Building a permission receipt layer inside an estate you do not own

The companion teardown on this site — "The evidence layer is the half nobody scopes, and the client discovers it at handover" — establishes the problem, and I am not going to re-argue it here. In one paragraph: a firm that inherits a client's estate, builds agents inside it and hands it back produces a great deal of evidence about what those agents did, and almost none about what they were permitted to do; the second fact is not recoverable from the first; and the moment it is asked for is reliably after the engagement has closed, the team has moved to another account, and the contractual instrument that would have required it was never written. This piece is about the artefact that would make authority a record rather than an inference, and it is written under the two constraints that make this sector's version of the problem different from a product vendor's: whatever you build has to go inside an estate you do not own and cannot migrate, and it has to keep working after every person who built it has gone.

I want to be honest about the scale of the claim before deriving anything. Nothing here is novel cryptography or novel architecture; the individual pieces are ordinary and several are older than the problem. What is missing is not a technique. It is the requirement that the artefact be produced at all, plus a deliverable specification that survives the people who wrote it. The commitment is the hard part, and it is contractual before it is technical.

What has to be true when the estate is not yours

Four constraints. The first two are shared with anyone building this primitive anywhere. The second two are specific to a firm that builds inside somebody else's system and then leaves, and they are the ones that eliminate the designs a product team would reach for first. Take them in order, because the eliminations compound.

First: the record has to be produced by the thing that decides, at the moment it decides. Any authority record assembled after the action is a reconstruction, and its accuracy depends on assumptions that decay silently — that the policy has not changed, that the evidence has not been garbage-collected, that the request context was fully captured. The standard everyone in this space builds against says outright why those assumptions fail. NIST Special Publication 800-207 establishes that access "is granted on a per-session basis" and that it "is determined by dynamic policy—including the observable state of client identity, application/service, and the requesting asset—and may include other behavioral and environmental attributes," with inputs it names as including "time/date of request, previously observed behavior, and installed credentials." A decision that is a function of inputs which mutate cannot be re-derived from a record written later. The only moment at which every input to the verdict is simultaneously in hand is the moment the verdict is reached.

Second: verification must not require anyone to ask you. If the only route to establishing what an agent was permitted to do runs through the firm that built the system, then the firm is in the trust path permanently, and the proof is worth whatever the reader thinks of the firm. That is tolerable for a support ticket and useless for the situations that actually generate the demand — a supervisory examination, a dispute with a counterparty, an incident review run by a party who has never heard of you. It is also, for a services firm specifically, a liability rather than an asset: a proof that requires your participation is a permanent, unpriced obligation attached to an engagement that has already been invoiced.

Third: no platform migration. The design attaches to what is already there, or it does not ship. This is the constraint a product vendor never faces and the one that most shapes the result. You do not get to choose the policy engine, the identity provider, the gateway or the log store; you inherited all four, they are load-bearing for systems you have never read, and the client's change-advisory process exists specifically to stop people like you from replacing them. Any design whose first step is "adopt our authorization service" is not a design, it is a proposal for a different engagement. What survives is a design that reads what the existing engine already produces and adds an artefact beside it.

Fourth: it has to be operable by people who have never met you. This is the one that eliminates the most designs and gets the least attention in architecture reviews. At handover the system passes to an operations team that did not build it, will not read its source, and cannot call you when it behaves oddly in fourteen months. Every dependency you take is a dependency they inherit. Every vendor account the verifier needs is an account someone has to keep paying for reasons nobody will remember. Every clever abstraction is a thing they will route around. The deliverable is not the running control alone; it is the running control plus a document a competent stranger can operate from, and the design has to be simple enough that such a document is short.

Put those four together and the shape is more or less forced. The decision point is whatever the client already runs, untouched. Beside it sits an adapter that reads the verdict the engine already returns and does nothing else. The artefact it produces is signed with a key the client holds from the first commit, commits to its inputs by digest rather than carrying them, and is verified by a program that runs on someone else's laptop with the network unplugged and no dependency the client has to renew. That is not a platform. It is roughly four files and a contract clause.

The standards already have the split. They stop one step short.

