Previous PayReality technical work. This page documents an earlier product direction and does not describe our current offering or availability. See what we're working on now.

← Developers

Runtime Policies

A Runtime Policy is a compiled artifact, not the governance document it was derived from: this page covers what that compilation actually does.

A Delegation of Authority document tells a human what's permitted. A Runtime Policy tells a deterministic evaluator the same thing, in a form it can execute against an Intent, with no ambiguity left for the evaluator to interpret. It can be compiled from such a document, or authored directly where that's the better fit; either way, it's a real, editable, versioned artifact reviewed through the same lifecycle. For the product-level explanation of why this exists, see Runtime Policies on the product side.

What compilation produces

policy.json (compiled, excerpt)
{
  "policy_key": "vendor-payment-approval-v4",
  "version": 4,
  "status": "active",
  "scope": { "action": "vendor_payment", "principal": "Finance Manager" },
  "conditions": [
    { "field": "amount", "operator": "<=", "value": 10000 },
    { "field": "currency", "operator": "==", "value": "USD" }
  ],
  "effect": "allow",
  "constraints": { "requires_dual_approval_above": 5000, "evidence_required": true }
}

This is the artifact the runtime actually evaluates against: structured conditions and a fixed effect (allow, deny, or require_human_review), not a paragraph a model has to interpret at decision time.

Runtime evaluation

Every field in conditions is checked against the Intent's actual content. All conditions must hold for the policy to match; the first matching policy's effect becomes the Decision, combined with whatever the Authority Graph separately determines about delegated authority, checked live at evaluation time against the exact delegation a policy was compiled from, not just the policy's own conditions in isolation.

Deterministic decisions

The same compiled policy, evaluated against the same Intent, always produces the same effect. There is no model call, no sampling, and no version drift inside evaluation itself: if a decision needs to be explained months later, re-running the same policy version against the same Intent reproduces it exactly.

Policy versioning

Publishing a new version doesn't edit the old one in place. Every version is retained, and every Decision's evidence records the exact version that was active when it was evaluated, so a policy change next quarter never silently rewrites what a decision made this quarter meant.

Policy deployment

A policy moves through draft → review → compiled → active → retired. Only an active policy is evaluated against live Intents; a draft can be edited freely because nothing depends on it yet, and a retired policy stops being evaluated going forward without deleting the history of decisions made while it was active.

Why this differs from the governance document

The governance document remains the source of truth for what your organization has actually decided; the compiled policy is PayReality's operationalization of it, not a replacement. If the two ever disagree, that's a signal the compiled policy needs to be corrected to match governance, not the other way around: Runtime Policies attest to evaluation of your authority, they don't originate it.

Other documentation

Getting StartedCreate an organization, register an agent, and get your first Authorization Receipt back.ArchitectureThe full path from an agent's signed intent to a decision and its evidence, component by component.Runtime APIThe Intent API: POST /v1/intents, its three possible outcomes, and the request/response lifecycle.AuthenticationThe Operator Key, per-user roles and permissions, per-developer API keys, and agent certificates.Authority GraphDelegated authority, roles, resources, and approval limits, and how governance becomes machine-readable.Authorization ReceiptsWhy logs aren't enough, the receipt lifecycle, and the planned architecture for independent verification.Evidence VerificationSignature verification, evidence export, and audit workflows against the Evidence Portal today.SDKsThe Python SDK, and the language roadmap for Node.js, Go, Java, .NET, and Rust.WebhooksEnterprise events (IntentReceived, DecisionCompleted, ReceiptIssued, and more) with real payloads.Integration ExamplesRotating keys, sending a heartbeat, and retiring an agent, with real SDK code for each.Integration GuidesConnecting Runtime Authority to agent frameworks, model providers, and enterprise systems.Agent RegistrationThe full agent lifecycle: registered, active, suspended, retired, or revoked.API ReferenceEndpoints, schemas, headers, status codes, errors, and versioning.Order WalkthroughOne order, followed end to end: signed intent, declared material fields, capability issuance, rejection on a changed field, and what the receipt path does and doesn't prove.