Minimum necessary is a decision, and decisions have to be reconstructable years later

What follows opens on a constructed illustration. It is not client work, not an incident report, and not a description of anything that occurred. It is assembled from primitives any clinical informatics or payer-side engineering lead will recognise, because the argument needs a trace concrete enough to check against your own estate — and inventing a breach to make a point would be exactly the behaviour this site argues against.

A utilisation management team runs an agent that assists prior-authorisation review. It is unglamorous and it works. A request arrives, the agent pulls the relevant clinical history for the member, assembles a structured case summary against the applicable coverage criteria, and hands the packet to a nurse reviewer who makes the determination. The agent does not decide anything clinical. It reads, it summarises, and it drafts. On a Tuesday morning it reads sixty-one records across one patient's chart — encounters, medication history, problem list — and produces a two-page summary. The nurse approves the request in four minutes instead of forty. Everyone involved considers this a good day.

Two years later, that access is questioned. The specific route does not matter much for the argument — a member complaint that escalates, a state regulator's inquiry into a denial pattern, a plaintiff's discovery request in a coverage dispute, an internal audit sampling the pilot period. What matters is the shape of the question, which is always the same shape: *on what authority was this record set read, and who determined that reading all of it was the minimum necessary?*

The estate answers the first half beautifully. The access log is intact and nothing was deleted. It holds the sixty-one record identifiers, the service account that read them, the query that returned them, timestamps to the millisecond, bytes returned, latency, retry count. The team can reconstruct the read to a degree that would have been impossible fifteen years ago. This is a well-instrumented system, and the people who instrumented it were not careless.

The second half of the question has no answer anywhere in the estate. Minimum necessary was enforced — genuinely enforced, not nominally — by a filter clause in the retrieval query that limited the agent to record categories tied to an open prior-authorisation case. That clause has since been edited eleven times. Some edits narrowed it after a privacy review. One widened it during a throughput incident and was narrowed back three weeks later. Two were refactors that changed the code without changing the semantics, and one of those quietly changed the semantics anyway. The repository has all eleven commits, with reviewer names and dates. What it does not have is any binding between a commit and a read. Nothing in the system ever wrote down which revision the evaluator had loaded when those sixty-one records came back, or what condition the filter was testing at that moment, or what purpose the calling workflow declared.

So the honest answer the team can give is: the filter as it stands today would not have permitted a read that broad, the filter as it stood at some point during that quarter might have, and we cannot tell you which was loaded on that Tuesday. That answer is truthful, technically competent, and useless — and in a proceeding it is considerably worse than useless, because it is indistinguishable from the answer a team would give if the access had in fact been out of scope.

The objection, at full strength

There is a serious case that all of this is a manufactured problem, and it deserves stating properly, because the version experienced healthcare engineers actually hold is a great deal better than the strawman version.

It runs like this. Minimum necessary is not a per-query proof obligation. The standard at 45 CFR 164.502(b)(1) requires a covered entity or business associate to “make reasonable efforts to limit protected health information to the minimum necessary to accomplish the intended purpose of the use, disclosure, or request.” Reasonable efforts is a standard about design and diligence, not about instance-level evidence. The way you discharge it is exactly the way this team did: you define role-based access consistent with 164.514(d)(2), you implement it as a technical control, you review it, you document the review, and you retain the documentation. The organisation demonstrates compliance by showing the control existed, was designed against a stated determination, and was subject to review — not by producing a per-access certificate. Demanding a receipt for every read is the security theatre of people who have never run a hospital's identity estate, where a nurse in an emergency department may legitimately touch hundreds of charts a shift and where a break-glass path has to exist at all.

The objection continues, and gets stronger. Reconstruction is not actually impossible in the illustration above — it is merely tedious. The repository has eleven commits with timestamps. The deployment system knows when each build shipped. Correlate the two and you can bound which revision was live on that Tuesday to a narrow window, probably to a single revision. Sophisticated teams already do this in incident review, and it works. Adding an authorisation receipt to every tool call in a clinical agent stack means adding a write to the hot path of a system that already struggles with latency at peak, generating an enormous volume of records that are themselves protected health information, subject to their own retention and access obligations, and creating a new and attractive target. The cure looks worse than the disease.