It is worth being precise about what exists, because the honest version of this argument is narrower than the version claiming nobody has thought about authority evidence. Several standards have. What none of them does is require a durable artefact of the decision.

Start with the architecture. NIST SP 800-207 breaks the policy decision point "into two logical components: the policy engine and policy administrator," places them on a control plane, and places the policy enforcement point that performs the action on the data plane. The separation this design advocates is not an innovation; it is the reference architecture's own model, and it has been for years. The gap is what crosses between the planes. In the same document's component description, the policy engine "makes and logs the decision (as approved, or denied), and the policy administrator executes the decision." The verdict is logged. The trust-algorithm inputs that produced it are not required to be retained. A binary approved-or-denied entry is the standard's own prescribed record, which is exactly why a firm inheriting a compliant estate finds a compliant estate that cannot answer the question.

The authorization model underneath it stops in the same place. XACML 3.0 — the vocabulary NIST SP 800-207 itself draws on for the policy decision point and policy enforcement point — defines the decision point as the entity that evaluates applicable policy and renders an authorization decision, and specifies a response context carrying a decision, a status, obligations and advice. It places no normative requirement on the decision point to persist or emit the attributes it consulted: the response goes back to the enforcement point, and the request context is not required to survive it. Obligations come closest to a durable side effect, and they are discharged by the enforcement point rather than retained as evidence of the decision.

NIST SP 800-53 Revision 5, the US federal control catalogue a great many North American estates are assessed against, has the same shape. NIST SP 800-53 Revision 5 control AU-10, non-repudiation, requires organisations to "Provide irrefutable evidence that an individual (or process acting on behalf of an individual) has performed [organisation-defined actions]." Read the object of that sentence. The control is scoped to proving that an action occurred; it does not require evidence that the action was authorised. The non-repudiation control in that catalogue is an effects control.

And the specification the sector is currently building agent integrations against is no different. The Model Context Protocol authorization specification, revision 2025-06-18, is strict about the token at the moment of use: servers "MUST validate that access tokens were issued specifically for them as the intended audience," they "MUST NOT accept or transit any other tokens," and an MCP server "MUST NOT pass through the token it received from the MCP client." Every one of those is a good requirement. None of them produces a record of the authorisation decision the server reached. Authority is checked and discarded.

I am asserting an absence, so I should say exactly how far it extends. Across NIST SP 800-207, NIST SP 800-53 Rev. 5, XACML 3.0, RFC 8693 and the MCP authorization specification at revision 2025-06-18, I could not find a requirement to emit or retain a signed artefact of an authority decision. That is a claim about those documents, not a claim about every product on the market, and it should be read as the former. If a standard requires the thing, I have not found it, and I would rather say so than cite something that nearly does.

The one place where the materials for a receipt already exist in a published specification is instructive, because they exist and are deliberately unused. RFC 8693, OAuth 2.0 Token Exchange, defines an "act" claim which "provides a means within a JWT to express that delegation has occurred and identify the acting party to whom authority has been delegated," and states that "A chain of delegation can be expressed by nesting one act claim within another," with the nested claims serving as a history trail. Then it constrains its own construct: "the consumer of a token MUST only consider the token's top-level claims and the party identified as the current actor," and prior actors identified by nested claims "are informational only and are not to be considered in access control decisions." The delegation chain is carried and explicitly not evaluated. It is audit material by design, and it is sitting inside a token format a great many estates already issue.

The claim set, and the block a platform design does not need

Every field in a hashed object should have to justify itself, because the object gets content-addressed and an addition re-derives every identifier ever issued. The platform-side version of this primitive uses one admission test: could an offline verifier reach the same verdict without this field? This design uses two, and the second is the sector's whole contribution — will this field still be meaningful after everyone who wrote the emitter has left the account?

