Glossary

Canonical definitions of the terms behind AGLedger accountability infrastructure. Each term has a permalink — link to #mandate, #pattern-d, #layer-3 directly.

Core protocol objects

Mandate

A structured commitment — what needs to be done, by when, under what constraints. Locked at creation. The mandate exists before work begins.

A mandate is the commitment that starts every unit of accountable work in AGLedger. It is locked at creation: the criteria, the deadline, the numeric bounds, and the contract type cannot be mutated after the mandate is ACTIVE. Both principal and performer are bound to the same definition of done. Mandates are Ed25519-signed and hash-chained to every subsequent state transition.

→ AOAP protocol spec→ How AGLedger works

Receipt

Evidence of delivery, submitted by the performer against the locked mandate. Structured, signed, hash-chained to the mandate that produced it.

A receipt is the performer's claim that the mandate was completed, along with the evidence to support the claim. It cites the mandate ID it responds to, carries structured evidence fields defined by the contract type, and is Ed25519-signed by the performer. Receipts are not judgments — they are claims. The verdict decides whether the claim is accepted.

Verdict

The principal's accept-or-reject judgment on whether the delivery met the mandate criteria.

Every receipt is followed by a verdict. The principal — human or system — decides whether the delivery satisfies the locked criteria. The verdict is signed, appended to the hash chain, and is what finally moves a mandate to FULFILLED or REJECTED. Numeric tolerance can auto-render a PASS verdict when bounds are met; the principal remains the ultimate judge.

Settlement Signal

SETTLE or HOLD, routed to payment platforms via webhook. AGLedger produces the signal; your financial systems act on it.

Settlement Signal™ is the outbound event AGLedger emits when a mandate reaches a terminal state. It carries SETTLE (proceed with payment, release goods, close ticket) or HOLD (do not proceed). AGLedger does not move money, transfer assets, or close tickets. Your financial systems, ERP, and ticketing systems act on the signal through webhooks with HMAC-SHA256 signatures.

Actors

Principal

The party that assigns a mandate and renders the verdict. Can be human, system, or agent.

The principal is the accountability holder. They define what success looks like (criteria), they decide whether the receipt satisfies those criteria (verdict), and they hold the authority to accept or reject. In Pattern D (ERP-as-Performer), the ERP system is typically the principal.

Performer

The party that executes the mandate and submits the receipt. Can be an agent, a service, or an enterprise system.

The performer does the work. They receive (or propose) the mandate, execute against its criteria, and submit the receipt with supporting evidence. Performers are signing parties — receipts are cryptographically attributed, not just logged.

Audit Agent

Your agent that queries AGLedger to answer audit questions in seconds instead of weeks. Customer-owned, not a product we ship.

An Audit Agent is a customer-built agent that queries the AGLedger vault to answer audit, compliance, or forensic questions. Because records are structured and signed at the moment they are written, the Audit Agent can answer "did agent X perform action Y correctly on date Z?" in seconds — with the signed proof attached. The Audit Agent is possessive: it is your agent, not AGLedger's service.

→ Compliance use cases

Patterns and deployment

Pattern D (ERP-as-Performer)

The hero integration pattern. The enterprise system owns the mandate and receipt; the agent performs work and renders the verdict. 8/8 FULFILLED across providers in testbed.

Pattern D moves accountability from agent behavior to infrastructure. The enterprise ERP (or CRM, ITSM, finance system) creates the mandate with policy-derived criteria, dispatches the task, captures the outcome, and submits the receipt with validated evidence from its own systems. The agent reviews the record and renders the verdict. Because the enterprise system owns both the mandate and the receipt, accountability is guaranteed regardless of whether the agent follows instructions. This is accountability your agents cannot opt out of.

→ Where AGLedger fits→ How accountability became the coordination layer

Governance Sidecar

Optional deployment mode where AGLedger sits beside a policy gateway, wrapping denials with directives.

The Governance Sidecar deployment mode pairs AGLedger with a Layer 1 policy control (Microsoft Agent Governance Toolkit, Kong AI Gateway, Galileo Agent Control). When the gateway denies an agent action, the sidecar wraps the denial with a directive instructing the agent to obtain a mandate, retry, and close the accountability loop. It turns a stateless allow/deny into a stateful, auditable interaction.

Market framing

Layer 3 (Accountability)

The third layer of the agent governance stack. Layer 1 is policy controls; Layer 2 is agent guardrails; Layer 3 is signed chain-of-custody for what the agent did.

An emerging three-layer framework organizes AI agent infrastructure: Layer 1 — policy controls (Microsoft Agent Governance Toolkit, Kong AI Gateway, Galileo Agent Control) decide whether an agent can act at all. Layer 2 — agent guardrails (Composio, Snyk, capability-scoping tools) shape how the agent acts. Layer 3 — accountability (AGLedger) records what the agent actually did, as a signed, tamper-evident chain of custody. Layers 1 and 2 are preventive. Layer 3 is evidential. AGLedger plugs into Layers 1 and 2; it does not compete with them.

→ Where AGLedger fits

AOAP

Agentic Operations and Accountability Protocol. The four-endpoint coordination language behind AGLedger: create, receipt, verdict, fulfill.

AOAP (Agentic Operations and Accountability Protocol) is the contract behind AGLedger. Four endpoints complete the lifecycle — mandate creation, receipt submission, verdict rendering, and fulfillment. Every transition is Ed25519-signed and SHA-256 hash-chained. AOAP is LLM-agnostic and framework-agnostic: any process that speaks HTTP can participate.

→ AOAP protocol spec

Compliance primitives

Dual Trail

Declare — what the agent reported it did — versus Detect — what the evidence shows. Both trails live in AGLedger.

Dual Trail is the AGLedger compliance pattern that records two parallel streams for the same unit of work. The Declare trail captures what was committed and what was claimed (the mandate and receipt). The Detect trail captures what the evidence independently shows (system-of-record events, webhook payloads, third-party confirmations). The two trails are reconciled by the Compliance Crosscheck — when they diverge, drift is surfaced.

Compliance Crosscheck

The reconciliation between Declare and Detect trails that surfaces drift between what an agent claimed and what the evidence shows.

The Compliance Crosscheck runs across the Dual Trail. For each mandate, it compares the Declare record (mandate + receipt) against the Detect record (independent evidence from systems of record). Agreements are the norm; disagreements are the signal. Crosscheck failures are structured alerts that feed compliance dashboards, Audit Agent queries, and regulatory reports.

See also