Both halves are correct as far as they go, and the second half is correct in a way that should genuinely constrain any proposed architecture. Take them in order.

Reasonable efforts is a standard about conduct, and conduct has to be shown. The reasonable-efforts framing is right about what the duty is and wrong about what discharging it requires when the actor is an agent. Read where the duty attaches: 164.502(b)(1) binds the covered entity “when using or disclosing protected health information or when requesting protected health information from another covered entity or business associate.” Per use. Per disclosure. Per request. That is not a policy-level obligation that happens to be implemented per request — it is written at the granularity of the individual act, and an agent's whole architectural character is that it generates acts at machine rate under a scope that no human inspected at the moment of the act. When a nurse touches two hundred charts a shift, the reasonable-efforts story has a human in it whose role, training and clinical relationship supply the context. When a service account touches two hundred thousand records a month under a filter clause, the filter clause is the entire story, and the filter clause is the thing nobody wrote down.

Correlating commits to deploys is inference, and inference is what the reviewer is testing. The reconstruction argument is the one worth dwelling on, because it is the one most teams quietly rely on. It fails not because the correlation is hard but because of what it produces: an argument, assembled after the fact, by the party with an interest in its conclusion, from artefacts that were not created for the purpose and were not protected against the possibility that they would be needed. A commit history and a deploy log tell you what was probably running. They do not tell you what the evaluator loaded — configuration overrides, feature flags, a cached policy bundle, a per-tenant override, a hot-fixed environment variable all live outside the repository. And the reviewer is not obliged to accept your reconstruction. They are entitled to test it, which converts a factual question into a credibility contest between your engineers and theirs.

The third part of the objection — that receipts add latency, volume and a new store of sensitive data — is not answered here at all, because it is a design constraint on the solution rather than a defence of the status quo. It is also the constraint that most obviously determines whether any such architecture is deployable, and it belongs in the companion piece where it can be engineered against rather than gestured at.

Why an authorisation leaves no residue

The reason this is structural, and not a thing somebody will patch in the next release of a framework, is a difference in physical kind between the two things being asked about.

An effect is a change in the world. A row is read, a value is written, a message is sent, a claim is adjudicated. Effects have residue by construction: the row was read, so the storage engine touched a page, the network moved bytes, the row appeared in a response. Instrumenting an effect means observing something that necessarily happened. That is why effect logging is a solved discipline and why the access log in the illustration is excellent — it is downstream of a physical event.

An authorisation is not a change in the world. It is a predicate evaluated over system state: given this principal, this resource, this context, this policy, is this permitted? The evaluation consumes inputs and returns a verdict. If the verdict is permit, the caller proceeds, and the resulting effect is bit-for-bit identical to the effect that would have been produced had no permission system existed at all. If the verdict is deny, the most common outcome is that nothing happens — and nothing happening is exactly what leaves no trace. The permission system's success case and its absence are observationally equivalent downstream.

This is the whole of it. Authority is not a thing that occurs; it is a property that holds. Properties that hold do not deposit sediment. If you want a record of one, something has to decide, deliberately, to emit it — and emission is a design act that nobody in the stack currently performs, because every layer reasonably assumes some other layer is the system of record for it.

The distributed-systems version of the same point is worth stating for anyone who wants to argue that better logging would have caught it. The authorisation verdict is a value in a stack frame. Its lifetime is the duration of the call. It is not persisted because persisting it has no function in the computation — the value is consumed the instant it is produced, and the runtime is correct to release it. Nothing has gone wrong. The garbage collector is not misbehaving. A system that discards the verdict is a correctly implemented system, which is precisely why no amount of engineering discipline within the current design surfaces the omission. You do not find this bug by testing, because it is not a bug.

Five arguments, five decay schedules

It would be convenient if the missing item were a single scalar — a scope string that could be stamped onto the log line and be done with. It is not. The determination is a function of at least five arguments, and each one decays on a different clock after the call returns. That is what makes reconstruction asymptotically hopeless rather than merely laborious.