The first test admits the familiar set. The principal exactly as the policy engine saw it, not a display name. The capability from a closed vocabulary, because free-text capabilities destroy replay when two spellings of one permission evaluate differently. The resource with its per-decision constraints, which belong in the receipt rather than the policy because they are frequently computed at request time. Both ends of the validity window, always, since a receipt carrying only an expiry cannot be distinguished from one back-dated afterwards. The delegation chain, attenuation-only, checked for shape and informational for the verdict per the RFC 8693 discipline. The policy bundle name, revision and digest of the exact bytes — the revision alone is insufficient, because revisions get reused, force-pushed and rebuilt. Digests of the inputs consumed, a determinism class, the determining rules as the client's own engine names them, and the verdict itself — both allow and deny, because a signed deny is genuine evidence that a request was made and refused.

The second test admits two things the platform version has no need for. An engagement identifier, because a client estate built by three firms across five years will hold receipts from three different emitters, and a verifier needs to know which specification revision governs the object in front of it. And a custody block: who holds the signing key, where the policy bundle bytes are archived, and under which retention class. Those are not cryptographic facts. They are the three assertions that decay first after handover, and putting them inside the signed object means a receipt carries, on its face, the claim that a named party was responsible for keeping it verifiable. When that claim stops being true, the receipt says so.

And a deliberate omission worth defending, because it will be the first thing an engagement lead asks to change. The receipt does not carry the evidence, only digests of it. Carrying the evidence would mean the receipt store holds copies of retrieved documents, membership snapshots and request payloads — which for a client in a regulated sector converts an audit artefact into a second copy of their most sensitive data, held in a system built by a vendor, retained for years. Commitment without disclosure is the trade. The failure-mode section is honest about what it costs, and the cost is real.

// @authority/receipts — the claim set, written for a build inside somebody else's estate.
//
// Two admission tests, not one:
//   1. Could an offline verifier reach the same verdict without this field?
//   2. Will this field still be meaningful once everyone who wrote the emitter
//      has left the account?
// A field failing either is a liability. The object is content-addressed, so any
// addition re-derives every identifier ever issued.

/** "sha-256:" followed by unpadded base64url. The only digest form v1 accepts. */
export type Digest = string;

/** RFC 3339 with a mandatory Z. Local offsets canonicalise differently. */
export type Timestamp = string;

/** One hop of delegation. Capabilities may only shrink from the previous hop. */
export interface DelegationStep {
  readonly principal: string;
  readonly capabilities: readonly string[];
  readonly grantedAt: Timestamp;
}

/** The policy is named and committed to, never carried. */
export interface PolicyRef {
  readonly bundle: string;
  readonly revision: string;
  readonly digest: Digest;
}

/**
 * Whether the verdict can be reproduced from what the receipt commits to.
 *  - "closed":   every input the policy read is digested in `evidence`
 *  - "external": the policy consulted live state not captured here
 * Policy that reads live state is "external", and SP 800-207 tenet 4 makes
 * dynamic inputs the expected case. A receipt that lies about this is worse than one that omits
 * it: a verifier will replay, diverge, and blame the wrong component.
 */
export type DeterminismClass = "closed" | "external";

/**
 * The handover block. Absent from a platform-side design of the same primitive
 * and mandatory here. A receipt whose keyHolder is the integrator stops being
 * issuable the week the engagement closes; one whose policyArchive is unnamed
 * stops being replayable the first time the client rotates a repository.
 */
export interface Custody {
  /** MUST be the client at handover. If it is your firm, you have built a leash. */
  readonly keyHolder: string;
  /** Where the exact policy bundle bytes are retrievable, and by whom. */
  readonly policyArchive: string;
  /** Named in the client's own retention schedule, not invented by the project. */
  readonly retentionClass: string;
}

export interface ReceiptClaims {
  readonly v: "authority.receipt/1";
  /** Which build emitted this, so a verifier knows which spec revision governs it. */
  readonly engagement: string;
  readonly principal: string;
  readonly capability: string;
  readonly resource: {
    readonly type: string;
    readonly id: string;
    readonly constraints: Readonly<Record<string, string | number | boolean>>;
  };
  readonly notBefore: Timestamp;
  readonly expiresAt: Timestamp;
  readonly delegation: readonly DelegationStep[];
  readonly policy: PolicyRef;
  readonly evidence: readonly Digest[];
  readonly determinism: DeterminismClass;
  /** Both are issued. Only "allow" is accepted at the gate. */
  readonly decision: "allow" | "deny";
  /** Rule identifiers as the client's own engine names them. Opaque to us. */
  readonly determining: readonly string[];
  readonly custody: Custody;
  readonly issuer: string;
  readonly issuedAt: Timestamp;
}

