Authority Graph
The structure Runtime Authority queries to answer one question: is this principal entitled to delegate this action, and to what extent?
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.
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.