A modern AI system is a large neural network. Unlike ordinary software, it is not written as explicit rules a person can inspect; it is trained, and its behavior emerges from billions of numerical parameters adjusted during that training. Those who build and run these systems can see what a model outputs but cannot, in general, explain why it produced one output rather than another.

This is not a fringe claim; it is acknowledged by the frontier developers themselves. Anthropic describes its own models as a black box: something goes in and a response comes out, and it is not clear why the model gave that particular response instead of another. The research effort to change this, mechanistic interpretability, is real, but does not yet let anyone reconstruct why a model reached a particular decision by examining the model itself.

The decision cannot be recovered from the model. It can only be recovered from a record of what went into it.

It is tempting to think this is solved by having the model explain itself. It is not. Peer-reviewed research has established that a language model's stated reasoning is frequently unfaithful: the explanation it writes does not reflect the factor that actually drove its answer. Turpin et al. (2023) showed that a model can be influenced by something — the order of options, a bias in the prompt — and then produce a fluent, plausible rationale that never mentions that influence. The rationale is written to look reasonable, not to report the true cause.

For coverage the consequence is direct: a denial can cite the correct clinical criteria and read as sound while the real driver, a cost signal or a utilization target, goes unstated. The record therefore cannot rest on the model's explanation. It must preserve the inputs and conditions that allow the decision to be checked independently.

An AI decision is a function not only of the clinical facts but of the exact conditions under which it was produced: what the model was told and how it was worded, which model and version answered, the sampling settings, the tools it could call, the documents and policy in its context, and any memory it retrieved. Changing a single one of these — a word of framing, a figure in the context, an item of retrieved memory — can flip a decision that should not have changed. A decision can only be shown to have been made properly if all of these conditions were recorded.

An affected member, a reviewer, or a regulator can only contest a decision they can see into, and adding an AI system does not suspend that right. Litigation over automated post-acute coverage tools has turned on precisely this failure: denials that patients could neither understand nor contest because the basis was never disclosed or reconstructable, with a federal court observing that affected patients had no way to challenge the process that produced them.

A conformant provenance record is what makes a coverage decision challengeable.

A determination is made against a set of documents, and that set changes over time. Records are faxed in late. Notes are amended, addended, or signed after the fact — all of which are lawful and routine. Without a sealed record of the set, there is no way to distinguish a document the reviewer saw from one that arrived afterward.

For every decision in scope, the record MUST contain a manifest of the evidence, with one entry per document:

• A stable identifier for the document, and its source.
• A digest of its exact content at the time of the decision.
• The time it was received.
• Whether it was presented to the model.
• Whether it was presented to the human reviewer, where one was involved.

The manifest MUST itself be digested, and that digest MUST be committed to the ledger with the determination. The two presentation flags are not bookkeeping. A document that was on file but never sent to the model, and a document nobody ever had, are different failures with different remedies, and no other part of the record distinguishes them.

The record MUST contain everything the system was given, as it was given:

• The request: the service, item, or drug sought, with units and duration; the member; and the date and time of the decision.
• The exact prompt and instructions, as worded, including all system-level instructions.
• The full text of the coverage rule or policy applied, pinned by hash to the exact version in force. A version identifier alone is insufficient: policies are revised, and an appeal turns on what the criterion said that day.
• The tools or retrieval available, and the results actually returned by any that were used, captured as retrieved rather than merely noted.
• Any memory or additional context present in the system's window at decision time.

Where a deployment uses no memory or outside context, the record MUST state that the decision was made on the request alone; that attestation satisfies this part. Anything able to influence a decision that is not captured is a conformance gap. This is the central obligation of the Profile.

The settings that govern how the system produced its output MUST be recorded and bound to the decision:

• Model identity and version, including any provider-side version or system fingerprint returned with the response.
• Temperature, top-p, and any other sampling parameters.
• The sampling seed, where the provider accepts one.
• Token limits and stop conditions in force.
• Any confidence or routing threshold applied to this decision.

These MAY be held as a single versioned configuration referenced by each decision rather than copied into each record, provided that every change is written as a new dated entry in the tamper-evident ledger, and that each decision unambiguously references the version in force when it was made. This is how a change to a routing threshold — the lever that decides how many cases a human sees — is caught: not by logging the number on every decision, but by making every change to it a permanent, timestamped, attributable event.

The record MUST contain:

• The decision itself, and whether it was favorable or adverse.
• What was requested versus what was decided, wherever they differ.
• The stated basis, with principal reasons for any adverse outcome.
• Any reasoning the system generated, in full and untruncated. Where a system can emit reasoning it SHOULD; a token limit MUST NOT cut it off; where it emits none, the record notes that.
• The decider: whether the determination was issued by a model or by deterministic code, and where it was code, the identity and version hash of that code.