export interface Receipt {
  /** Content address of the canonical claims. Identical claims, identical id. */
  readonly id: Digest;
  readonly claims: ReceiptClaims;
  /** Ed25519 over the canonical claim bytes, base64url. Never over the id. */
  readonly signature: string;
}

The control path, through components you did not build

Eight steps. Two are new code; four run through components the estate already has, with one line added to each; the last two are the handover and the verification that happens without you. That ratio is the design, and it is the answer to the objection an engagement lead will raise first, which is that this sounds like a platform.

1. *The agent proposes; the estate's engine evaluates.* Unchanged. Whatever authorisation the client already performs, performs it. You were not asked for an opinion on their policy language.
2. *The adapter reads the verdict.* The decision, the determining rules, the bundle and its revision, and whether the evaluation touched anything outside the committed evidence. This mapper is the only component rewritten per estate, and it is small precisely because it does not decide anything.
3. *The issuer signs.* Claims assembled, canonicalised, hashed to a content address, signed with a key the client holds. The receipt exists before anything has happened in the world.
4. *The action proceeds, carrying the receipt id.* One header. This is the property that makes migration survivable: the action path gains a field, not a redesign, and removing the whole layer leaves a plain call behind.
5. *The gate refuses on absence.* At the enforcement point the estate already has. Signature, expiry, capability, resource scope. If any check fails, or there is no receipt at all, the action does not happen. Not logged-and-allowed. Refused.
6. *The effect log keeps doing its job.* The client's existing telemetry is untouched and now carries a receipt id, which is what turns two partial records into one complete one without either being rebuilt.
7. *The handover package is produced.* The verifier, the conformance vectors, the public keys, the retention schedule and a runbook. This is a step in the control path rather than a project artefact, because a receipt system whose verifier never leaves the delivery team's repository is a control the client does not have.
8. *Someone verifies, later, without you.* A third party holding a receipt, the named policy bundle and the evidence replays the decision and reaches the same verdict, or discovers they do not. They call nobody to do it.

The fatal inversion is between steps three and four. If the receipt can be produced after the action — even microseconds after, even in the same process — then it is a description of something that already happened, and the only thing its signature attests is that a component was willing to describe it that way. Every property in the design rests on the receipt existing, durably, before the effect does.

Step seven carries almost as much weight and is the one that actually gets cut. It has no technical dependency and no visible failure when omitted: the system runs identically without it, right up until the day the client needs to verify something and finds the ability to do so lives in a repository they were never granted access to. Engagements compressing under deadline compress here first, because the code works and the documentation is what you can defer.

Where this breaks

A design piece without an honest failure analysis is marketing. This is the longest section, ordered by how likely each failure is to bite.

You cannot enumerate the doors, because you did not build the house. This is the failure I would bet on, and it is worse here than in a platform. Every real estate has side paths: an administrative console, a break-glass credential, a batch job someone wrote before your firm was engaged, an integration whose owner left the client two reorganisations ago. Effects arriving through any of them have no receipt, and absence is indistinguishable from "the emitter was down" or "nobody instrumented that path." The moment absence is ambiguous, the presence of a receipt stops being evidence of authority and becomes evidence of instrumentation coverage. A product team owns its own surface and can at least enumerate it exhaustively. You are working from an architecture diagram that was accurate at some point. Fixing this is not a receipt-format problem; it is a discovery programme, and it is larger than everything else in this piece combined.

Key custody after handover is where the design most often inverts. The scheme's entire second constraint depends on the client holding the signing key. In practice the path of least resistance runs the other way: the integrator's build pipeline already has a key management setup, the client's does not, and provisioning theirs takes six weeks of a process nobody wants to start in week two. So the firm's key signs, temporarily, and temporarily becomes permanent. The result is a control that establishes only what the vendor was willing to assert, and a firm that has silently acquired a perpetual obligation to remain reachable. Worse, the failure is invisible at handover: everything verifies. That is why the custody block is inside the signed claims and why the verifier takes an expected key holder — so the divergence is a countable failure in a batch report rather than an observation someone might make.