1. *The policy version the evaluator actually loaded.* Not what is in the repository — what the running process had in memory, including overrides, flags and cached bundles. In the illustration this is the query filter, edited eleven times in place, because a filter clause embedded in retrieval code is not a policy artefact with a lifecycle; it is a line of code.
2. *The scope bound to the principal at that moment.* Role bindings on service accounts are mutable and are routinely rewritten at access reviews. The binding that existed on the Tuesday is overwritten by the binding that exists at the next quarterly review, and identity systems generally keep a change log of the binding rather than a snapshot resolvable to an instant.
3. *The request context handed to the evaluator.* Purpose of use, the case identifier, the requesting workflow, the member relationship. This is the argument with the shortest half-life of all: it is a parameter, it exists only for the duration of the call, and no component in the path has any reason to write it anywhere.
4. *The delegation depth.* Whether the read was made on the standing authority of the service account, on behalf of a named nurse reviewer, or on behalf of another agent acting on behalf of a nurse. At the data boundary all three arrive as the same service account. The chain collapses at exactly the point where it starts to matter.
5. *The evidence relied upon.* The case state that justified the breadth — an open prior-authorisation request, a coverage criterion requiring cardiac history, a specific clinical question. That evidence lives in the case management system, on its own retention schedule, and the case closes and is archived without any pointer back to the read it justified.

Each of the five is individually recoverable for a while, and the windows do not coincide. A month later, four of the five are still obtainable with effort. A year later you have the commit history and possibly the role binding. Two years later, at the horizon this sector actually operates on, the intersection is empty. Notice that nothing in this story involves deletion, negligence, or a retention policy expiring. The information was never written down. There is no backup that contains it, and no forensic technique that recovers it, because recovery presupposes a record.

What breaks, provision by provision

The general argument becomes a healthcare argument at the point where you read the sector's own instruments closely enough to see which side of the effect/authority line each duty sits on. The pattern is consistent, and it is not an accident: rules written for systems operated by humans attach their mandatory duties to the record of effects, because when a human is the actor the authority is carried by the human.

The audit-control duty is scoped to activity, not to authorisation. 45 CFR 164.312(b) requires a covered entity to “Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.” Activity. What was done, by whom, when. The rule specifies no retention period for those records, and it says nothing whatever about recording the basis on which the activity was permitted. A team that implements 164.312(b) impeccably will produce precisely the log in the illustration — and will have discharged the duty.

The mandatory duty is to review the effects; the authority grant is only addressable. This asymmetry is visible in the rule's own status labels. Under the administrative safeguards, 164.308(a)(1)(ii)(D) — information system activity review, the regular review of records such as audit logs and access reports — is Required. The two specifications that come closest to materialising an authority decision, 164.308(a)(4)(ii)(B) access authorisation and 164.308(a)(4)(ii)(C) access establishment and modification, are both merely Addressable. Under the technical safeguards, unique user identification at 164.312(a)(2)(i) is Required, and it is a duty about tracking identity: “Assign a unique name and/or number for identifying and tracking user identity.” Who the principal is, not what the principal was permitted to do.

That is the shape of the omission from the security side. From the privacy side, the same rule set already contains the exact vocabulary an authority record would need, which is what makes the gap so odd once you notice it. 45 CFR 164.514(d)(2) operationalises minimum necessary as a determination made 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.

Principal class. Resource category. Conditions of access. That is a permission tuple, written into the regulation in 2000-era language for a world of workforce members and workstations. The rule already describes the object; what it does not require — because it had no reason to — is that the object be materialised at the moment it is applied. When the person or class is a service account executing a filter clause, the determination and its application come apart, and only the application leaves a trace.

The accounting of disclosures is a reconstruction duty with a six-year horizon. 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 is not universal — 164.528(a)(1) carves out disclosures for treatment, payment and health care operations, among others — but for the disclosures it does reach, 164.528(b)(2) requires each entry to carry the date, the recipient's name and address if known, 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 purpose element is the whole argument in one clause. It is not satisfiable from an effect log at any distance in time, because purpose is not a property of the read — it is a property of the decision to permit the read, and it was a parameter that nobody persisted.