The decider is recorded because it is the first question a regulator asks and because the two cases are provable to different degrees, as Section 10 sets out.

Where a second model or a distinct scoring step generates a confidence, risk, or priority score, whether used to rank, prioritize, or decide which cases reach a human, the record MUST additionally capture the score and its scale (for example, 6 of 6, or 95 of 100); the model and version that produced it; and what the score was used for. A bare number without its scale and source is non-conformant.

This Profile does not enumerate stages, because doing so would encode one vendor's architecture and fail on the next. It treats every point at which an AI system transformed the material as a stage with an input and an output, and requires three properties that hold regardless of what the stages are, how many there are, or what they are called:

• Continuity. Each stage MUST record a digest of its input and a digest of its output. Each stage's input digest MUST equal the preceding stage's output digest.
• Closure. The first stage's input digest MUST equal the digest of the evidence manifest, and the determination's input MUST be the final stage's output. Every byte the determination rests on must trace back to the sealed set.
• Attribution. Each stage MUST record the model identity and version, or the code version, that performed it.

A break in the chain means material entered or left the pipeline unrecorded. This is detectable without knowing anything about what any stage does, which is precisely what makes the requirement architecture-independent. A deployment declaring that no AI system touched the material before the determination MUST record that declaration. It is a testable claim, not an exemption.

Where a stage's output is relied on downstream, the output itself MUST be retained, not only its digest:

• Extraction output. The decision-relevant facts extracted, each carrying a pointer to its location in the source packet. A fact used in a determination but not traceable to the packet MUST be marked ungrounded.
• Summarization output. Any condensed representation actually presented to a human reviewer or consumed by a downstream component, retained in full alongside the extraction output it was derived from, so the two can be compared.
• Codification artifacts. Where a coverage policy was converted into a machine-executable rule: the source policy text hash-pinned to its version, the generated rule, and an element-level comparison showing every required criterion, exception, and branch as present or absent.
• Packet composition. The documents assembled into the decision packet, in order, with total size, and whether any content was truncated or dropped before the model saw it.

A digest alone is sufficient to prove a stage's output was not altered. It is not sufficient to detect that the output was wrong — that a disqualifying fact was dropped in summarization, or that a codified rule omitted an exception. Detecting those requires comparing the stage's output against its input, which requires the content.

For each extracted fact that would independently defeat the request, the record MUST state whether it appears in the summary or representation passed downstream. Where it does not, that omission MUST be recorded as an explicit event rather than left implicit in the absence.

Where the record contained conflicting values for the same decision-relevant fact, the record MUST state which source was treated as authoritative and which value was used. Where no conflicts were found, an explicit empty finding is the conformant way to say so.

This Profile rests on digests, and a digest is only meaningful if two conformant implementations compute the same one for the same content. The following are therefore normative.

• Algorithm. A digest MUST be computed with SHA-256 or a stronger function from the SHA-2 or SHA-3 family. The algorithm and its identifier MUST be recorded alongside each digest, so that the function in force is explicit and can be migrated without invalidating prior records. A record MUST NOT use a function with a known practical collision (MD5 and SHA-1 are non-conformant).
• What is hashed. For a document or attachment, the digest is computed over the exact retrieved bytes of its content, not over a reference, a URL, or a metadata wrapper. For a structured FHIR resource, the bytes hashed MUST be a canonical serialization (below), not the resource as incidentally transmitted, because two byte-different serializations of the same resource would otherwise produce two different digests and defeat comparison.
• Canonicalization. Where the hashed object is a FHIR resource, the deployment MUST apply a documented, deterministic canonicalization before hashing (for example, canonical JSON with sorted keys and normalized whitespace, or an equivalent published scheme) and MUST record which canonicalization was used. Two conformant deployments recording the same resource MUST arrive at the same digest. Where the hashed object is an opaque document (a PDF, a scan, a fax image), the raw bytes are the canonical form and no transformation is applied.
• Chain construction. The ledger is append-only: each committed entry MUST include the digest of the immediately preceding entry, so that the entries form a hash chain in which altering any earlier entry breaks every later link. Each entry MUST carry its commitment time and a signature over its content and the prior-entry link. Verifying the chain (Section 11.2) means recomputing these links end to end.
• What the digest proves, and does not. A committed digest proves that the content existed at commitment time and has not changed since, provided the content remains retrievable and is re-hashed under the same algorithm and canonicalization. It does not prove the content is correct, complete, or true. Completeness against a prior stage is established by comparison (Section 4), not by the digest alone.

Every record MUST be committed to a signed, append-only, hash-chained ledger, so that any entry can be shown to have been created when claimed and not altered since. Corrections are made by appending a new, linked record, never by overwriting a committed one. The logic governing each decision's routing and disposition is held tamper-evident on the same basis. Any implementation providing append-only, cryptographically verifiable integrity of the kind used in recognized secure-logging and audit-trail practice satisfies this requirement; no specific vendor is mandated.

