Permission receipts for clinical and patient-data agents

The companion teardown on this site — "Minimum necessary is a decision, and decisions have to be reconstructable years later" — establishes the gap, and I am not going to re-argue it. In one paragraph: a clinical agent that retrieves records leaves an access log, and an access log answers what was touched. The duty that governs the retrieval is about scope, it attaches at the level of the individual use or disclosure or request, and it was discharged by a determination somebody or something made before the retrieval happened. That determination is not in the log. It can sometimes be inferred from the log plus the filter configuration plus the policy as it stands today, and each of those three inputs decays at a different rate. This piece is about the artefact that would make the determination a record instead of an inference, and it is written for the people who would have to ship it inside a hospital, a payer, a laboratory network or a sponsor's clinical data platform.

I want to set the scale of the claim honestly, because the argument is weaker if it is inflated. Nothing in the mechanism is novel. Content-addressed signed statements, deterministic serialisation, delegation chains, append-only logs — all of it is production technology borrowed from software supply chain and from capability systems that predate the current wave by a decade. What does not exist, so far as I can find in the rule text and the certification criteria, is any requirement that the authority decision be materialised at all, and any requirement that the action path refuse to proceed without it. The engineering here is ordinary. The commitment is not.

One framing note before the derivation. Every instrument cited below is American, because those are the ones whose text I have read against the publisher's own copy. The artefact is not. A hospital group in Bengaluru or a health authority in the Gulf faces the same structural problem — a duty about scope, discharged by a decision nobody wrote down. I make no claim about the contents of those jurisdictions' instruments, not having verified them; only that the design does not depend on which supervisor is asking.

The rules already split the two records

The most useful thing I can say about this design is that it is not an invention. Three American rulebooks that govern systems handling patient data already distinguish between the record of what happened and the record of who was permitted to make it happen. They distinguish them in the strongest way a regulation can: by enumerating them separately. What they do not do is require the second with the same force as the first, and that asymmetry is the entire opportunity.

The FDA's electronic-records rule has separated them since 1997. 21 CFR 11.10 lists the controls a closed system must have. Paragraph (e) requires "Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records," adding that "Record changes shall not obscure previously recorded information" and that the audit trail documentation be retained at least as long as the records it concerns. Paragraph (g), separately, requires "Use of authority checks to ensure that only authorized individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform the operation at hand." Two paragraphs, two obligations. The audit trail is scoped to entries and actions on records; it does not ask you to record the authorisation basis on which the action was permitted. The authority check is a control that must exist; it does not ask you to record its output. Between them sits a gap that nobody was required to fill because, in 1997, the authority check was a human clicking a button and the person was standing there.

The HIPAA Security Rule splits them too, and then makes the wrong half optional. 45 CFR 164.312(b) requires covered entities to "Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information." That duty attaches to activity — to effects. It is a standard, and standards are mandatory; the Required and Addressable labels attach to implementation specifications beneath them. The administrative counterpart at 164.308(a)(1)(ii)(D), information system activity review, is an implementation specification and is labelled Required: it obliges regular review of records of system activity, such as audit logs and access reports. Now look at the two specifications that come closest to materialising an authority decision. 164.308(a)(4)(ii)(B), access authorization, requires policies and procedures "for granting access to electronic protected health information, for example, through access to a workstation, transaction, program, process, or other mechanism." 164.308(a)(4)(ii)(C), access establishment and modification, requires policies and procedures that "establish, document, review, and modify a user's right of access." Both are Addressable. The rule mandates reviewing the record of effects and only addressably requires documenting the grant of authority.

And the certification criteria for health IT log the mutation of authority without logging its evaluation. The ONC criterion at 45 CFR 170.315(d)(2), auditable events and tamper-resistance, requires certified technology to record actions related to electronic health information per the referenced ASTM sections, plus changes to user privileges, audit log status changes and encryption status changes; recorded actions "must not be capable of being changed, overwritten, or deleted by the technology," and the technology must be able to detect whether the audit log has been altered. That is a serious integrity requirement and it is met by shipping products. Note precisely what is in scope: changes to user privileges — the mutation of the authority function. Not the evaluation of that function at each individual action. You will be able to show a reviewer when a role was granted. You will not be able to show them what the role resolved to at 03:14 on a Tuesday for one specific retrieval, which is the question an agent makes urgent.