The retention clock runs from the date a policy was last in effect, not from the date it was written. 45 CFR 164.316(b)(2)(i) requires an entity to “Retain the documentation required by paragraph (b)(1) of this section for 6 years from the date of its creation or the date when it last was in effect, whichever is later.” Read the second limb carefully, because it is the regulatory shape of the policy-churn problem: a policy version retired today can still be the version a reviewer must be shown six years from now. A team that treats its access policy as code, edits it in place eleven times, and keeps only the current state has not merely lost a debugging aid. It has lost the artefact whose retention the rule contemplates, and it has lost it in a way no backup restores, because the repository does hold the text — what it does not hold is which text was in effect when.

Some records carry a restriction that travels with the data itself. 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.” The restriction attaches to the data, not to the access path. An agent that legitimately retrieves a chart under one permission and then reuses Part 2 content in a downstream summary, an embedding index, a fine-tuning corpus or an analytics extract has crossed a line that no HIPAA-shaped access log is structured to record, because the log records that the chart was read, not what the content was subsequently permitted to be used for. Retrieval-augmented architectures make this considerably worse: the moment content is copied into a vector store, the read that put it there and the use that surfaces it are separated by an arbitrary amount of time and an arbitrary number of hops.

Entries in the medical record must be attributed to a responsible person. The CMS hospital condition of participation at 42 CFR 482.24(c)(1) requires all entries to be “legible, complete, dated, timed, and authenticated in written or electronic form by the person responsible for providing or evaluating the service provided,” and 482.24(b)(1) requires records to be retained “in their original or legally reproduced form for a period of at least 5 years.” Authentication is per entry and it names a responsible person. When an agent drafts and an unmodified draft is filed, the attribution question is not decorative — it is the question of which human's professional responsibility the entry rests on, and answering it requires knowing what the agent was authorised to do and on whose delegation, which is the record that does not exist.

The FDA's electronic-records rule already treats these as two separate controls. This is the strongest evidence that the distinction is not an invention of this essay. 21 CFR 11.10 enumerates the controls for closed systems as a list, and it lists them separately. 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 subject records. Paragraph (g), a distinct control, 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.” The rule has understood since 1997 that the record of what happened and the check on who was permitted to make it happen are different obligations. What it does not say — and this is the gap, not a criticism of the rule — is that the authority check must itself produce a record. In a world of human operators at validated workstations, it did not need to.

The reviewer may be opposing counsel, and that changes the standard

An evidence layer scoped against a regulator's examination cycle or an annual audit is built for a comparatively forgiving reviewer: the horizon is quarters, the standard is whether a control existed and was operating, and a well-constructed narrative supported by design documentation will often carry the day. Healthcare has that reviewer. It also has a second one, and the second one is why a layer designed for the first will not hold. I have no survey telling me how many estates are scoped only for the first reviewer — the point stands as a question to ask about your own, not as a claim about the population.

In litigation, the reconstruction is adversarial. Federal Rule of Civil Procedure 37(e), as amended in 2015, addresses electronically stored information “that should have been preserved in the anticipation or conduct of litigation” and “is lost because a party failed to take reasonable steps to preserve it, and it cannot be restored or replaced through additional discovery.” On a finding of prejudice a court may “order measures no greater than necessary to cure the prejudice,” and only on finding that a party acted with intent to deprive another of the information's use may it presume the lost information was unfavourable, instruct the jury that it may so presume, or dismiss the action or enter default judgment.

The 2015 amendment was, in the main, protective of producing parties: it raised the bar for the most severe sanctions to a finding of intent. But read what it presupposes. The framework is about information that was lost. Authority that was never materialised occupies a stranger position — it is not lost, it never existed, and the reason it never existed is a design choice made by the party that now cannot produce it. Whether a court treats that as a preservation failure or as an ordinary evidentiary gap is not something this essay can answer, and I have not retrieved a healthcare-specific opinion either way. What is available without any case law at all is the practical observation that the party unable to demonstrate the scope of an automated access is the party that will be asked to explain, at length, why its system was built that way.