Your own subcontractors are a hole exactly where the guidance predicts one. The interagency guidance for US banking organisations names the structural problem precisely: subcontracting "can result in risk due to the absence of a direct relationship between the banking organization and the subcontractor, further lessening the banking organization's direct control of activities." A firm that emits receipts from the components it wrote, while an offshore delivery partner or a specialist subcontractor writes components that do not, has built a system whose coverage map matches its own org chart rather than the estate. There is a working model for the fix and it is contractual rather than technical: DFARS 252.204-7012 requires the contractor to include the clause in subcontracts "without alteration, except to identify the parties," which is how a client's obligation reaches a party the client has no relationship with. A receipt scheme with no equivalent flow-down has a gap in the same place, and it will be discovered by whoever audits the subcontractor rather than by you.

Policy that reads live state does not replay, and the standard makes that the expected case. Policies that consult live state — current group membership, a remaining balance, a risk score computed at request time, the hour of the day — cannot be replayed to the same answer later, because the state moved. This is not an edge case a careful team designs around; SP 800-207's fourth tenet makes dynamic, observable-state-dependent policy the expected shape of a zero trust deployment. There are two honest responses and one dishonest one. Freeze every consulted input into the evidence set, which makes replay work and costs latency and storage. Or mark the receipt external and accept that verification establishes structure, signature, scope and timing but not the verdict. The dishonest response is to omit the determinism field and let verifiers read a divergence as fraud when it means Tuesday. That is why the field is mandatory.

An erasure duty and an evidence duty can pull in opposite directions, and India's statute makes it concrete. The DPDP Act 2023 requires a Data Fiduciary to "cause its Data Processor to erase any personal data that was made available by the Data Fiduciary for processing." A receipt commits to evidence by digest, which is the right design for confidentiality and creates a specific tension when the evidence is personal data subject to erasure: the digest survives, the evidence does not, and the receipt degrades from replayable to merely signed at exactly the moment someone might want to examine it. There is no clean resolution inside the receipt format. What the design can do is make the collision visible — the retention class is in the claims, so a receipt asserts on its face which schedule its evidence was held under, and a batch report can tell you how many receipts have outlived the data they commit to. Deciding what to do about that is the client's call and belongs in a policy document, not in a library.

The policy archive is the client's, and it is the first thing to rot. Replay requires the exact bundle bytes that produced the verdict. Those bytes live in the client's repository, under the client's retention practices, administered by a team that has no idea a signed artefact elsewhere depends on them. A repository migration, a rewritten history, a tooling change that reformats bundles on export — any of these silently converts a replayable estate into a signature-only one, and nothing notices. Naming the archive inside the claims makes the dependency legible, which is the most a library can do about an organisational fact.

Signed policy is not correct policy. The receipt proves a decision was made, by whom, under which rules, on what evidence. It says nothing about whether those rules were any good. A policy granting everything to everyone produces beautifully verifiable receipts. What the design buys is a change of subject: the argument stops being "trust the log" and becomes "here is the exact policy that was applied, argue with it." That is a real improvement and it is not correctness, and a firm selling it as correctness deserves the eventual conversation.

Acceptance closes over defects nobody has found yet. US federal acceptance doctrine is instructive about the shape of the risk even where it does not bind, and the asymmetry is worth reading carefully. FAR 52.246-2, the fixed-price supplies clause, provides that acceptance "shall be conclusive, except for latent defects, fraud, gross mistakes amounting to fraud, or as otherwise provided in the contract." I checked, and that sentence does not appear in FAR 52.246-4, the parallel services clause; do not attribute it to services work. What the services clause does say is that inspection records shall "be maintained and made available to the Government during contract performance and for as long afterwards as the contract requires" — a retention period with no floor at all, set entirely by whatever the statement of work happens to say. Both halves point one way: the window in which an evidence deliverable can be added is the window before acceptance, and the retention obligation you actually carry is whatever someone wrote into a document during a negotiation you may not have attended.