A precision point worth stating because it is widely got wrong. The Security Rule does not specify a retention period for audit logs. 164.312(b) requires the audit control and says nothing about how long its output is kept. The six-year figure people attach to it comes from 164.316(b)(2)(i), which imposes six-year retention on the documentation required by 164.316(b)(1) — the written policies and procedures, and the records of required actions, activities and assessments — not on system audit logs as such. I have read both provisions and found no primary text extending the six-year clock to the logs. State it as: the rule mandates the control and leaves its retention unspecified. That is a stronger position than the folk version, and it is one of the reasons the receipt has to carry its own retention story rather than inheriting one.

What has to be true

Five constraints. Each eliminates a family of designs, and I want to take them in the order that makes the eliminations visible, because the interesting property of this problem is how little survives it. The first three are general to authority records; the last two are what this sector adds, and they are the ones that change the artefact rather than merely justify it.

First: the record must be produced by the thing that decides, at the moment it decides. Any record assembled afterwards is a reconstruction. It may be an accurate reconstruction, and often will be, but its accuracy depends on the reconstructor having the policy that was in force rather than the policy that is in force, an evidence set that has not been aged out, and a request context that was fully captured. All three decay, and they decay silently — nothing in the system announces that the inference has become unsound. The only instant at which every input to the verdict is simultaneously in hand is the instant the verdict is reached. Capture it there or do not capture it.

Second: the scope determination must be a stated field, not something a reader derives from configuration. This is where healthcare differs from a generic authorisation problem, and it is the constraint the whole design turns on. The duty at 45 CFR 164.502(b)(1) is that a covered entity or business associate "must make reasonable efforts to limit protected health information to the minimum necessary to accomplish the intended purpose of the use, disclosure, or request." That is not a duty to have a filter. It is a duty to have made a judgement about scope, per use, per disclosure, per request. A reviewer asking whether it was discharged is asking what the judgement was — and if your answer is "here is the query the agent ran, and here is the filter class it ran under, and here is the current version of the filter," you have handed them three artefacts and asked them to do the reconstruction themselves. Worse, you have made the answer depend on the edit history of a configuration file, which is the least defensible object in the building.

Third: verification must not require you to participate. If the only route to establishing what an agent was permitted to do is to ask the organisation that ran it, then that organisation is permanently in the trust path and the proof is worth what the reader thinks of them. That is adequate for an internal incident review and useless in the situations that actually generate demand. The corollary is that a query API over an audit warehouse does not satisfy this, however good the warehouse is, because its operator decides what the query returns. What survives is a self-contained artefact and a verifier that makes no network calls at all.

Fourth, specific to this sector: the horizon is years, and the clock does not start when you think it does. 45 CFR 164.528(a)(1) gives an individual the right to "an accounting of disclosures of protected health information made by a covered entity in the six years prior to the date on which the accounting is requested." The right has carve-outs — treatment, payment and health care operations among them — but for the disclosures it reaches, 164.528(b)(2) requires each entry to carry the date, the recipient's name and, if known, address, a brief description of the information disclosed, and "a brief statement of the purpose of the disclosure that reasonably informs the individual" of the basis for it. That last element is a reconstruction duty with a six-year tail: you must be able to say, years later, why. Then 164.316(b)(2)(i) requires retaining documentation "for 6 years from the date of its creation or the date when it last was in effect, whichever is later." Read the second clause carefully. The clock runs from retirement, not from creation. A policy version you supersede this afternoon can be the version you must produce in 2032. And in the provider setting, 42 CFR 482.24(b)(1) requires medical records to be retained "in their original or legally reproduced form for a period of at least 5 years." A design whose verification depends on infrastructure you will have replaced twice by then is not a design, it is a plan to be embarrassed.

