Keep one governed capability behind the Four Doors
The Four Doors describe human UI, REST API, Remote MCP, and browser-based WebMCP access to a capability, with availability and permissions stated separately. The Four Doors help distinguish ways to reach a capability. They are not four different definitions of what that capability means. I would expect the same decision rules and evidence limits to survive every route through which the result is delivered.
“The interface changes. The need for useful decision support does not.”
— Curtiss Witt, The Decision Economy, Chapter 14.
What are the Four Doors to a decision-support capability?
The Institute’s Four Doors are human UI, REST API, Remote MCP, and browser-based WebMCP access to a decision-support capability. They describe routes, not four different promises of intelligence or four guaranteed sources of demand. Each route needs its own availability and behavior statement. (Witt, supplied author source set, September 2026)
A human interface lets a person read the purpose, provide inputs, and understand the result directly. Its usefulness depends on clear interaction and explanation. Adding machine routes does not excuse a confusing form or a result whose meaning only the development team understands.
A REST API route allows a compatible client to submit a documented request and receive a structured response. The contract must explain what to send and what the result means. It does not automatically tell every external agent that the tool exists or deserves selection.
Remote MCP connects compatible clients to a server’s defined capabilities through the protocol. The client still needs appropriate configuration, task fit, and authority. A server being available is different from a particular assistant discovering, choosing, and successfully using it for a real user. Model Context Protocol: What is MCP?; accessed September 2026
WebMCP concerns structured tools exposed by a website for supported browser-agent interactions. It is distinct from a remote MCP server. State browser support and any page effects explicitly rather than assuming the name means universal compatibility with every agent or browser. Chrome for Developers: WebMCP is available for early preview; accessed September 2026
The comparison below describes two approaches to the work. It is a practical design contrast, not a measured claim that one approach always produces a better commercial outcome.
| Information and activity approach | Decision-support approach |
|---|---|
| Treat each interface as a separate truth. | Keep the decision rules and limits consistent. |
| Open every route without a consumer. | Match each route to a defined task. |
| Confuse implementation with availability. | Publish the actual validation status of each door. |
What meaning must stay consistent across the doors?
The same approved assessment rules should retain their meaning across supported routes. An interface change should not quietly change how owner answers are interpreted. If behavior differs for a legitimate reason, document that difference instead of leaving clients to discover conflicting results by accident.
BY YOUR ACCOUNT remains the evidence basis whether DERA is used through a page or a machine interface. The transport does not verify the business. Carry that label into summaries and integrations so a structured response does not appear more authoritative than the human result. Decision Economy Institute: live capability manifest; accessed September 2026
A client needs to know which fields represent dimensions, descriptive statuses, and starting actions. The human version needs the same meanings in readable form. Consistent semantics matter more than making every interface look alike; the purpose is to preserve what the result actually establishes.
Record the contract and ruleset versions relevant to an invocation. A change to allowed inputs or output meaning can affect consumers even when the endpoint stays the same. Version information helps maintainers know when to review an integration rather than assume it remains valid indefinitely.
The result does not predict AI recommendation, certify a business, or perform an independent audit. Those limits should not disappear in a shortened machine response or promotional summary. A smaller representation must preserve any qualification needed to avoid changing the substantive meaning.
How do I choose a door for a real task?
Identify who or what needs the capability: a person, a conventional application, a remote AI client, or a supported browser agent. The answer informs which route is useful. Building every possible interface before understanding the consumer can create maintenance work without a defined decision benefit.
A client should know whether the tool assesses readiness, retrieves information, or performs another action. Avoid a broad name that suggests capabilities the route does not provide. Narrow descriptions improve task matching and make it easier to identify an invocation that falls outside the supported purpose.
Some routes may depend on the current browser page or session, while others accept a self-contained request. State the relevant context and what the operation changes. The caller should not have to infer whether a tool result will replace a current assessment or leave the interface untouched.
A manifest or directory listing can help identify a capability. Successful invocation requires a compatible request and supported route. Do not report the first as proof of the second. A useful integration record distinguishes seeing the tool description from actually completing the defined operation.
A route can expose an operation without authorizing unrelated action. The assessment’s result does not grant permission to send email, book services, or make payments. A client must respect the operation’s scope and the user’s authorization rather than treating access as a general license to continue.
The working rule I return to is this: “The interface changes. The need for useful decision support does not.” It is a way to judge the next piece of work, while keeping its evidence and limitations visible.
How should I verify each access route?
Review whether a person can understand the introduction, complete relevant inputs, and interpret the full result. That is a different check from whether a server endpoint responds. The human route is successful when it delivers the promised help in an understandable way, including important limitations.
For an API route, inspect documented methods, request shape, output, and error behavior. A request that returns a response is only the beginning. Verify that the substantive result matches the expected meaning and does not omit the evidence basis or other important qualifications.
A supported client needs to identify the tool and use its documented input and output contract. Record which client and conditions were tested. Do not generalize one successful integration into a claim that all AI assistants support the same route or will choose to use it.
Browser-based tooling depends on the supported environment and the page’s actual behavior. Confirm discovery, invocation, and any effect on the current interface. An internal test and an external production-browser test are different evidence, and both should retain their actual scope.
A feature can exist in code while remaining unavailable for general use pending validation. Keep those statuses separate in the manifest and public copy. This makes the remaining work concrete and avoids asking a user or agent to depend on a capability not yet established for their environment.
Which doors does the Institute currently declare available?
The live Institute manifest declares the assessment’s REST and Remote MCP routes available and includes their endpoints. That is the current public capability statement. A reader should still distinguish this declaration and its recorded tests from a new independent verification in a different client environment. Decision Economy Institute: live capability manifest; accessed September 2026
The manifest marks WebMCP implemented but unavailable pending external-browser validation. Do not advertise it as universally live. The distinction protects the accuracy of the Four Doors explanation while allowing the architecture to describe the intended browser route and its remaining validation requirement. Decision Economy Institute: live capability manifest; accessed September 2026
The manifest states that the assessment does not book services, make payments, or send messages as part of its invocation. Optional Email My Plan is a separate explicit request. Preserve that separation when an agent uses the assessment result to suggest what a person might do next. Decision Economy Institute: live capability manifest; accessed September 2026
The Institute’s OpenAPI document describes the HTTP surface; it is not a fifth decision engine or proof that the four routes are equally available. Use it with the relevant interface documentation, and avoid confusing a description of capabilities with evidence of actual customer use. Decision Economy Institute: live capability manifest; accessed September 2026
Use the route suited to the user and supported environment, then inspect whether it delivers useful decision help. Four Doors expands possible access patterns; it does not establish four times the usage, a recommendation advantage, or a guaranteed commercial return from the number of interfaces alone.
What can I do with this today?
Start with one offer and write down the next decision this article helps you examine. Give the work a defined scope before adding a new page, tool or integration.
1. Choose a route appropriate to the user and task.
2. Identify the consequential fact or condition that remains uncertain. Name who can check it and what would establish completion.
3. If you need help ordering the business work, complete the free Decision Economy Readiness Assessment. Read its reasons and three starting actions, then choose the first task you can inspect.
Our own example is deliberately bounded. The Institute’s Method explains the owner-reported result; its capability manifest declares what the tool can do; and its assessment schema makes the question bank and data contract inspectable. These September 2026 publisher documents describe the assessment. They do not independently establish better customer or business outcomes.
Keep one governed capability behind the Four Doors
Before the next customer faces the same unresolved choice, identify the improvement that would make the answer more useful. Use the readiness assessment to turn your reported conditions into three starting actions, and keep the next evidence check in view.
Disclaimer
Based on your answers, this assessment suggests improvement priorities; it does not independently verify your business or predict AI recommendations, sales, or business quality.
FAQ
Who uses the human door?
A human interface lets a person read the purpose, provide inputs, and understand the result directly. Its usefulness depends on clear interaction and explanation. Adding machine routes does not excuse a confusing form or a result whose meaning only the development team understands.
What should output structure preserve?
A client needs to know which fields represent dimensions, descriptive statuses, and starting actions. The human version needs the same meanings in readable form. Consistent semantics matter more than making every interface look alike; the purpose is to preserve what the result actually establishes.
How narrowly should an operation be described?
A client should know whether the tool assesses readiness, retrieves information, or performs another action. Avoid a broad name that suggests capabilities the route does not provide. Narrow descriptions improve task matching and make it easier to identify an invocation that falls outside the supported purpose.
What browser environment needs checking?
Browser-based tooling depends on the supported environment and the page’s actual behavior. Confirm discovery, invocation, and any effect on the current interface. An internal test and an external production-browser test are different evidence, and both should retain their actual scope.
What is the role of the OpenAPI document?
The Institute’s OpenAPI document describes the HTTP surface; it is not a fifth decision engine or proof that the four routes are equally available. Use it with the relevant interface documentation, and avoid confusing a description of capabilities with evidence of actual customer use.
Do I need to share contact details before seeing the assessment result?
No. The complete result is available before an optional email request. If a contact commitment has held you back, try the free readiness assessment and read the plan first. Emailing it and consenting to future updates are separate choices. The result remains BY YOUR ACCOUNT.
References
Curtiss Witt. The Decision Economy, updated author-supplied manuscript, Chapter 14 for the quoted decision rule; the supplied manuscript also grounds the framework. Supplied September 2026; unpublished manuscript, so no public URL is asserted.
Decision_Economy_DSA_Definitive_Design_Specification_V1 final.docx. Supplied September 2026. Assessment behavior and design boundaries. Historical build-stage prohibitions are superseded by later explicit authorizations; this is not current deployment proof.
Model Context Protocol: What is MCP?. Official protocol documentation. Describes connections between AI applications and external systems. Compatibility, authorization, and useful task behavior still require specific checks.
Chrome for Developers: WebMCP is available for early preview. First-party announcement; February 10, 2026. Describes proposed declarative and imperative browser APIs. Recheck support when drafting and publishing; early-preview documentation is not universal browser availability.
Decision Economy Institute: live capability manifest. Publisher’s capability declaration, accessed September 10, 2026. Describes the available routes and their limits; not an independent test of every operation.
Decision Economy Institute: How this assessment works. Publisher’s own Method; ruleset de-readiness-1.0.0, accessed September 10, 2026. Not an independent outcomes study.
Decision Economy Institute: Assessment schema and question bank. Publisher’s technical contract; accessed September 10, 2026. Data shape and published question bank, not proof of real-world decision quality.
Continue exploring
Can a website be easy for AI to access but still be unhelpful?
What are an API, OpenAPI, and MCP—and which does my business need?
What is WebMCP, and should my business use it yet?
Tags: Four Doors to decision support; Decision Economy; Decision Economy Institute; Curtiss Witt; customer decisions; decision support; business readiness; DERA; Better Choices; Machine access.