> For the complete documentation index, see [llms.txt](https://rwapact.gitbook.io/whitepaper/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://rwapact.gitbook.io/whitepaper/introduction/why-a-decision-layer-matters.md). # Why a Decision Layer Matters Why autonomous RWA trading needs a dedicated decision layer between agent intent and transaction execution. ## Why a Decision Layer Matters [The RWA Risk Gap](/whitepaper/introduction/the-rwa-risk-gap.md) established that transaction validity does not express every condition relevant to an RWA trade. Market context, policy constraints, and operating conditions can all affect whether an action should proceed. That raises an architectural question: where should those decisions happen? Existing systems already have distinct responsibilities. An agent determines what it intends to do. A wallet holds custody and signs transactions. An execution layer routes and executes approved actions. Policy systems can define permissions. Risk systems can evaluate relevant market conditions. These roles do not compete. Each addresses a different part of the trading path. The challenge is that the conditions needed to authorize an autonomous trade can remain fragmented across them. A dedicated decision layer creates a defined place to evaluate those conditions together. It sits between agent intent and execution. Its purpose is to determine whether a proposed action is allowed to proceed. > **The agent can propose. The decision layer can authorize. The execution layer can execute.** ### Execution and decision are different responsibilities Execution determines how a trade is carried out. It can select a route, submit a transaction, and complete the requested action through a venue or API. Decision determines whether that trade should be allowed to reach execution. It evaluates the conditions surrounding an intent before the execution path receives it. This distinction does not suggest that execution infrastructure is incomplete. Execution systems should remain focused on their own responsibilities. A wallet should remain responsible for custody and signing. A venue should remain responsible for execution. The decision layer complements these systems by providing a checkpoint for trade authorization. It does not replace the agent's strategy. It does not take custody. It does not become another trading venue. | Layer | Primary responsibility | What it does not necessarily answer | | --------------- | ---------------------------------------------- | ----------------------------------------------------------- | | Agent | Generates trade intent | Whether the action meets all current constraints | | Wallet | Custody and transaction signing | Whether market and policy conditions are acceptable | | Execution layer | Routes and executes transactions | Whether the trade is appropriate to execute | | Policy layer | Defines constraints and permissions | Whether current RWA market conditions support execution | | Risk layer | Evaluates risk conditions | Whether the complete action fits session and policy context | | Decision layer | Evaluates relevant conditions before execution | It does not execute the trade itself | The table describes a separation of concerns. It does not require every system to be independent or external. It shows why no single execution-focused responsibility necessarily produces a complete authorization decision. ### Fragmented context needs a defined checkpoint An autonomous RWA trade can depend on information that comes from several parts of the stack. Risk conditions can indicate whether current market context is acceptable. A session can establish whether the agent may act now. Policy can define permitted assets, amounts, and actions. Execution costs can also affect whether an action remains suitable. Other conditions may apply before authorization, depending on the intended controls. None of these facts alone settles the trade decision. The question is whether the proposed action satisfies the relevant conditions together, at the point of execution. Without a defined checkpoint, an agent can form an intent while the authorization context remains distributed across separate responsibilities. A decision layer makes that checkpoint explicit. It gathers the conditions required for a decision and evaluates them before an action moves forward. The result creates a clear boundary between **intent** and **authorized execution**. This boundary matters because intent is not unconditional authority. An agent should be able to express what it wants to do. That does not mean every generated action automatically receives permission to execute. The agent's authority can be bounded by the conditions under which it operates. A decision layer applies those conditions when the intent becomes an execution attempt. This makes the authorization boundary visible and machine-enforceable. ### The decision boundary A decision boundary is the point where a proposed trade changes state. Before the boundary, the action means: “the agent wants to perform this action.” After it, the system has determined that the action is allowed to proceed. ``` Agent Intent | v Decision Boundary | v Execution ``` The boundary does not eliminate the agent's role. The agent still interprets strategy, data, and instructions. It does not eliminate execution infrastructure either. Approved actions still move through the selected execution path. It separates the expression of an action from permission to carry it out. That separation is useful whenever authorization depends on more than a valid transaction and an authorized signature. The decision itself follows a simple conceptual sequence: ``` Intent ↓ Evaluate context ↓ Authorize or reject ↓ Execution ``` The outcome is not always authorization. The decision boundary can reject an action before it reaches execution. This is an intentional result, not an unexpected failure of the execution path. For example, rejection can occur when risk exceeds a permitted threshold. It can occur when an agent session is inactive or outside its intended scope. It can also occur when the asset, amount, or execution conditions violate an applicable policy. Making rejection explicit gives the system a clear response when a trade does not satisfy its authorization conditions. The agent receives a decision rather than assuming execution should proceed. The execution layer receives only actions that have passed the defined checkpoint. ### Autonomous agents need bounded authority A human trader can inspect an action immediately before signing. The trader can consider the asset, amount, market conditions, and timing at the final step. This review forms part of the authorization process. An autonomous agent can generate actions continuously. It can act on strategy, data, or predefined instructions without a person inspecting each transaction. Its ability to produce an intent can therefore operate faster and more frequently than direct human review. Authorization cannot depend entirely on a person being present at the final execution step. The system needs explicit conditions that determine whether the agent's current intent remains within its granted authority. This does not mean agents should be prevented from acting. It means their ability to act should be bounded by a decision process. The process applies the controls that are relevant when the proposed trade approaches execution. For RWA trading, those controls can be especially important. The asset's trading context can include market conditions, restrictions, and other factors beyond basic transaction validity. A decision boundary provides a place to account for that context without assigning every responsibility to the agent or execution layer. ### Decision is more than risk Risk evaluation is an important input, but it is not the complete authorization model. A trade decision can depend on several independent conditions: * Risk condition and current market context. * Session validity and policy authorization. * Asset, amount, execution cost, and attestation requirements. These dimensions answer different questions. A favorable risk condition does not establish that an agent is within an active session. A valid session does not establish that an amount is permitted. A permitted asset does not establish that execution conditions are acceptable. The decision layer evaluates the conditions relevant to authorization as a combined decision. It does not reduce trade governance to a single risk score. It also does not require one condition to stand in for every other control. This model allows the system to treat authorization as a deliberate outcome. An action proceeds when the required conditions are satisfied. It is rejected when they are not. The result can be recorded as part of the decision process without changing the execution layer's responsibility. ### Keep decision separate from execution The decision layer should remain separate from execution by design. It evaluates and authorizes. The existing execution layer remains responsible for executing approved trades. This separation allows existing execution infrastructure to continue serving its role. Different execution environments can be placed behind the same decision boundary. Risk and policy logic can remain independent from a specific venue. It also gives the system the opportunity to reject an action before execution begins. That is an architectural choice, not a guarantee that every trade is safe or every outcome is correct. The important distinction remains simple. An agent can express an intent. A decision layer can determine whether that intent is authorized under current conditions. Execution infrastructure can then carry out the approved action. This is the role RWAPACT is designed to fill. [Introducing RWAPACT](/whitepaper/introduction/introducing-rwapact.md) explains how the protocol turns this decision-layer concept into an on-chain risk gate. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://rwapact.gitbook.io/whitepaper/introduction/why-a-decision-layer-matters.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.