The evidentiary system has, meanwhile, already made room for the kind of record that would answer. Federal Rule of Evidence 902(13), effective 1 December 2017, makes self-authenticating “A record generated by an electronic process or system that produces an accurate result, as shown by a certification of a qualified person” meeting the certification requirements of Rule 902(11) or (12); Rule 902(14) does the same for “Data copied from an electronic device, storage medium, or file, if authenticated by a process of digital identification,” again on certification. Cryptographic digital identification of a record is an established route to admissibility without live custodial testimony. The machinery for admitting a verifiable, content-addressed record of a decision exists. The record does not.

One further point about horizon, which is the quiet reason this sector is harder than the others. A payer's coverage dispute can surface years after the determination. The accounting of disclosures right reaches back six years. Documentation retention runs six years from the date a policy last was in effect. Hospital records are retained at least five years under the federal condition of participation, and longer under many state requirements and for minors. If your observability stack keeps ninety days of hot logs and a year of cold storage, it is not within an order of magnitude of the horizon on which the decisions it describes may be examined. Check the retention actually configured on the store that would have to answer, rather than the retention named in the policy that governs it.

/** A minimum-necessary filter as actually deployed: a clause in retrieval code.
 *  Eleven revisions exist in the repository. None carries an effective window,
 *  because an in-place edit to a query is not a policy artefact with a lifecycle. */
type FilterRevision = {
  readonly id: string;
  readonly permittedCategories: readonly string[];
  /** The condition the reviewer believed constrained the read. */
  readonly condition: string;
};

/** One row of the access log. This part of the estate is complete and intact. */
type AccessEvent = {
  readonly at: string;
  readonly actor: string;
  readonly recordCount: number;
  readonly categoriesTouched: readonly string[];
};

const REVISIONS: readonly FilterRevision[] = [
  {
    id: "r-04",
    permittedCategories: ["encounter", "medication", "problem"],
    condition: "an open prior-authorisation case exists for this member",
  },
  {
    id: "r-07",
    permittedCategories: ["encounter", "medication", "problem", "note"],
    condition: "an open case exists, OR the member is on the plan roster",
  },
  {
    id: "r-09",
    permittedCategories: ["encounter", "medication", "problem", "note", "imaging"],
    condition: "none — widened during a throughput incident, narrowed back later",
  },
  {
    id: "r-11",
    permittedCategories: ["encounter", "medication", "problem", "note", "imaging"],
    condition: "an open case exists AND the caller is the prior-auth workflow",
  },
];

const OBSERVED: AccessEvent = {
  at: "2024-06-11T09:41:07.412Z",
  actor: "svc-priorauth-agent",
  recordCount: 61,
  categoriesTouched: ["encounter", "medication", "problem"],
};

/** A revision is consistent with an access if it would have permitted every
 *  category the access touched. Note the direction: the log shows what was read,
 *  never what could have been read, so a narrow read is evidence for every
 *  revision at least that wide. */
function isConsistent(revision: FilterRevision, event: AccessEvent): boolean {
  return event.categoriesTouched.every((category) =>
    revision.permittedCategories.includes(category),
  );
}

type Reconstruction =
  | { readonly determinate: true; readonly revision: FilterRevision }
  | { readonly determinate: false; readonly candidates: readonly FilterRevision[] };

function reconstruct(
  event: AccessEvent,
  revisions: readonly FilterRevision[],
): Reconstruction {
  const candidates = revisions.filter((revision) => isConsistent(revision, event));
  return candidates.length === 1
    ? { determinate: true, revision: candidates[0] }
    : { determinate: false, candidates };
}

const result = reconstruct(OBSERVED, REVISIONS);

if (result.determinate) {
  console.log("Scope in force:", result.revision.id, "-", result.revision.condition);
} else {
  console.log("Indeterminate. Consistent revisions:", result.candidates.length);
  for (const candidate of result.candidates) {
    console.log("  " + candidate.id + ": " + candidate.condition);
  }
  console.log(
    "The log cannot separate a reviewed narrow grant from an incident-widened one.",
  );
}

What the field already knows, and where it stops

None of the components here is exotic, and it is worth being precise about how close the sector's own standards already come — both because it makes the omission legible and because it bounds what any proposal can claim to be novel.

Certified health IT already logs changes to the authority function. The ONC — now ASTP — certification 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 specified sections of ASTM E2147-18, along with 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. Read that list again. Changes to user privileges are logged — the mutation of the authority function is captured. The evaluation of that function at the moment of an access is not. The criterion knows that authority is a thing with a history, and records the history of the rule rather than the history of the rulings.

