Skip to content

From user intent to an auditable purchase request.

An audit trail becomes useful only when it preserves the chain of authority—not merely a timestamp and a final status.
By Arnav Kakar 6 minute read

The useful unit is a trace

A trustworthy purchase record connects human intent, agent identity, evaluated facts, policy version, risk evidence, deterministic result, and any later human resolution. Remove one link and the operator is forced to reconstruct authority from assumptions.

Start with the authority that existed

Suppose an operator gives a procurement agent a $2,000 monthly budget, allows software and office equipment, permits autonomous transactions up to $250, and requires review for every new merchant. The system should save the structured rule as a version with an activation time and actor.

If the operator later raises the autonomous limit, earlier requests must still point to the version that governed them. Otherwise a historical decision can appear justified by a rule that did not yet exist.

Record the request as facts

For a $96 Notion renewal, store the requesting agent, normalized amount and currency, merchant identity, category, country, merchant-novelty state, request time, and idempotency key. The raw agent explanation can provide context, but it should not substitute for the fields the policy engine actually evaluated.

Idempotency matters because agents retry. A repeated network request should retrieve the original result, not consume the budget twice or create two approval records.

Keep policy evidence and risk evidence separate

The policy trace might say the agent is active, the mandate is current, $1,904 remains, software is allowed, and $96 is below the autonomous threshold. The risk trace might note that Notion is a known merchant and the amount matches prior behavior.

These are different claims. Policy establishes permission; risk asks whether eligible behavior deserves additional scrutiny. Storing them separately prevents a single opaque score from hiding which business rule mattered.

Append the human action

For an $899 Apple request, policy could return APPROVAL_REQUIRED because the amount exceeds the autonomous limit and the merchant is new. If a reviewer approves it, save the reviewer, optional note, time, and scope of that approval. “Approve once” should mean this request only—not a silent merchant allowlist change.

The original result remains. The human action is a later, explicit resolution. That distinction is what lets an auditor answer both “what did the system decide?” and “what did the person decide afterward?”

Make the evidence usable

A hash-linked event log can make tampering more evident, but a useful interface must also translate identifiers and payloads into a readable sequence. Operators need the merchant, amount, agent, exact rule rows, risk factors, policy version, and actor—not just a digest.

The audit-evidence reference describes Mandate’s current MVP boundary and what production maturity would add.