Fifth, also specific to this sector: the reviewer may be opposing counsel, and use restrictions travel with the data. Two distinct pressures, and both bear on the artefact's shape. On the first: the Federal Rules of Evidence make self-authenticating a record "generated by an electronic process or system that produces an accurate result" on certification by a qualified person under Rule 902(13), and data "authenticated by a process of digital identification" under Rule 902(14), both effective December 2017. Cryptographic identification of a record is therefore already an established route to admissibility without live custodial testimony — the evidentiary system anticipates content-addressed, independently checkable records. On the other side of the same coin, Rule 37(e) of the Federal Rules of Civil Procedure provides that where electronically stored information that should have been preserved is lost because a party failed to take reasonable steps, a court may order curative measures on a finding of prejudice, and on a finding of intent to deprive may presume the lost information was unfavourable, instruct the jury accordingly, or enter default judgment. An unreconstructable authority record is not merely an audit finding. On the second pressure: 42 CFR 2.13(a) provides that substance use disorder patient records subject to Part 2 "may be disclosed or used only as permitted by the regulations in this part and may not otherwise be disclosed or used in any civil, criminal, administrative, or legislative proceedings conducted by any federal, state, or local authority." That restriction attaches to the data, not to the permission under which it was fetched. An agent that retrieves a chart under a treatment permission and reuses Part 2 content elsewhere has breached a duty that no access log is structured to evidence.

Take the five together and the shape is forced rather than chosen. The decision point emits, before the action, a signed artefact stating the minimum-necessary determination in its own words; naming its policy precisely enough that the exact bytes can be pinned; committing to its evidence by digest rather than carrying it, because carrying it would make the audit record itself a disclosure; carrying the delegation chain and any use restrictions that must propagate; and checkable by a program on a stranger's laptop with the network unplugged, years after the system that issued it was decommissioned.

What follows, and what has to be borrowed

Given the constraints, the components assemble themselves, and almost every one is borrowed from a domain that solved a version of this earlier. I would rather name the borrowings than present the result as invention.

Content addressing over a deterministic serialisation, so the record names a specific thing rather than a moving one. The established supply-chain pattern is to bind a signed claim to an artefact by digest rather than by name, so the artefact cannot change underneath the claim. Naming the policy by branch, or the evidence set by identifier, lets both drift; naming them by digest is what turns "this exact policy" into a checkable statement. That in turn forces a canonical form on the claim set, because without deterministic property ordering and constrained number handling two conforming implementations will produce two different identifiers for the same decision — and the scheme then fails in the least detectable way possible, passing one team's tests while silently disagreeing with another's in production. It is the first thing to freeze and the thing to write conformance vectors for.

A delegation chain, with the discipline that the chain is audit material and not an input to the verdict. The pattern is standard in token-exchange systems: the chain records how the current actor came to be acting, and the verdict is a function of the current principal and the capability set it holds. The chain does real work in this sector for a reason that has nothing to do with authorisation. 42 CFR 482.24(c)(1) requires that all medical record entries be "legible, complete, dated, timed, and authenticated in written or electronic form by the person responsible for providing or evaluating the service provided." The authentication duty is per-entry and names a responsible person. An agent writing into the chart does not discharge it. So the chain must be able to terminate in a natural person, and the gateway must be able to refuse a write whose chain does not.

Commitment without carriage, which here is a regulatory requirement rather than a privacy preference. In a multi-tenant platform, committing to evidence by digest rather than carrying it protects the tenant's policy from the platform. In a hospital it does something more basic: it keeps the audit record from becoming a second copy of the patient's information. If the receipt carried the retrieved documents, the care-team snapshot and the consent directives inline, then a receipt store would be a protected-information store, subject to the same duties as the chart, discoverable on the same terms, and requiring the same retention and destruction discipline. Digests give you the ability to prove what the decision was taken on without duplicating it. The cost of that choice is real and I treat it under failure modes.

Append-only logging, for the one question signatures cannot answer. A signed allow proves a decision was made and what it said. It does not prove that a second, quieter allow was not issued for the same principal on the same afternoon. The transparency-log pattern from certificate ecosystems answers this, and answers it honestly: the log does not prevent misissuance, it makes misissuance detectable by parties who care to look. Borrow the property and borrow the modesty about what it is. Build it last — it provides nothing until there is issuance volume for it to police.

The determination is a field, not an inference

This deserves its own section, because it is the difference between a generic authority receipt with a healthcare label on it and an artefact that answers the question this sector asks.

The regulation has already given us the vocabulary. 45 CFR 164.514(d)(2) operationalises minimum necessary as a function that must be defined in advance: a covered entity must identify "(A) Those persons or classes of persons, as appropriate, in its workforce who need access to protected health information to carry out their duties" and "(B) For each such person or class of persons, the category or categories of protected health information to which access is needed and any conditions appropriate to such access," then make reasonable efforts to limit access consistently with that determination. Class of person. Categories of information. Conditions of access. That is a three-part tuple, written by the rulemaker, describing exactly the thing a permission receipt would bind.

