> 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/the-rwapact-protocol/pact-decision-logic.md). # Pact Decision Logic ## Pact Decision Logic The Five-Layer Pact produces one authorization decision for each trade intent. It does not approve a trade because one component returns a favorable result. The required conditions must collectively pass before execution is authorized. The decision model is: ``` Can_Trade = KRO risk below threshold AND KSO session active and in scope AND KPV policy allows asset and amount AND KGR gas conditions are optimized ``` KAR is not another approval condition. It records the approval or rejection that results from the required checks, together with relevant decision context. ### From trade intent to decision An agent submits a trade intent to the Pact decision boundary. KRO evaluates RWA-specific risk. KSO validates the agent's session authority. KPV checks the asset, amount, and trade conditions against policy. KGR evaluates gas and execution conditions. The outputs combine into one authorization result. KAR records that result. If all required conditions pass, execution is authorized. If any required condition fails, the trade does not proceed and KAR records the rejection reason. ``` Trade Intent -> KRO: Risk Evaluation -> KSO: Session Validation -> KPV: Policy Validation -> KGR: Gas Conditions -> Decision -> KAR: Attestation ``` This lifecycle shows a decision boundary, not a transaction execution sequence. RWAPACT determines whether execution is allowed. The execution layer carries out an authorized transaction after that decision. ### The AND condition The conjunction in `Can_Trade` is central to the Pact. An acceptable risk score alone is insufficient. The agent must also be acting in an active session, within its authorized scope, under a policy that permits the requested asset and amount, and under acceptable gas conditions. KRO requires the assessed risk to remain within the applicable threshold. KSO requires an active session that covers the agent and trade. KPV requires the asset and amount to comply with the active policy. KGR requires gas and execution conditions to satisfy the configured optimization requirements. The result is all-or-nothing for the required conditions. A failed requirement prevents authorization. This avoids treating individual checks as separate recommendations that can be ignored when execution remains technically possible. ### Approval path When each required condition passes, RWAPACT authorizes the trade to continue to the execution layer. ``` Trade Intent -> Risk Pass -> Session Pass -> Policy Pass -> Gas Pass -> Authorization -> KAR Attestation -> Execution ``` KAR records the approval and relevant context. The execution layer then performs the authorized transaction. RWAPACT authorizes. The execution layer executes. For example, an agent may submit a tokenized stock trade where the risk remains within the permitted threshold. The session is active, the asset and amount are within scope and budget, the policy permits the trade, and the gas conditions satisfy the configured requirements. The Pact authorizes the trade, KAR records the decision, and the execution layer can perform the transaction. ### Rejection path When a required condition fails, RWAPACT rejects the trade before it reaches execution. ``` Trade Intent -> Failed Check -> Reject -> Reason Code -> KAR Attestation -> No Execution ``` Rejection is a normal protocol outcome. It does not necessarily indicate a malfunction. It can show that the Pact correctly determined the trade did not satisfy the conditions required for authorization. Reasons can include a risk score above threshold, an expired or revoked session, an asset outside the session scope, a trade that exceeds the session maximum, a policy violation, insufficient liquidity, excessive slippage, an oracle freshness requirement that is not satisfied, a market-hours restriction, a compliance freeze, or gas conditions that are not optimized. KAR records the rejection reason and the decision context. The execution layer receives no authorization for the trade. ### Decision context The final decision is more than a boolean. KAR preserves the context associated with approval or rejection, including the agent ID, session ID, asset, amount, risk score, policy version, gas route hash, approval status, rejection reason, timestamp, and execution transaction hash after execution. This context preserves the circumstances under which RWAPACT made its decision. It supports a persistent, on-chain history of the authorization outcome. It does not automatically create legal compliance or guarantee dispute resolution. ### A valid trade that gets rejected The following conceptual example shows the difference between technical validity and Pact authorization. It does not describe a production transaction. An autonomous agent submits a tokenized stock trade with valid transaction parameters. KRO returns a risk score of `67`. The active policy, evaluated by KPV, permits a maximum KRO risk score of `50`. The risk condition does not satisfy the active policy threshold. RWAPACT rejects the trade. KAR records the risk score, policy version, rejection status, rejection reason, and relevant session and trade context. The execution layer never receives authorization. ### Why rejection is a first-class outcome RWAPACT is designed to prevent trades from reaching execution when required conditions are not satisfied. Rejection is therefore an expected outcome of the decision gate, not an incidental side effect of a failed execution attempt. The boundary remains consistent in both paths: ``` The agent proposes. RWAPACT decides. The execution layer executes. ``` The Five-Layer Pact supplies the conditions for this decision. The next sections examine each component in detail, beginning with [KRO, Risk Oracle](/whitepaper/the-five-layer-pact/kro-risk-oracle.md). --- # 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/the-rwapact-protocol/pact-decision-logic.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.