Architecture
Ten components, one deterministic path, from an agent's signed intent to a decision, its evidence, and, where a trusted destination reports back, a reconciled execution outcome.
An agent can reason about what to do next. Whether it's authorized to do it isn't the agent's call, and it isn't Runtime Authority's either: that's the organization's, through the governance it already runs. Everything below exists to answer that question, deterministically, in the moment between an agent forming an intent and an enterprise system acting on it, without ever asking the agent itself.
Agent
An autonomous AI agent, registered with its own cryptographic identity, forms an intention to take a real-world action.
Intent
That action is expressed as a signed Intent: a structured, cryptographically signed request naming the resource, amount, and counterpart involved. Its content comes directly from the Agent's own signed request, or, for higher-assurance use cases, is corroborated by a Trusted Adapter (see below). Nothing has happened yet.
Runtime Authority
The Intent's signature is verified, then it's handed to evaluation. This is the orchestrating layer, not a single check: it's what queries the two components below.
Authority Graph
Answers "is this agent's principal entitled to delegate this kind of action, and to this extent?" (modeled from the organization's actual governance documents).
Runtime Policies
Answers "under what conditions is this specific action permitted?" (compiled, versioned rules evaluated against the Intent's actual content).
Decision Engine
Combines both answers deterministically into exactly one outcome: Allow, Deny, or Human Review. The same Intent, Graph, and Policy always produce the same Decision.
Capability Authorization
For an Allow, or a Human Review a reviewer has since approved, an optional short-lived, single-use authorization can be issued, bound to the exact agent, action, resource, and environment the decision covered. Not issued for every decision automatically.
Authorization Receipt
The Decision is recorded as signed evidence the moment it's made, retrievable today as a receipt through the API; a portable, independently verifiable artifact is the roadmap beyond that, see Authorization Receipts.
Evidence Portal
Where that record is searched, investigated, audited, and exported: the human-facing layer over every decision the runtime has made.
Enterprise System (downstream integration)
The payment rail, ERP, or infrastructure API the agent was trying to reach in the first place. Not part of PayReality: a compatible Policy Enforcement Point (PayReality's own reference implementation, agent-runtime middleware, an API/MCP gateway, a customer proxy, or an enterprise-system adapter) verifies and consumes a Capability, or otherwise requires an Allow decision, before letting execution proceed. PayReality never hosts or performs the operation itself, and an Allow decision alone is never proof that execution occurred.
Execution Receipt & Reconciliation
When a separately authenticated destination or trusted execution adapter reports back what it actually did, PayReality verifies that receipt's linkage and reconciles it against the authorized action: MATCHED, MISMATCHED, EXECUTION_FAILED, PARTIAL, RECEIPT_MISSING, or INDETERMINATE. A cryptographically authenticated receipt proves what the trusted source reported; it does not independently prove that the underlying business system or real-world event was truthful.
Why this is a chain, not a single check
A simpler design would run one function ("is this allowed?") against one rule set. Runtime Authority deliberately keeps the Authority Graph and Runtime Policies as separate components evaluated together, because they answer separate questions your organization already keeps separate: who is entitled to delegate authority (an org-chart and Delegation of Authority question) versus under what conditions a specific action is permitted (a policy question). Collapsing them would mean rebuilding your governance structure from scratch instead of modeling the one you already have.
Two ways to establish what's actually being attempted
An Agent's own signed Intent is one way Runtime Authority learns what's being attempted, and it's sufficient for lower-assurance use cases. For higher-assurance ones, PayReality doesn't have to rely solely on what the Agent says: a Trusted Adapter, a separate, independently authenticated identity, reports the real attempted enterprise operation through an approved, human-reviewed Action Mapping, translated into the same canonical action Runtime Authority evaluates. These are three distinct concepts, never collapsed into one: the Agent is who is acting, the Trusted Adapter is the trusted witness for what operation is actually being attempted, and an IntegrationIdentity is the credential the Adapter itself authenticates with, distinct from any Agent's own certificate. An Agent's self-declared description of an action is never, on its own, treated as proof of what an external enterprise system was actually asked to do once a Trusted Adapter path exists for it. No packaged connector for SAP, Salesforce, Workday, ServiceNow, or any other vendor system ships with PayReality today: every Trusted Adapter is customer-built, against your own systems.
Trusted Enterprise Facts
Some authority rules depend on a fact that doesn't originate inside PayReality at all: whether a supplier is approved, whether a delegated authority holder is still active, business-unit membership, account status, or a risk classification. PayReality can rely on these as authenticated, provenance-aware assertions, supplied through an approved trust path, rather than from the Agent simply asserting them. This is a real distinction worth stating plainly: PayReality authenticates the source, the provenance, and the validity window of an enterprise fact. It doesn't independently verify the underlying business truth, and it doesn't replace the source system that remains responsible for it. There's no single, dedicated public API guide for this surface yet; the exact integration path depends on which enterprise source you're connecting and which platform mechanism it supports, not a one-size endpoint every customer calls the same way.
Three evidence layers
What a decision's evidence contains grows in three distinct layers, each answering a different question. Intent evidence is what was proposed or observed: the Agent's signed request, or a Trusted Adapter's independent report of it. Authority evidence is why the decision came out the way it did: the exact Authority Graph and Runtime Policy state a decision was evaluated against. Execution evidence is what a trusted destination or execution adapter reported afterward, and whether it matched what was authorized. The first two layers are produced the moment a decision is made; the third only exists once, and if, a separately authenticated source reports back.
Vendor-neutral by design
This architecture is built around a vendor-neutral authority and evidence contract, not a single vendor's agent runtime or enforcement product. Any agent runtime, gateway, or customer-controlled enforcement point that can submit a canonical action, enforce a PayReality authorization, and return an authenticated execution receipt can participate in this chain. Named adapters, for a specific enterprise system or a specific agent-runtime vendor, are built to match each customer's actual workflow requirements; PayReality doesn't ship a generic, off-the-shelf connector for every vendor system today (see Integration Guides).
The PayReality reference PEP, the enforcement point named above, is one implementation of that contract, not the only one a real deployment can use: it's a working reference implementation, a certification and test mechanism other enforcement points can be checked against, a fallback deployment option where a customer has nothing else in place, and the definition of what correct authorization verification actually means for this platform.
What's live today vs. planned
Agent, Intent, Runtime Authority, Authority Graph, Runtime Policies, the Decision Engine, the Evidence Portal, and the Authorization Receipt are the live system: every Intent submitted today passes through exactly this path, ending in a decision, its evidence, and a retrievable Authorization Receipt. The Trusted Adapter path and Capability Authorization are real and live today too, on either runtime path. Trusted Enterprise Facts are also real today, at the level described above; what's still direction is a single, uniform public API for connecting them, not the underlying mechanism. Execution receipts and reconciliation are the newest surface here, and the least publicly documented: see Runtime API for its current status. See Authorization Receipts for exactly what the receipt contains today. The Enterprise System node above is shown for context: PayReality does not execute the action or reach into that system today. A production integration would need an enterprise-side enforcement point that requires and checks the decision before letting execution proceed; no such integration ships with PayReality today.