Compromise of the issuing key inverts everything. Whoever holds the client's signing key can mint receipts that verify perfectly, and every property becomes a property of the attacker's output. The mitigations are the usual ones and all partial: hardware custody, short-lived issuer keys with a signed key history, independent timestamping. None makes a stolen key harmless. They make one eventually visible, which is a weaker claim and should be stated as one.

And a short list of what the design simply does not address, offered so nobody discovers it during an incident. It says nothing about whether an agent's intent was appropriate — an agent manipulated into requesting a permitted action gets a valid receipt for it. It says nothing about the quality or provenance of the evidence, only that specific bytes were used. It does not detect a compromised decision point faithfully signing decisions it was tricked into making. It does not prove that no second, broader permission was issued quietly to the same principal at the same moment; that gap is what transparency logging exists for, and I have left transparency logging out of the first version because it provides nothing until there is issuance volume to misbehave. And it does not make an autonomous system safe. It makes one accountable, and those are different projects that get confused constantly.

What it costs

I have not benchmarked this implementation, so I will describe the shape of the cost and mark the measurements as planned rather than produce numbers I cannot stand behind.

Latency: the cryptography is almost certainly not the dominant term, and that is a prediction, not a result. Per decision the added work is one canonicalisation pass, one SHA-256 over a payload in the low kilobytes, and one signature over the same bytes. The prediction under test is that this is small relative to the durable write that must complete before the action proceeds. The measurement that would settle it is straightforward and belongs in the first fortnight of any engagement that adopts this: p50 and p99 of decide-to-receipt-durable on a fixed workload, run with and without the receipt path, with canonicalisation, hashing, signing and storage timed separately. Until that is run I would not quote a figure, and I would treat any figure quoted without that decomposition — mine or anyone's — as uninformative.

Volume is a design lever and it is the one that decides affordability. One receipt per authority decision, not per action and not per model call. What sets the bill is how coarsely a decision is defined. A grant covering an agent's whole session produces one receipt and a wide blast radius; a grant per tool call produces precise attribution and a great many receipts. Most estates will want something between, and this granularity choice deserves more design attention than the cryptography, because it is the parameter that cannot be changed later without re-deriving every identifier ever issued.

The operational burden is retention, and it is a records problem wearing an engineering costume. Replay requires the exact policy bundle bytes. That means every policy version ever decided under has to remain retrievable for as long as any receipt referencing it might be examined — a period measured in years and set by someone who does not report to engineering and may not report to the client's technology function at all. A team that ships receipts without answering the archive question has built a system that verifies beautifully for ninety days and degrades to signature-only afterwards. The same applies with more force to the evidence, and it is the single item on this list most likely to be discovered too late.

Migration is cheap for the format and expensive for the property, and the expensive half is political. Adding a receipt id header to an action path is a small change. Making an inherited gate refuse on absence is not, because it means enumerating every path that reaches a resource and either routing it through the gate or documenting it as an exception — in an estate whose paths you are still discovering, owned by teams who did not ask for this and whose change-approval process you do not control. The sequencing that works is a ratchet: emit in shadow and change nothing; then require on one capability class in one environment; then require by default with a published, shrinking exception list whose length is a metric someone at the client owns. What does not work is a flag that can be turned off under load, because it will be, at the exact moment the evidence would have mattered.

One piece of external context bears on whether this is worth doing now, and it points the opposite way from how it is usually read in delivery meetings. OCC Bulletin 2026-13, "Model Risk Management: Revised Guidance," issued 17 April 2026 — with the parallel Federal Reserve issuance SR 26-2 — supersedes SR 11-7 and SR 21-8. The OCC bulletin states, in its own wording, that generative and agentic AI models are "not within the scope of this guidance," and the agencies have said they plan to issue a request for information addressing model risk management generally and banks' use of AI in particular - a consultation step rather than a rule, which places the eventual specification further away rather than nearer - and it also states that it does not set forth enforceable standards or prescriptive requirements. Read as an exemption, that is a reason to descope the evidence layer and move on. Read as a deferral — which is what it is — it means nobody is going to hand this sector a control specification for agent authority in time for the systems already being built, and the eventual guidance will be written against whatever the industry has by then shipped. Every obligation attached to the underlying activity is untouched. What was removed is the framework that would have specified the controls.