Integrity derives from when the commitment was made, not from how much was stored. A digest written into the chain at decision time makes any later alteration detectable regardless of how much content the deployment retains.

An unbroken chain proves that the entries were not altered. It does not, by itself, prove that retained content still matches the digest recorded for it. Where a deployment retains content, verification MUST recompute the digest of the retained content and compare it against the digest committed at decision time. A record whose content no longer matches its committed digest MUST be reported as altered, not as verified.

Every artifact required by this Profile MUST be digested into the ledger, and MUST remain retrievable. Where it is retrieved from is a property of the deployment, not of conformance. A deployment MUST record, for each decision, where the readable content is retained. Two custody arrangements conform:

• Retained by the recording system. The content is held alongside the proof. The system is a PHI system and is governed accordingly.
• Retained by the plan, referenced by the record. The content remains in the plan's systems and the record carries a resolvable reference to it. The recording system holds proof without holding the content.

A record that carries a digest for content that no party retains is non-conformant. A digest of something nobody kept proves nothing, and a conformance claim that rests on it is a claim that cannot be tested.

Records MUST be retained, and remain verifiable, for at least the period required by applicable coverage and appeals law. Deployments SHOULD NOT retain readable clinical content beyond that period; the integrity record may be retained longer, because it contains no clinical content.

A provenance record is evidence, and evidence has its own chain of custody. Where a record is disclosed — to an appeals reviewer, a regulator, counsel, or the member — the deployment MUST record as a ledger event: what was disclosed, to whom, when, and under what authority.

Disclosure access SHOULD be scoped to the determinations at issue and SHOULD expire. A standing export of the whole population is not a disclosure; it is a copy, and it defeats the custody record this section establishes.

Verifying a record's integrity, and auditing AI involvement and human accountability, MUST NOT require exposing protected health information. Integrity verification operates on digests, and digests contain no clinical content. Deletion obligations are satisfied by removing the readable content while retaining the committed digest: the chain is never rewritten, and the record remains verifiable against whatever copy is later produced.

Bit-exact re-execution of a large language model is not achievable in production, and this Profile does not require or imply it. Providers update models behind stable identifiers; numerical non-determinism means identical inputs can yield different outputs on identical settings; and where a sampling seed is offered at all, it is typically documented as best-effort rather than guaranteed. A conformance claim MUST NOT be represented as a guarantee that the determination can be reproduced.

• Exhaustiveness of influence. Everything that could have influenced the determination is in the record. There was no undisclosed instruction, no unrecorded retrieved content, no hidden context. This is what makes prompt manipulation, context injection, and undisclosed steering detectable rather than deniable.
• Integrity over time. Every recorded artifact is byte-identical to what existed at the moment of the determination, or the discrepancy is detected and reported.
• Accountability. Who decided, on what basis, under what configuration, reviewed by whom, and where the case went next.

Where the determination was issued by deterministic code rather than a model, the decision step is reproducible: the recorded rule version can be re-executed against the recorded extracted representation and the outcome compared to the one issued. For such deployments a conformant record supports a stronger claim, that the determination followed correctly from its inputs, and a conformance report SHOULD state which claim applies. This is a property of the architecture, not a difference in the requirements.

For each reporting period, a deployment MUST measure and report:

• The number of in-scope determinations the deployment issued.
• The number of those that produced a conformant record.
• The resulting coverage rate.
• Every shortfall attributed to the specific requirement that failed, so that a coverage rate below 100% names its cause rather than reporting a bare number.

A record committed once and never checked again establishes nothing about the present. A deployment MUST:

• Verify the integrity of the hash chain on a defined cycle, and at least daily.
• Re-verify retained content against its committed digests on a defined cycle, and at least quarterly across the full retained population.
• Record each verification run, its scope, and its result as an event in the ledger. A verification a deployment cannot prove it performed is not a control.
• Report any lapse in either cycle. Where verification has lapsed, the affected period MUST be reported as unverified rather than as conformant.

A deployment MAY publish an attestation of its conformance. Where it does, the attestation MUST contain all of the following, and MUST NOT state more than has been measured:

• The Profile and version claimed, and the reporting period covered.
• The coverage rate for that period, and the scope of decision types included.
• Chain verification status, with the time of the most recent successful verification.
• Certification status per capability line, including any line lapsed or suspended.
• The custody arrangement in force.
• An as-of date. An attestation without one is non-conformant, and an attestation whose most recent verification falls outside its own stated cycle MUST be presented as stale.

A published attestation MUST be independently verifiable: a third party MUST be able to confirm the integrity claims against the ledger without being granted access to clinical content. It MUST NOT contain protected health information, per-determination data, or outcome statistics such as approval or denial rates. It attests to the provenance posture of a deployment, not to the merits of its determinations.