Decision-support certification already demands that a basis be inspectable — at model level. The criterion at 45 CFR 170.315(b)(11), decision support interventions, established by the HTI-1 final rule published on 9 January 2024 at 89 FR 1196, requires certified health IT to make available source attributes for predictive decision support interventions across categories including intended use and decision-making role, cautioned out-of-scope use, development details and input features, fairness process, external validation, quantitative performance measures, ongoing maintenance, and update and validation schedule. This is a genuine advance, and so far as I can establish it is the first US health IT certification requirement to demand source attributes specifically for predictive interventions — the 2015 Edition criterion it replaces, § 170.315(a)(9), already required source attributes for evidence-based clinical decision support, so the idea that the basis of an automated recommendation should be inspectable is older than the AI framing of it. It also operates one level up from the problem in this essay: it describes the intervention in general, not the individual instance. Knowing what a model was designed to do does not tell a reviewer what a particular agent was permitted to read on a particular Tuesday.

Clinical trials already expect workflow actions and user management to be evidenced. ICH E6(R3), adopted at Step 4 on 6 January 2025, is guideline text rather than a regulation, and it speaks in shoulds — but read what it expects. Section 4.2.2(a) says the responsible party's approach to metadata of higher criticality should entail evaluating the system to ensure that computerised systems “maintain logs of user account creation, changes to user roles and permissions and user access”; that systems be designed to permit data changes such that initial entry and any subsequent changes or deletions are documented, “including, where appropriate, the reason for the change”; and that systems “record and maintain workflow actions in addition to direct data entry/changes into the system.” Section 4.2.2(b) adds that audit trails should not be modified except in rare circumstances, and 4.2.2(c) that they be interpretable and able to support review. Section 4.3.8 states that access controls are integral “to limit system access to authorised users and to ensure attributability to an individual,” with permissions assigned based on duties, functions, blinding arrangements and organisation, and revoked when no longer needed. Section 4.2.7 says trial data and relevant metadata should be archived so they remain retrievable and readable and are protected from unauthorised access and alterations throughout the retention period.

That last cluster is the closest any instrument in this sector comes. It reaches the reason for a change, it reaches workflow actions and not merely data entry, and it binds the metadata for the full archival horizon. What it still does not require is that the authorisation decision itself be an emitted, retained, verifiable object — a record stating that at this instant, this principal, under this policy revision, for this declared purpose, was permitted this scope over this resource, and here is the evidence that determination relied on. Every ingredient of that sentence appears somewhere in the instruments quoted in this piece. The sentence itself is required by none of them.

A note on jurisdiction, since agents in this sector are increasingly built and operated across the US, India and the Gulf by the same engineering organisations. The instruments quoted here are American because those are the texts I retrieved and dated for this piece. The mechanism is not American: any regime that asks an operator to demonstrate, after the fact, that access to health data was limited to a defined purpose will run into the same physical fact, because the fact is about how permission systems execute rather than about which rulebook governs them. Read the argument, not the citation, and then check your own instrument's text yourself.

The limits of this argument

Several things could weaken or defeat what is argued above, and they should be stated by me rather than discovered by a reader.