The deliverable is a contract line before it is a codebase

This is the section that makes the difference between a well-built control and a well-built control nobody paid for, and it is the part of the design a technical audience most consistently skips. For a services firm, the question is not whether authority evidence is a good idea. It is whether the acceptance criteria say so, because everything else is a change order.

NIST SP 800-53 Rev. 5 control SA-4, acquisition process, is where this lives in the US control catalogue. It requires nine categories of requirement to be included "explicitly or by reference … in the acquisition contract," among them (e) "Security and privacy documentation requirements," (h) "Allocation of responsibility or identification of parties responsible for information security, privacy, and supply chain risk management," and (i) "Acceptance criteria." Read those three together from the delivery side. SA-4(i) is the exact line where an authority-evidence deliverable either is or is not specified; SA-4(e) is where the operating manual either is or is not a document you owe; SA-4(h) is where key custody stops being a design preference and becomes an allocated responsibility with a name against it.

For work inside a US banking organisation, the interagency guidance sets out what the client's own contract is expected to cover, and reading it as the vendor is more useful than reading it as the client. It is explicit that the duty does not move: "A banking organization is responsible for conducting its activities in compliance with applicable laws and regulations, including those activities involving third parties. The use of third parties does not abrogate these responsibilities." It extends the audit right through the prime to its subcontractors, noting that contracts generally include provisions "for periodic, independent audits of the third party and its relevant subcontractors," and it asks whether contract provisions "describe the types and frequency of audit reports the banking organization is entitled to receive." And it recommends that contracts stipulate that performance "is subject to regulatory examination and oversight, including appropriate retention of, and access to, all relevant documentation and other materials."

That last phrase is the one to sit with. "All relevant documentation" is defined nowhere and negotiated in the statement of work. Meanwhile the guidance's own named section on retention — covering the client's "ability to access its data in an appropriate and timely manner," access to the third party's data and supporting documentation, and how data may be shared with regulators as part of the supervisory process — is written around data and reports. Authorisation decisions are not enumerated as a class of retained information anywhere in it. So the obligation is broad, the enumeration is silent on the artefact, and the gap between the two is filled by whichever party thought about it during contracting.

The picture in India is sharper, because there the statute writes it down. The DPDP Act 2023 puts the duty on the client and makes it non-contractible: a Data Fiduciary "shall, irrespective of any agreement to the contrary or failure of a Data Principal to carry out the duties provided under this Act, be responsible for complying with the provisions of this Act," including in respect of processing undertaken on its behalf by a Data Processor, and it may involve a Data Processor "only under a valid contract." The Act also extends the security duty across the processor boundary: the Fiduciary must protect personal data "in its possession or under its control, including in respect of any processing undertaken by it or on its behalf by a Data Processor, by taking reasonable security safeguards." An Indian services firm is typically the Processor. Its entire obligation is the contract — and the statute says in terms that the words "irrespective of any agreement to the contrary" prevent the duty being pushed back the other way. That is an unusually clean commercial position to argue from: the client cannot delegate the duty, so what they can buy is the ability to discharge it, which is precisely what a verifiable authority record is.

The Reserve Bank of India's directions on outsourcing information technology services come closer than any other instrument I read to naming the artefact, and still stop short of it. The directions require the regulated entity's outsourcing agreement to provide effective access to the data, books, records, information, logs, alerts and business premises relevant to the outsourced activity; require a right to audit the service provider including its sub-contractors; require prior consent for sub-contracting; make the service provider contractually liable for the performance and risk management practices of its sub-contractors; and state that outsourcing shall not diminish the regulated entity's own obligations. It says logs. Logs are effects. The closest instrument in scope still describes the record this design exists to supplement rather than the record it produces.