So the receipt carries it verbatim. Not a policy identifier from which the tuple could be looked up, and not a filter name that resolves to it in whatever version of the configuration happens to be deployed at read time. The determination object states the class the principal was treated as belonging to, the categories of information the determination admitted, the conditions attached, and the purpose in words that would satisfy 164.528(b)(2)'s requirement for "a brief statement of the purpose of the disclosure that reasonably informs the individual." Then it pins the policy version — bundle, revision and the digest of the exact bytes — so that a reviewer can check whether the stated determination is one the stated policy would in fact produce.

There is a design test embedded in this, and it is the most useful one I know for whether a claim set is right. A receipt for a disclosure should be sufficient on its own to generate the accounting entry 164.528(b)(2) requires: date, recipient, description, purpose. If generating it means joining back to three other systems, the claim set is missing something, and the missing thing is exactly what a reviewer will ask for.

One more field belongs here and it is the one teams will most want to omit. Whether the determination consulted anything outside the evidence it committed to. Call it the determinism class. If the policy read only the committed inputs, a verifier can replay it and either agree or disagree, and that is the strong case. If it consulted live state — current care-team membership, an open encounter, a consent directive that has since been withdrawn — then replay in year six will reach a different verdict for reasons that have nothing to do with anyone's conduct. Recording which of those two worlds you were in is what stops a future disagreement from being read as a discrepancy. It is also, I suspect, going to come back "external" far more often than teams predict, because care-team membership is precisely the kind of live state that clinical policy consults. That is a prediction, not a result; it is one of the things the shadow-mode measurement below exists to establish.

The claim set, field by field

Every field is present because a verifier lacking it could not reach the same verdict offline. That is the admission test and it is strict: the object gets hashed, so every addition changes every identifier ever issued, and a field added for convenience is a migration you will regret in a regulated archive.

• *principal* — the acting identity exactly as the policy engine saw it. The string the policy matched on, not a display name and not a session identifier. A verifier that cannot reconstruct the subject cannot replay.
• *capability* — the operation authorised, from a closed vocabulary the entity controls. Free-text capabilities destroy replay, because two spellings of the same permission evaluate differently.
• *resource* — type, identifier and the scope expression attached to this grant. Per-decision constraints belong here rather than in the policy, because they are frequently computed: a date window derived from an encounter, a section filter derived from the question being answered.
• *determination* — the minimum-necessary object: class of persons, categories, conditions, purpose, and the basis on which the use or disclosure was permitted. This is the field the sector adds, and it is the reason the artefact is worth building here first.
• *minimumNecessaryApplies* — recorded, not inferred. Whether the standard was treated as applying to this use is itself a determination the entity's policy makes, and a receipt that silently assumes an answer is a receipt that hides the interesting part.
• *disclosure* — null for an internal use; otherwise the recipient and, where known, the address. This is what makes the accounting-entry derivation mechanical rather than a reporting project.
• *useRestrictions* — restrictions that travel with the data rather than with the permission. Part 2 material is the canonical case. Each restriction states whether it propagates to receipts derived from this one, and in version one they all do.
• *notBefore / expiresAt* — the validity window, both of them, always. A record carrying only an expiry cannot be distinguished from one back-dated afterwards.
• *delegation* — the ordered chain, each hop carrying its own capability set and a flag marking whether that hop is a natural person accountable under the record-authentication duty. Attenuation-only, checked by the verifier, informational for the verdict.
• *policy* — bundle, revision, digest of the exact bytes, and the date the version last was in effect. That last field is not decoration: it is what tells an archivist when the retention clock for those bytes actually starts.
• *evidence* — digests of every input the decision consumed that is not already in the claims, each with the custodian expected to hold the preimage. Naming a custodian is not a promise that the preimage survives; it is a statement of who to ask, which is the most the artefact can honestly offer.
• *determinism* — committed or external, as above.
• *decision* — allow or deny. Both are issued; only allow is accepted by the gateway. A signed deny is genuinely useful evidence that a request was made and refused, and discarding it leaves you unable to prove restraint.
• *determining* — identifiers of the rules that drove the verdict, in whatever form the policy engine names them.
• *issuer / issuedAt* — who signed and when, so key rotation and the validity window can be reasoned about together across a horizon measured in years.
• *parent* — for the loop case: the identifier of the task-level receipt this per-action receipt hangs from. The tension this field manages is discussed under failure modes and it is not fully resolved.

