Authority Graph

The Authority Graph is not a permissions table. It's a connected structure of principals (who holds authority), delegates (who it's been extended to, including AI agents), resources (what's being acted on), and the constraints attached to each delegation, modeled this way because a flat table can't represent "the Finance Manager may delegate payment approval up to $10,000 to a specific agent, who may act on the AP Vendor Payments resource only." For the product-level explanation of why this exists, see Authority Graph on the product side.

What a delegation looks like

{
  "principal": { "id": "prin_fin_mgr", "role": "Finance Manager" },
  "delegate": { "id": "agt_8f2b1c", "type": "agent" },
  "resource": { "type": "vendor_payment", "scope": "AP-EMEA" },
  "constraints": {
    "approval_limit": { "amount": 10000, "currency": "USD" },
    "expires": "2027-01-01T00:00:00Z",
    "requires_dual_approval_above": { "amount": 5000, "currency": "USD" }
  },
  "version": 4
}

Roles and role hierarchy

Principals sit inside your existing role hierarchy, not a parallel one PayReality invents. Delegation can flow along that hierarchy (a Finance Director's authority can be sub-delegated by a Finance Manager reporting to them) exactly as your org chart already permits, or explicitly blocked from doing so where separation of duties requires it.

Resources

A resource is whatever the delegated authority is scoped to: a payment type, a procurement category, an infrastructure system, a contract class. Scoping a delegation to a specific resource is what stops "may approve vendor payments up to $10,000" from being read as "may approve anything up to $10,000."

Approval limits

Limits are constraints on a specific delegation, not a global ceiling: two different agents acting for two different principals can carry two different limits on the same resource type, because that's how your actual approval matrix already works.

Relationships and versioning

Every delegation carries a version. Editing who can delegate what doesn't overwrite history: a decision made under version: 3 remains explainable against exactly that version, even after version: 4 publishes. This matters because a Decision's evidence needs to reference the authority state that was actually active at evaluation time, not whatever the graph looks like when someone checks later.

Approved delegations are versioned snapshots, but the graph is not only consulted at compile time. A Runtime Policy compiled from a specific delegation is grounded in that exact delegation relationship, and at evaluation time, before that policy is allowed to grant the authority it was compiled from, the runtime checks that the grounding delegation still exists and is still active. Revoking or expiring it stops the derived policy from granting that authority automatically, with no manual policy edit required: the check runs on the live graph, not a cached copy of it from whenever the policy was compiled or last reviewed.

How governance becomes machine-readable

The AI Authority Builder reads governance documents you already have (a Delegation of Authority policy, an approval matrix, a signing schedule) and proposes the graph structure above as candidates for human review. Nothing is published automatically: a person confirms the extracted principals, delegations, and limits actually match the source document before the graph goes live. Where no single document captures the structure, the same graph shape can be authored directly instead: AI-assisted extraction is a convenience, not the only path to a valid graph.