One more comparison, because it shows what a real evidence-preservation obligation looks like when a regulator actually writes one, and it is instructive that even this one is scoped to effects. DFARS 252.204-7012, in its May 2024 form, requires a contractor to "preserve and protect images of all known affected information systems … and all relevant monitoring/packet capture data for at least 90 days," and requires the clause to be included in subcontracts "without alteration, except to identify the parties." Ninety days, named data classes, mandatory flow-down. That is what a drafted preservation duty reads like. Nothing comparable exists for authorisation decisions, in that instrument or in any other I read for this piece. The practical consequence for a firm is that this is a clause you propose rather than a clause you comply with — which is a weaker position rhetorically and a much stronger one commercially, since the specification is still yours to write.

None of which is confined to North America and India. The delivery pattern this piece is written for — a firm that inherits an estate, builds inside it, and hands it back to an operations team it will not staff — runs through the Gulf's capability-centre and national-programme work as much as through Charlotte or Bengaluru. The instruments differ; the structural exposure does not. The client will be asked to demonstrate authority, the firm that built the thing has left, and the artefact either exists from the first sprint or does not exist at all.

If you had a week

The temptation is to start with the emitter, because it is the part that produces something visible. That is the wrong order. Seven things, roughly in this sequence.

1. *Get the deliverable into the acceptance criteria, or stop.* One line naming the artefact, the verifier, the retention class and the key holder. If it cannot go in, everything below is unbilled work that will be descoped in week nine, and knowing that on day one is worth more than any code you could write instead.
2. *Freeze the claim set and the canonicalisation, and write conformance vectors for both.* A pinned set of claim objects with their expected canonical bytes and expected identifiers is what makes a second implementation possible — including the client's own, years later, in a language you did not choose. It costs an afternoon now against a migration nobody will fund.
3. *Write the verifier first, and ship it as the handover artefact from day one.* It is the deliverable and it defines what the other components must produce. If it cannot be written in a day, the claim set is wrong — either missing something a verifier needs or carrying something no verifier uses. Put it in a repository the client owns before it works, not after.
4. *Test the offline property, in CI.* Run the verification path with outbound networking disabled and fail the build if anything reaches for a socket. This is the property the entire design is sold on and the one most likely to be eroded by a well-meaning convenience feature in month four, long after anyone remembers why it mattered.
5. *Settle key custody before the first signature.* Whose key, held where, rotated by whom, and what the client does when it is compromised. This is a procurement conversation, it will take longer than the code, and starting it in the final fortnight is how the firm's key ends up signing in perpetuity.
6. *Emit in shadow from exactly one decision point, on one capability class, enforcing nothing.* You are measuring the shape of the volume, the size of the canonical payload, and how often the determinism class comes back external. I would expect that last number to be high, because dynamic policy is the expected case rather than the exception — but that is a prediction, it is what this step exists to measure, and it is the number most likely to change the plan.
7. *Only then, the gate.* One capability class, refusing on absence, in one environment, with the exception list published from day one. The exception list is the honest measure of how far the estate actually is, and it is the number to report to the client rather than the count of receipts issued.

What I would explicitly not do in the first week: build a transparency log, define a bespoke serialisation, or attempt to cover every capability at once. The first provides nothing until there is issuance volume to misbehave, the second is a standards project disguised as a sprint, and the third guarantees the gate ships behind a flag that never gets turned on.

Write the checker before the thing it checks, because the checker is what tells you whether the record is any good. Put it in the client's hands before it works, so it cannot be forgotten later. Settle who holds the key while there is still a procurement conversation happening. And measure progress by counting the doors that still bypass the system, not the receipts the system has produced.

Two claims are load-bearing for the whole design, and both are testable rather than rhetorical. The first: a competent third party, handed only a receipt, the named policy bundle and the evidence, reaches the same verdict as the original decision point without contacting anyone — including you. The second: a year after the engagement closes, an operator who has never met the delivery team can run the verifier from the runbook and get a result they can act on. A design failing the first may still be a useful improvement to a log. A design failing the second is a control that belongs to your firm rather than to your client, which for this sector is the only failure that actually matters.