// @authority/receipts — the clinical claim set.
//
// Admission test for every field: could an offline verifier, holding only this object
// plus the policy bytes and the evidence preimages, reach the same verdict? If not, the
// field does not belong here. The object is hashed, so an addition changes every
// identifier ever issued.

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

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

/**
 * The vocabulary of 45 CFR 164.514(d)(2): persons or classes of persons, the categories
 * of information they need, and the conditions appropriate to that access. Stated in the
 * receipt rather than looked up from a filter, because a filter's edit history is not a
 * determination.
 */
export interface MinimumNecessaryDetermination {
  /** The workforce class the policy matched — the class, not the individual. */
  readonly classOfPersons: string;
  /** Categories of information admitted, from a closed vocabulary the entity controls. */
  readonly categories: readonly string[];
  /** Conditions attached to this access: encounter scope, date window, section limits. */
  readonly conditions: readonly string[];
  /** Purpose in words that would satisfy 164.528(b)(2)'s "reasonably informs" test. */
  readonly purpose: string;
  /** Set when a standing rule produced the determination rather than a case-by-case call. */
  readonly standingRule?: string;
}

/** Why the use or disclosure was permitted. Deliberately open: entities differ. */
export type PermissionBasis =
  | { readonly kind: "treatment" }
  | { readonly kind: "payment" }
  | { readonly kind: "operations" }
  | { readonly kind: "individual-request" }
  | { readonly kind: "authorization"; readonly authorizationId: string }
  | { readonly kind: "required-by-law"; readonly citation: string }
  | { readonly kind: "research"; readonly protocolId: string }
  | { readonly kind: "emergency-override"; readonly attestedBy: string };

/**
 * A restriction that travels with the data rather than with the permission. 42 CFR Part 2
 * material is the canonical case: it may be lawfully retrieved and still not lawfully
 * reused. `propagates` is true for every restriction v1 knows about; the field exists so
 * that a later non-propagating restriction does not require a claim-set migration.
 */
export interface UseRestriction {
  readonly regime: string;
  readonly scope: string;
  readonly propagates: boolean;
}

/** 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;
  /**
   * True only for a natural person who can discharge the per-entry authentication duty at
   * 42 CFR 482.24(c)(1). A write whose chain contains none of these is refused.
   */
  readonly responsibleIndividual: boolean;
}

/** The policy is named and committed to, never carried. */
export interface PolicyRef {
  readonly bundle: string;
  readonly revision: string;
  readonly digest: Digest;
  /**
   * Null while the version is in effect; set on retirement. 45 CFR 164.316(b)(2)(i) runs
   * its retention clock from "the date when it last was in effect, whichever is later",
   * so this field is what tells an archivist when the clock actually starts.
   */
  readonly lastInEffect: Timestamp | null;
}

/** Committed, not carried. Naming a custodian says who to ask, not that they still have it. */
export interface EvidenceCommitment {
  readonly kind: string;
  readonly digest: Digest;
  readonly custodian: string;
}

/** Whether the decision read anything outside the evidence it committed to. */
export type DeterminismClass = "committed" | "external";

export interface ReceiptClaims {
  readonly v: 1;
  readonly principal: string;
  readonly capability: string;
  readonly resource: {
    readonly type: string;
    readonly id: string;
    readonly scope?: string;
  };
  readonly determination: MinimumNecessaryDetermination;
  readonly basis: PermissionBasis;
  /** Recorded, never inferred. See the commentary. */
  readonly minimumNecessaryApplies: boolean;
  /** Null for an internal use; populated for a disclosure. Drives the accounting entry. */
  readonly disclosure: {
    readonly recipient: string;
    readonly recipientAddress?: string;
    readonly description: string;
  } | null;
  readonly useRestrictions: readonly UseRestriction[];
  readonly notBefore: Timestamp;
  readonly expiresAt: Timestamp;
  readonly delegation: readonly DelegationStep[];
  readonly policy: PolicyRef;
  readonly evidence: readonly EvidenceCommitment[];
  readonly determinism: DeterminismClass;
  readonly decision: "allow" | "deny";
  readonly determining: readonly string[];
  readonly issuer: string;
  readonly issuedAt: Timestamp;
  /** Task-level receipt this per-action receipt hangs from, for agent loops. */
  readonly parent?: Digest;
}