• *None of the instruments read for this piece requires an authorisation receipt, and I am not claiming any standard does.* I have not surveyed every sector standard, and a reader who finds one that does has improved the argument rather than defeated it. Every instrument quoted here is being read for what it presupposes, not for what it mandates. An organisation can be fully compliant with all of them and still be unable to answer the question in the opening trace. That is the finding, and it is also the reason nobody should present this as a compliance gap in the narrow sense.
• *No measurement exists.* The number this argument would most like to have is the fraction of an agent's actions whose authorising decision can be correctly reconstructed from logs alone, as a function of elapsed time and policy churn. I could not find a primary published study measuring it, in healthcare or any other sector. I am not going to substitute a plausible-sounding figure for one, and any piece that quotes such a number without a primary source should be treated with suspicion.
• *The Security Rule specifies no audit-log retention period, and the common claim that it requires six years is a conflation.* 164.312(b) mandates the audit control and names no period. The six-year clock at 164.316(b)(2)(i) attaches to the documentation required by 164.316(b)(1) — the written policies, procedures, actions, activities and assessments — not to system audit logs as such. I verified both texts and found no primary basis for extending the clock to logs.
• *The CFR text here comes from the GPO's 2023 annual edition, which is a fixed snapshot.* The live eCFR blocks automated retrieval, so quotations were taken from the GPO's XML of the 2023 edition. Amendments made after that edition closed are not reflected. The Part 2 rule implementing the CARES Act was published in February 2024, after the snapshot: the general restriction quoted from 2.13(a) is long-standing and stable, but any Part 2 detail beyond it — consent mechanics, redisclosure notice, the list of disclosures — should be checked against current text before anyone relies on it operationally.
• *The rules of procedure and evidence were read from a faithful reproduction, not from the promulgating authority.* FRCP 37(e) and FRE 902(13)–(14) are promulgated by the Supreme Court under the Rules Enabling Act and published by the Administrative Office of the US Courts. The wording quoted here should be re-verified against that source before it is relied on in any adversarial setting.
• *No healthcare-specific court opinion supports the litigation framing.* The argument that the later reviewer may be opposing counsel rests here on the rules of general application only. Decisions compelling production of electronic health record audit trails are frequently cited in the health-information-management literature; I did not verify any against the court's own filed opinion, so none is cited.
• *The addressable/required line can move.* Nothing in this piece depends on the current status labels staying where they are. If specifications that are addressable today become required tomorrow, the argument is unaffected: making the documentation of a grant mandatory still does not materialise the evaluation of that grant at the instant of an access.
• *The strongest falsifier is a working counter-example.* If a production clinical agent stack can, today, take an arbitrary access from two years ago and return the policy revision, principal scope, declared purpose, delegation chain and relied-upon evidence for it — from records created at the time of the access and protected against subsequent edit — then the claim of structural discard is simply wrong for that stack, and I would want to read its design. A close second falsifier: a reviewer population that consistently accepts after-the-fact correlation of commits to deploys as sufficient. That would not make the reconstruction sound, but it would make the problem commercially inert, which is a different argument and one worth losing.
• *The opening trace is constructed.* It is not an incident, not client work, and not a report of anything that happened. It is a composite of primitives — an assistive summarisation agent, a filter clause carrying a regulatory determination, in-place edits, a two-year question — chosen because each is independently ordinary.

Where this goes next

The teardown ends here deliberately. What is worth stating at the end of it is the shape of the thing that would answer, without pretending that stating a shape is the same as building one.

The answer is not more logging. Effect logging in this sector is already good, and in the illustration it was excellent — the estate lost nothing it recorded. The answer is a second emission of a different kind: an artefact produced at the moment of the decision, by the component that made it, stating the tuple the regulation already names — persons or classes, categories of information, conditions of access — together with the policy revision evaluated, the purpose declared by the caller, the delegation chain that arrived, and a verifiable identification of the evidence relied on. Retained on the horizon the sector actually operates on, not the horizon the observability budget assumed. Verifiable in a form that does not depend on the good faith of the party producing it, which is the requirement that Federal Rule of Evidence 902(14) already anticipates and that nothing in the current stack supplies.

Every hard question about that artefact is a question this piece has not answered. What it costs on the hot path of a system that is already latency-sensitive. Whether the receipt is itself protected health information and what follows if it is. How to keep the volume from exceeding the data it describes. What happens at break-glass, where the whole point is that the normal determination is bypassed. How a receipt survives a vendor boundary when the agent calls a third-party service that will never adopt your format. Those are engineering questions with real answers and real trade-offs, and they are the subject of the companion piece, *Permission receipts for clinical and patient-data agents*, which is forthcoming.

The single thing worth carrying out of this one is smaller and can be checked this week without building anything. Take one agent in your estate that touches patient data. Pick an access from a quarter ago — not two years, a quarter. Then ask your team to produce, from records created at the time, the scope that access was made under and the determination that set it. If the answer involves anybody reasoning from commit history to deploy windows, you have found the gap, and you have found it while it is still cheap.