Proof-of-Mandate and Receipt

When Mandaitor performs an operation for an agent, it signs two statements about it:

• The Proof-of-Mandate (PoM) says that a mandate authorized this operation: which agent, which business action, which record, under which mandate, and for exactly which request. Mandaitor signs it when it sends the write, after its last check before the write.
• The receipt says what the write did: the record's version before and after, when the operation was decided, sent and completed, who approved it, and the PoM it was made on. Mandaitor signs it once a read-back of the record has established the outcome.

The proof answers was this allowed?, and the receipt what happened? Together they let a reviewer, an auditor or a counterparty check later that an operation in a business system was authorized, and what it did, without trusting the agent or reading its logs.

Proof versus receipt

	Proof-of-Mandate	Receipt
Says	The write was authorized, by this mandate, for this request	This is the outcome of the write
Signed	When the write is sent	When a read-back establishes the outcome
Format	SD-JWT Verifiable Credential: typ: "vc+sd-jwt", vct: "ProofOfMandate"	Compact JWS: typ: "mandaitor-receipt+jwt"
Key	#key-1 in the issuer's DID document	#receipt-key-1, used for receipts only
Bound to	The request digest, or the approval digest when a person approved	The execution, its request digest, the digest of the result the agent was given, and the PoM's digest
Who receives it	The audit trail and the evidence pack. The agent never does.	The agent, with the execution; the audit trail and the evidence pack

Both are signed with PS256, with keys held in a key management service, and both name the same issuer: did:web:api.mandaitor.io:v1, whose DID document is at https://api.mandaitor.io/v1/did.json. A token is one or the other by its typ and key: a PoM is never accepted as a receipt, nor a receipt as a PoM.

The agent never receives the Proof-of-Mandate. Mandaitor performs the write itself, so a PoM in the agent's hands would only be an authorization it could take somewhere else. The PoM stays on the mandate's audit trail, and the receipt points to it.

The Proof-of-Mandate

A PoM is a W3C Verifiable Credential in the Selective Disclosure JWT (SD-JWT) format. These claims are always visible:

Claim	Content
decision	ALLOW
mandate_id	The mandate that authorized the write
requested_action, requested_resource	The business action and the one record, such as procurement.requisition.release on procurement:plant:1000/requisition:10000123
delegate_subject_id, sub	The agent's DID
verification_event_id, verification_timestamp	The audit event that recorded the dispatch, and when
request_digest or approval_digest	The one request the PoM authorized: the approval's digest when a person approved it, the request's otherwise

Others can be withheld when the PoM is shared, without breaking its signature: the tenant, the principal, the reason codes, and constraints_snapshot, the constraints the decision was evaluated against. A constraint the snapshot lists was checked. An execution is never authorized under a constraint Mandaitor cannot evaluate, so its PoM never carries a constraint that was not.

The receipt

The receipt is a compact JWS, signed PS256. Its claims name the agent, the tenant and the execution, the tool and its version, the request digest, the approval if a person gave one, and:

• authorization: the dispatch event, the mandate, and pom_digest, the SHA-256 of the PoM's compact form;
• target: the connector, the system, the record, its version before and after, and the target's own transaction reference where it has one;
• timeline: when the operation was decided, sent and completed;
• result_digest: in SUCCEEDED, the digest of the result the agent was given, so the receipt binds what the agent was told.

An execution gets a receipt in SUCCEEDED, and in FAILED once a read-back proves that nothing was written. A denial has none: its record is the decision on the audit trail. Nor does an outcome a person of the tenant recorded by hand, because Mandaitor signs only what it read back. Receipts gives every claim and how to verify one, with or without the SDK.

Where to find them

• The agent gets the receipt in the execution, from GET /executions/{id} or in the MCP server's tool result.
• The audit trail records the PoM on the dispatch event and the receipt on the outcome's event.
• The evidence pack of a mandate lists both, in chain order, in proof_tokens. See Evidence Packs and Audit Events.

Other signed statements

• A request-bound decision's authorization is not a PoM. It is a single-use token for one request, typ: "mandaitor-authorization+jwt", signed with a key of its own, which an integrator's enforcement point redeems before its own system acts. See Request-bound Decisions.
• POST /verify can return a PoM to its caller, which then acts itself. That PoM states a decision, not a write: no receipt follows it. See Verifying Actions.