export interface ReceiptSignature {
  readonly alg: "ed25519";
  readonly keyId: string;
  /** base64url over the domain-separated identifier. */
  readonly value: string;
}

export interface PermissionReceipt {
  readonly id: Digest;
  readonly claims: ReceiptClaims;
  readonly signature: ReceiptSignature;
}

/** Domain separation, so a receipt identifier can never be replayed as some other signature. */
export const SIGNING_DOMAIN = "authority-receipt-v1:" as const;

/** Capabilities that mutate the designated record set, and therefore need a human in the chain. */
export const WRITE_CAPABILITIES: ReadonlySet<string> = new Set([
  "chart.note.create",
  "chart.note.amend",
  "order.place",
  "problem.update",
]);

The control path

The ordering is the design. Everything else is detail that could be argued either way; the sequence is the property under test, and it is the thing that makes the artefact a record rather than a report.

1. *The agent forms an intent, not a query.* What gets authorised is "read this patient's record to answer this question", not the FHIR search that eventually results. This matters because the minimum-necessary determination is about the purpose, and the purpose lives in the intent.
2. *The decision point evaluates the determination* against a pinned policy version, on evidence it commits to by digest — the care-team membership snapshot, the applicable consent directives, whatever else the policy consults. It records whether it consulted anything it did not commit to.
3. *The issuer canonicalises, hashes and signs.* The receipt exists before any record is touched. If it does not, everything downstream is a reconstruction with better formatting.
4. *The receipt identifier travels on the request.* The policy does not travel with it, and the evidence is not carried, only committed to. What crosses the wire is an identifier and a signature.
5. *The gateway checks and refuses on absence.* Signature, window, capability, resource scope, use restrictions. Refusing on absence is what makes the receipted path the only path; a gateway that logs a warning and proceeds has built a dashboard, not a control.
6. *The read executes and the existing audit trail records it, unchanged.* Nothing about the current record of effects is replaced. A column is added beside it. That is worth emphasising to anyone who has to fund this: it is additive, so it does not put a certified system's existing conformance at risk.
7. *Use restrictions propagate onto every derived receipt.* If the retrieval returned Part 2 material, the restriction attaches to the summary the agent writes, the message it drafts, and the record it hands to the next step.
8. *A write requires a responsible human at the end of the chain.* The chart entry must be authenticated by the person responsible for the service; the agent's chain must terminate in one, and the gateway refuses if it does not.
9. *Years later, a reviewer replays offline.* Receipt, policy bytes, evidence set, and a program. They reach the same verdict or they do not, and either outcome is informative. What they do not need is you.

Where this breaks

A design piece with no honest failure analysis is marketing. These run in rough order of how likely they are to bite, and the first matters most.

Gate the emergency path and you will hurt someone. 45 CFR 164.312(a)(2)(ii), emergency access procedure, is a Required implementation specification, and it is required for an obvious reason: a clinician who needs a chart in a resuscitation needs it now, and any system that stands between them and it has failed at something more important than audit. A naive reading of this design — the gateway refuses actions arriving without a valid receipt — applied to break-glass access, produces a system that is unsafe. So the emergency lane must invert: it emits a receipt marked as an override, attributing the attestation to the person who invoked it, and it is never blocked by receipt validation. That receipt makes no replay claim, because there was no policy evaluation to replay. It records that a human took responsibility at a named moment. That is worth having, and it is a categorically weaker artefact than the ordinary case, and pretending otherwise would be the exact kind of overclaim this whole design exists to avoid. If you build the gateway before you have designed the emergency lane, you have built the wrong thing in the wrong order.

A signed determination is not a correct determination. The receipt proves that someone decided the scope was minimum necessary, on a stated policy, on stated evidence, before acting. It does not prove the scope was minimum necessary. A policy that grants the whole chart to every class of person produces perfectly valid receipts all day. What the artefact does is convert an unanswerable question into an answerable one and move the argument onto the policy, where it can be had. That is progress and it is not compliance, and anyone selling it as compliance is selling something else.

Digests commit without preserving, and here the preimage is the problem. This failure mode is sharper in healthcare than anywhere else I have thought about it. Committing to evidence by digest means that if the preimage is gone, the receipt degrades to proof that a decision was taken on something with a particular hash — which establishes integrity and nothing about content. In other domains you fix that by keeping the preimages. Here you may be forbidden to. Evidence sets contain protected information; other duties, including state law and research participants withdrawing consent, may require destroying exactly the thing the digest commits to. So there is a real, structural tension between the artefact's replayability and the estate's minimisation and destruction obligations, and I do not think it fully resolves. What you can do is be deliberate: decide per evidence class whether the preimage is retained, record the custodian in the receipt so the question is at least addressed to someone, and accept in advance that some receipts will verify but not replay. What you cannot do is discover this in year four.

Policy that consults live clinical state does not replay. Care-team membership changes. Encounters open and close. Consent directives are granted and withdrawn. A minimum-necessary policy that consults any of these is reading state that will not be the same at replay time, and a verifier in year six will reach a different verdict for reasons that have nothing to do with anyone's conduct. The determinism field makes this visible rather than fixing it. Fixing it means committing snapshots of that state as evidence, which increases receipt size and drags more protected information into the commitment set, which runs straight back into the previous failure mode. I would expect the external class to be common in real clinical policy; that expectation is not a measurement, and it is one of the things the shadow-mode run below is for.

Agent loops make the unit of authorisation genuinely ambiguous. An agent retrieves, reasons over what it found, and retrieves again on the basis of what it learned; the scope of the second retrieval was set partly by the contents of the first. One receipt per retrieval means the count tracks the agent's reasoning, and the volume is unbounded in a way nobody has budgeted for. One receipt per task means the stated scope must be a superset of everything the agent might need, and a superset determination is a weaker minimum-necessary claim — arguably weak enough to defeat the purpose. The parent field manages the tension by letting per-action receipts hang from a task-level one, so volume is per-action while purpose is stated once. It manages the tension; it does not dissolve it. Someone still has to decide how wide the task-level scope may be, and that decision is doing more work than the design admits.

One unreceipted interface makes the whole thing decorative. Healthcare estates are worse than most here. The paths into the record set are many and the modern ones are the minority: FHIR endpoints, yes, but also HL7 v2 interfaces built in the last century and still load-bearing, nightly extracts to the reporting warehouse, vendor support tooling with its own access model, a research data mart, an exchange connection, and whatever the imaging estate does. If any of those reaches the data without a receipt, the honest measure of the programme is not how many receipts were issued but how many doors remain unreceipted — a number to publish from day one, because a coverage claim without a denominator is one of the commonest ways an assurance system lies.

Part 2 propagation is only as good as the tagging underneath it. The design carries a use restriction forward onto derived receipts. It cannot manufacture one the source system never recorded. If the record does not distinguish Part 2 content from the rest of the chart — and segmentation of this kind is genuinely hard — a receipt will faithfully record the absence of a restriction that should have been there. The artefact makes the restriction traceable once it exists; it does not create the segmentation. A programme that assumes otherwise has moved a data-modelling problem into a cryptography project, where it will not be solved.

A signed allow does not prove no other allow was issued, and keys do not survive by themselves. Two smaller ones together. The first is answered by the transparency log, and only partially: it gives you detection, not prevention, and only for parties who look. The second is unglamorous and will be the thing that actually bites. Verifying in 2032 a signature made in 2026 requires the verification key, its rotation history and a runnable implementation of the algorithm to still exist and be locatable. Archival guidance in the trial world gestures at this — ICH E6(R3), which is guideline rather than regulation, says at section 4.2.7 that trial data and relevant metadata should be archived so they remain retrievable and readable and "protected from unauthorised access and alterations throughout the retention period". Key material is metadata in exactly that sense. Someone has to own it, and it will not be the team that built the issuer, because that team will have been reorganised twice.

What it costs

I have not measured any of the following in a clinical estate, and I say so in each place rather than once at the end, because a cost section with unmarked estimates is how a design piece launders a guess into a figure.

Latency: one canonicalisation, one hash, one signature per decision. That is the added work on the critical path, and in the abstract it is small. What I cannot tell you is what it costs in a real deployment, because the added latency is dominated not by the cryptography but by whatever the decision point must fetch in order to commit to its evidence — entirely a function of how the policy is written. The measurement is planned and its design is simple: shadow-mode over a representative mix of retrievals, recording the delta at the median and the ninety-ninth percentile between the existing authorisation path and the same path with issuance included. Nobody should accept a number for this from a design document, including this one.

Storage: dominated by the determination and the evidence array, not by the signature. A receipt is a small object, but there is one per action and the horizon runs to years. Size is driven by how many evidence commitments the policy makes and how verbose the conditions list is. I have not measured the distribution and will not guess at it; the same shadow run yields it directly, and a fortnight of it will tell a team more than any estimate here could.

The real cost is the archive, and it is not an engineering cost. Policy bundles addressed by digest, retained on a clock that starts when the version last was in effect rather than when it was written. Evidence custody decided per class, with the destruction duties reconciled against it. Verification keys and rotation history held for the same horizon. None of that is code. All of it needs an owner with a name, and in most organisations it will take longer to establish that ownership than to build the package. If I had to predict where a programme like this stalls, it is here, and it stalls quietly.

Migration: the gateway is the hard part, and the record system may not be yours. Placing a gateway in front of a FHIR endpoint is a solved problem. Placing one in front of an HL7 v2 interface engine, a nightly extract and a vendor's own support access is not, and in most provider estates the record system is a product you licence rather than a service you operate. That constraint deserves its own treatment and gets it elsewhere on this site, in the piece on issuing receipts across an estate you do not own. The short version: coverage will be partial for a long time, the exception list is the honest artefact, and a programme that cannot tolerate publishing an exception list is not ready to start.

There is also a research question underneath all of this that I want to name rather than paper over, because it is the number that would settle the argument. What fraction of an agent's actions can have their authorising decision correctly reconstructed from logs alone, as a function of elapsed time and of how much the policy has churned in between? I searched for a primary published measurement of this — in healthcare and outside it — and did not find one. Not a soft one I chose not to cite; none I could verify against the study itself. So the honest position is that the quantity is unmeasured. That is a weaker claim than a percentage would be and a considerably more defensible one, and it is also an invitation: the experiment is not hard to run inside a single estate, and whoever runs it first will have said something nobody has said.

If you had a week

The temptation is to start with the gateway, because it is the component that visibly changes behaviour. That is the wrong order and in this sector it is a dangerous one. Six things, roughly in sequence.

1. *Write the accounting derivation first.* Before the issuer, before the verifier, before anything. If a receipt cannot mechanically produce the four elements of a 164.528(b)(2) entry, the claim set is wrong, and you will have discovered that in an afternoon rather than during a request you are obliged to answer within a deadline.
2. *Then the verifier, and test its no-network property in the build.* It is the deliverable and it defines what the other components must produce. Add a test that runs the verification path with outbound networking disabled and fails the build if anything reaches for a socket.
3. *Freeze the claim set and the canonical form, with conformance vectors.* A pinned file of claim objects with their expected canonical bytes and expected identifiers is what makes a second implementation possible. It costs an afternoon now against a migration across a multi-year archive later.
4. *Design the emergency lane before you design the gateway.* Write down exactly what break-glass emits, who attests, what claim the resulting receipt does and does not make, and how it is reviewed. Do this while the gateway is still a diagram, because once the gateway exists the temptation to route the hard case through it will be considerable.
5. *Shadow-emit from one decision point, on one capability class, enforcing nothing.* You are measuring three things: the volume, the size distribution, and how often the determinism class comes back external. That third number will shape the plan more than the other two.
6. *Answer the archive question, then the gateway.* Where policy bundles live and for how long, which evidence classes retain preimages, who owns the keys. Then the gateway, on one capability class, in one environment, refusing on absence, with the exception list published from the first day.

What I would explicitly not do in week one: build the transparency log, attempt the HL7 v2 interfaces, or try to cover every capability at once. The first provides nothing until there is volume for it to police, the second is a quarter of work disguised as an integration, and the third guarantees the gateway ships behind a flag that never gets turned on.

Two claims carry the whole design and both are testable rather than rhetorical. The first: a competent stranger, holding only a receipt, a policy bundle and an evidence set, reaches the same verdict as the original decision point without contacting anyone and without a witness. The second: the record shows what the scope determination was, in the rule's own vocabulary, rather than what a filter would produce if you ran it again today. A design that fails either may still be a genuine improvement on an access log, and it is not a permission receipt. Both are properties you can write a test for, which is the strongest argument I have for specifying it this way rather than describing it.