# Evidence-Packet Compliance Crosswalk

**v0.4 — published to the Trust Center · August 13, 2026**

*v0.2: every HSCC cell verified against the primary guide PDF (healthsectorcouncil.org, April 2026, 109 pp.); two verdicts corrected on primary-source evidence. v0.3: fifth (stretch) column added for ONC/ASTP HTI-1 § 170.315(b)(11), verified from the official HealthIT.gov page — see Revision notes and the HTI-1 scope note.*

This document maps the Gatekeeper evidence packet — its **8 persisted record fields** and its **4 per-record control statuses** — against four external reference frames:

1. The contract asks in the HSCC **Third-Party AI Risk and Supply Chain Transparency Guide** (HSCC Cybersecurity Working Group, April 2026), specifically **Appendix E: Sample Commercial Contract Language** and **Appendix F: Sample BAA Contract Language** (titles as they appear in the guide). Every ask cited below was verified against the guide's own appendix text.
2. The five requirement areas of the Joint Commission's **Responsible Use of AI in Healthcare (RUAIH) program** (referred to here by its RUAIH acronym; the program's full official title is not reproduced in this document), wording verified from the official Joint Commission page on August 12, 2026.
3. The **HIPAA §164.312(b) / SOC 2 CC6.1 / CC6.3 / CC6.8** controls the deployed pipeline already stamps on every record.
4. As a stretch reference, the **ONC/ASTP HTI-1** criterion **§ 170.315(b)(11) — Decision support interventions**, verified from the official HealthIT.gov Test Method page. This comparison is a reference/benchmark only — see the HTI-1 scope note below the table; it is not a determination that Gatekeeper is subject to, or satisfies, the criterion.

**This crosswalk is a mapping document, not a formal compliance claim.** It documents where the evidence packet answers, partially answers, or doesn't address an external ask. Mapping is evidence, not proof of formal compliance status. Nothing here states or implies that Gatekeeper or any customer holds any formal compliance status or satisfies any regulation.

## What is being mapped (source of truth)

The evidence packet is generated by the deployed pipeline (shared generator: `src/lib/evidence-packet.ts`); every record is a real persisted audit row. Each record carries **8 fields**:

`timestamp` · `workflow_tag` · `actor_identity` · `model_provider` · `policy_version` · `decision` · redaction counts (`per_type_counts` / `redaction_count`) · `exceptions`

(Rendered surfaces split two compound fields for display — `model_provider` into Provider / Model, `policy_version` into Policy / Policy Version (Git SHA lineage) — but the persisted record has these 8.)

Each record also carries a `compliance_mapping` with four control statuses, read from the backend record, never hardcoded:

- `CC6.1` — Redaction proof
- `CC6.3` — Policy version lineage
- `CC6.8` — Jailbreak block
- `164.312(b)` — Audit trail

Each control status is `satisfied`, `not_applicable`, or `unavailable` (see *How to Read the Gatekeeper Evidence Packet*).

## Crosswalk

| Evidence packet field / control status | HSCC Appendix E/F asks | RUAIH's five areas | HIPAA §164.312(b) / SOC 2 controls | ONC/ASTP HTI-1 §170.315(b)(11) (applies to certified Health IT Modules / EHR technology, not to AI vendors — reference only) |
| --- | --- | --- | --- | --- |
| `workflow_tag` | Partially answers — Appendix E §12 (Audit Rights and Compliance Verification, audit upon "[30 days' notice]") and Appendix F's "AI Purpose Limitation" provision (PHI processed "only for the clinical, operational, or administrative purposes specified") presume per-call purpose attribution; this field documents which business workflow each AI call belongs to. The packet provides no notice or approval workflow. | Partially answers — *governance*: documents that each call is attributed to a governed workflow (or flagged when it is not). | Answers — component of the persisted audit row stamped `164.312(b)` "Audit trail". | Partially answers — one step removed: (b)(11)(vi)(C) requires each Predictive DSI to be subject to "policies and implemented controls for governance, including how data are acquired, managed, and used"; for AI calls routed through the gateway, workflow attribution documents one implemented use-control operating. Documents no (b)(11)(iv) source attribute. |
| `actor_identity` | Partially answers — Appendix F §4 (AI-Specific Safeguards) asks for "audit logging of all AI system access to and processing of PHI" and Appendix E §12 grants audit rights; this field documents who made each AI call. Not itself an audit right or notice, and only covers calls routed through the gateway. | Partially answers — *governance*: per-call actor attribution documents accountability for AI use. | Answers — component of the persisted audit row stamped `164.312(b)` "Audit trail". | Partially answers — one step removed: same (b)(11)(vi)(C) governance-controls hook; per-call actor attribution documents an implemented control on who uses AI. Documents no (b)(11)(iv) source attribute. |
| `model_provider` | Partially answers — Appendix F §6 (Subcontractor and Third-Party AI Service Flowdown) names upstream AI services explicitly ("AWS, Azure, Google Cloud AI services, OpenAI, Anthropic, etc.") and requires BAAs "before PHI is processed through such services"; Appendix E §11 gates changes to "third-party AI services processing PHI" behind contract amendment, updated privacy impact assessment, and governance approval. This field documents which upstream provider/model each call actually reached, or that it was blocked first. It does not establish that BAAs or amendments exist. | Partially answers — *monitoring, evaluating, and validating safety performance, effectiveness, and responsible use*: documents which pipeline stage / upstream model handled each call. | Answers — component of the persisted audit row stamped `164.312(b)` "Audit trail". | Partially answers — one step removed: the Predictive DSI source attributes ask for intervention-developer identification ("Name and contact information for the intervention developer"); per-call provider/model identification documents which upstream model actually served each call. It is not the plain-language source-attribute description the Health IT Module must make accessible. |
| `policy_version` (with policy git SHA) | Partially answers — Appendix E §3 (Updates, Patches, and Change Management) asks for "comprehensive release notes, change documentation, and validation evidence at least [30 days] prior to planned updates"; such change tracking needs lineage, and version + git-SHA documents exactly which policy version governed each call. The packet is not an advance notice. | Partially answers — *governance*: documents policy approval/version lineage per call; does not establish the organization-wide AI policy itself. | Answers — SOC 2 `CC6.3` "Policy version lineage" (policy/version lineage), carrying the policy version stamped with a policy Git-SHA lineage suffix. | Partially answers — the "Update and continued validation or fairness assessment schedule" attribute requires a "Description of process and frequency by which the intervention is updated"; version + git-SHA lineage documents that updates occurred and which version governed each call — supporting evidence for such a description, not the schedule, process, or correction-frequency description itself. |
| `decision` (`ALLOWED` / `REDACTED` / `BLOCKED`) | Partially answers — Appendix E §14 (Coordinated Incident Response and Recovery) asks for notification of "security incidents, AI model failures, performance anomalies" within "2 hours for Critical incidents, 24 hours for others"; incident documentation needs enforcement outcomes, and the decision plus block reason documents what was stopped and why. The packet does not send notifications. | Partially answers — *risk and bias reduction*: documents per-call risk enforcement (redact/block). Does not address bias. | Answers — drives SOC 2 `CC6.1` "Redaction proof" (REDACTED) and `CC6.8` "Jailbreak block" (BLOCKED) statuses; row persisted under `164.312(b)` "Audit trail". | Partially answers — one step removed: (b)(11)(vi)(B) requires Predictive DSIs to be "subject to practices to mitigate risks"; per-call redact/block decisions document mitigation practices operating. The packet contains no risk analysis of the (b)(11)(vi)(A) characteristics ("validity, reliability, robustness, fairness, intelligibility, safety, security, and privacy"). |
| redaction counts (`per_type_counts` / `redaction_count`) | Partially answers — Appendix F §4 (AI-Specific Safeguards) asks for "safeguards against unintended disclosure of PHI in AI-generated outputs" and Appendix F's baseline Minimum Necessary Standard provision requires processing "only the minimum necessary PHI"; per-entity redaction counts document PHI stripped before egress to upstream AI services. One safeguard among the several §4 asks for — not the full safeguard set (no encryption or access-control evidence in the packet). *(v0.2: upgraded from "Doesn't address" — see Revision notes.)* | Partially answers — *effective data management*: documents PHI detected and removed before egress, per entity type. | Answers — SOC 2 `CC6.1` "Redaction proof" detail, expressed as entity types and counts only — no PHI values. | Partially answers — one step removed: privacy is one of the (b)(11)(vi)(A) risk characteristics and (vi)(B) requires mitigation practices; per-entity redaction counts document a privacy-risk mitigation operating per call. No validity or fairness evidence. |
| `timestamp` | Partially answers — Appendix E's clocked asks (§3 "emergency security patches within 72 hours"; §16 drift notice within "[48 hours]"; §14 incident notice within 2 hours Critical / 24 hours others) are only verifiable against timestamped records; the UTC persistence timestamp documents when each event occurred. The packet does not compute or send notices. | Partially answers — *monitoring, evaluating, and validating safety performance, effectiveness, and responsible use*: timestamps make per-call monitoring evidence orderable and auditable. | Answers — component of the persisted audit row stamped `164.312(b)` "Audit trail". | Doesn't address — the ongoing-maintenance and update-schedule source attributes require descriptions of process and frequency; a call timestamp documents when a gateway event occurred, not any described update schedule, validation process, or fairness assessment. |
| `exceptions` (e.g. `UNGOVERNED_CALL`; block reason on blocked rows) | Partially answers — Appendix F §4 asks for "monitoring for anomalous AI behavior" and Appendix F §9 (Audit and Oversight of AI Data Flows) asks to verify "PHI is accessed and processed only as authorized"; the `UNGOVERNED_CALL` exception documents unattributed AI usage being loudly flagged rather than silently passed. Not a notification workflow. | Partially answers — *governance* and *monitoring, evaluating, and validating safety performance, effectiveness, and responsible use*: documents that untagged AI usage is flagged, never silently passed. | Answers — component of the persisted audit row stamped `164.312(b)` "Audit trail"; block reasons feed `CC6.8` "Jailbreak block". | Partially answers — one step removed: (b)(11)(vi)(C) governance controls; the `UNGOVERNED_CALL` exception documents enforcement of use-governance (untagged AI usage flagged, never silently passed). Documents no (b)(11)(iv) source attribute. |
| `CC6.1` — Redaction proof (`satisfied` / `not_applicable` / `unavailable`) | Partially answers — Appendix F §4 (AI-Specific Safeguards) asks for technical safeguards against PHI exposure, including "safeguards against unintended disclosure of PHI in AI-generated outputs"; the per-record Redaction proof status documents one such safeguard operating per call. It does not document the rest of §4's safeguard set. *(v0.2: upgraded from "Doesn't address" — see Revision notes.)* | Partially answers — *effective data management*: per-record proof that sensitive entities were replaced before anything left the boundary. | Answers — SOC 2 `CC6.1` (logical access / redaction), status stamped per record by the pipeline. | Partially answers — one step removed: same basis as redaction counts — a privacy-risk mitigation practice recorded per call ((b)(11)(vi)(A)/(B)). No validity or fairness evidence. |
| `CC6.3` — Policy version lineage (`satisfied` / `not_applicable` / `unavailable`) | Partially answers — evidence base for Appendix E §3's planned-update ask ("release notes, change documentation, and validation evidence at least [30 days] prior"): the lineage shows which policy version was in force for every call. | Partially answers — *governance*: documents policy version control in operation. | Answers — SOC 2 `CC6.3` (policy/version lineage), status stamped per record by the pipeline. | Partially answers — same basis as `policy_version`: lineage evidence that could support — but does not constitute — the required "Update and continued validation or fairness assessment schedule" description. |
| `CC6.8` — Jailbreak block (`satisfied` / `not_applicable` / `unavailable`) | Partially answers — Appendix F §4 asks for "protection against adversarial attacks, model inversion, or membership inference that could expose PHI", and Appendix E §14 covers security-incident notification (2 hours Critical / 24 hours): a detected jailbreak is blocked before the upstream model is called and recorded as satisfied, not merely logged. | Partially answers — *risk and bias reduction*: documents prompt-injection risk enforcement. Does not address bias. | Answers — SOC 2 `CC6.8` (unauthorized/malicious activity), status stamped per record by the pipeline. | Partially answers — one step removed: the (b)(11)(vi)(A) risk characteristics include "robustness", "safety", and "security"; a recorded jailbreak block documents a mitigation practice against adversarial input ((vi)(B)). No validity or fairness evidence. |
| `164.312(b)` — Audit trail (`satisfied` / `not_applicable` / `unavailable`) | Partially answers — Appendix F §4 asks for "audit logging of all AI system access to and processing of PHI", Appendix F §9 asks for "documentation, system logs, audit trails" to support audits, and Appendix E §12 grants audit upon "[30 days' notice]": per-call audit rows are persisted and exportable (`POST /api/v1/evidence/export`). Covers only calls routed through the gateway; the contractual audit right itself is outside packet scope. | Partially answers — *monitoring, evaluating, and validating safety performance, effectiveness, and responsible use*: the persisted trail is what monitoring and evaluation read. | Answers — HIPAA `§164.312(b)` "Audit trail", status stamped per record by the pipeline. | Partially answers — one step removed: a persisted, exportable audit trail documents "implemented controls" over how data are used ((b)(11)(vi)(C)) for gateway-routed calls; it is not the Health IT Module's source-attribute disclosure, and covers only calls routed through the gateway. |

### HTI-1 scope note (read before using the fifth column)

**§ 170.315(b)(11) — Decision support interventions** is a criterion of the **federal ONC program under which Health IT Modules are tested and certified** (the program's official title is not reproduced in this document). Its duties fall on the **Health IT Module**, not on an AI vendor: per the regulation text on the official page, "the Health IT Module must enable a limited set of identified users to access complete and up-to-date plain language descriptions of source attribute information" ((b)(11)(v)), and intervention risk management applies to each Predictive DSI "supplied by the health IT developer as part of its Health IT Module" ((b)(11)(vi)). Gatekeeper is not a Health IT Module, and the evidence packet is not a source-attribute disclosure.

The fifth column is a **reference/benchmark comparison only** — it documents where packet evidence relates to HTI-1 concepts (mostly one step removed, via the (b)(11)(vi) risk-management, mitigation, and governance practices) and where it does not. Scope limitation, stated plainly: the packet contains **no update schedule, no continued-validation process, no fairness assessment, and no correction-frequency description** — the substance of the "Update and continued validation or fairness assessment schedule" source attribute. The page's companion guide for the criterion also notes — paraphrased here rather than quoted, because the original sentence contains the federal program's official title — that the program has not established requirements for specific measures of validity or fairness. Nothing in this column is a determination that Gatekeeper, the evidence packet, or any customer is subject to or satisfies § 170.315(b)(11). No effective or deadline dates are cited: date material on the official page was not verified as applicable to this specific requirement and scope, and is deliberately omitted.

## RUAIH five-area coverage summary

The Joint Commission's Responsible Use of AI in Healthcare (RUAIH) program — launched June 1, 2026 — organizes its standards around five areas. Wording below is verbatim from the official Joint Commission page (verified August 12, 2026 — the page renders the areas lowercase, inline):

| # | RUAIH area (official wording) | Packet coverage |
| --- | --- | --- |
| 1 | governance | Partially answers — via `workflow_tag`, `actor_identity`, `policy_version`, `exceptions`, and `CC6.3` "Policy version lineage". The packet documents governed-vs-ungoverned attribution and policy lineage per call; it does not establish an organizational governance structure. |
| 2 | effective data management | Partially answers — via redaction counts and `CC6.1` "Redaction proof". The packet documents per-call PHI redaction before egress; it does not document an organization-wide data-management program. |
| 3 | risk and bias reduction | Partially answers — via `decision` and `CC6.8` "Jailbreak block". The packet documents risk enforcement (redact/block); it contains no bias-reduction evidence. |
| 4 | monitoring, evaluating, and validating safety performance, effectiveness, and responsible use | Partially answers — via `timestamp`, `model_provider`, `exceptions`, and the `164.312(b)` "Audit trail" control. The packet is the per-call monitoring record; it does not itself evaluate or validate performance. |
| 5 | transparency, education, and training | Doesn't address — no packet field documents staff education/training or patient transparency and consent. |

## Sources

- **Evidence packet (left column):** shared generator `src/lib/evidence-packet.ts`; committed artifacts `evidence/governed_packet.json`, `evidence/ungoverned_packet.json`; reviewer guide *How to Read the Gatekeeper Evidence Packet* (`/trust/how-to-read-the-evidence-packet.md`); `docs/SAMPLE_EVIDENCE_PACKET.md`. Field names, control names, and statuses are reused verbatim; no fields were added or renamed.
- **HSCC column:** *Third-Party AI Risk and Supply Chain Transparency Guide*, HSCC Cybersecurity Working Group, April 2026 (cover title: *Health Industry Cybersecurity Third-Party AI Risk and Supply Chain Transparency Guide*; 109 pp., healthsectorcouncil.org) — **Appendix E: Sample Commercial Contract Language** (17 numbered clauses, pp. 65–70) and **Appendix F: Sample BAA Contract Language** (baseline provisions + 9 numbered provisions, pp. 71–73). Every cell's ask was verified against this primary appendix text on August 12, 2026; quoted phrases are verbatim from the guide, and square brackets reproduce the guide's own fill-in bracketing. The in-repo research report *The State of AI Change Obligations in Healthcare* (`/research/state-of-ai-change-obligations-aug-2026.md`, §2) remains a secondary summary.
- **RUAIH column:** Joint Commission, *Responsible Use of AI in Healthcare (RUAIH)* — official page (jointcommission.org, in the section for the Responsible Use of AI in Healthcare program; the program's full official title is not reproduced in this document), five-area wording read from the page on August 12, 2026; five-area wording re-verified August 13, 2026. Launch date: the program was launched June 1, 2026, per the official Joint Commission announcement of that date (this is a launch date only, not an effective or compliance date).
- **HIPAA / SOC 2 column:** the four controls stamped by the deployed pipeline on every record (`CC6.1`, `CC6.3`, `CC6.8`, `164.312(b)`), with the control descriptions used in the published security questionnaire (`/trust/questionnaire.md`). The backend stamps exactly these four controls per record.
- **HTI-1 column:** ONC/ASTP, § 170.315(b)(11) *Decision support interventions* — official Test Method page and its companion guide (the guide's official title is not reproduced in this document), `https://www.healthit.gov/test-method/decision-support-interventions/`, regulation paragraphs (b)(11)(iv)–(vi) as presented there, read August 12, 2026. Quoted phrases — including "Update and continued validation or fairness assessment schedule" and its two sub-elements ("Description of process and frequency by which the intervention is updated" and "Description of frequency by which the intervention's performance is corrected when risks related to validity and fairness are identified") — are verbatim from that page. No deadline or effective dates from the page are cited (not verified as applicable to this requirement and scope).

## Revision notes (v0.2)

Primary-source verification against the HSCC guide PDF confirmed every previously cited ask (E §3 update/release-notes/validation windows, E §12 audit notice, E §14 incident clocks, E §16 drift notice, E §11 third-party-AI consent gate, F §6 upstream naming — the "AWS, Azure, Google Cloud AI services, OpenAI, Anthropic, etc." quote is verbatim). Three corrections resulted:

1. **Appendix title punctuation** — the guide titles its appendices with a colon (*Appendix E: Sample Commercial Contract Language*, *Appendix F: Sample BAA Contract Language*); earlier drafts used an em dash.
2. **Redaction counts × HSCC: "Doesn't address" → "Partially answers".** The v0.1 verdict relied on the research report's summary, which covers only change-notice obligations. The primary text contains Appendix F §4 (AI-Specific Safeguards) — "safeguards against unintended disclosure of PHI in AI-generated outputs" — and the baseline Minimum Necessary Standard provision, which per-entity redaction counts partially document.
3. **CC6.1 Redaction proof × HSCC: "Doesn't address" → "Partially answers".** Same basis: Appendix F §4 is a genuine safeguard ask the v0.1 summary source did not include. The verdict remains partial — the packet documents redaction only, not §4's full safeguard set (encryption, access controls, anomaly monitoring).

## Revision notes (v0.3)

The previously deferred ONC/ASTP HTI-1 stretch column was added after verifying § 170.315(b)(11) directly on the official HealthIT.gov Test Method page (regulation paragraphs (b)(11)(iv) source attributes, (v) access and modification, (vi) intervention risk management). The existing four columns were not modified. Column outcome, applied strictly: **0 Answers**, 11 Partially answers (each carrying an explicit one-step-removed or evidence-vs-description caveat), 1 Doesn't address (`timestamp`). The packet never contains the plain-language source-attribute descriptions the criterion requires of a Health IT Module, so no cell claims a full answer; see the HTI-1 scope note.

## Revision notes (v0.4)

Publication pass, August 13, 2026. RUAIH five-area wording re-verified directly on the official Joint Commission page (all five areas, including area 4, match verbatim — no wording changed); the June 1, 2026 launch date was added, identified strictly as a launch date. The HTI-1 column header now states the criterion's regulated scope explicitly (certified Health IT Modules / EHR technology, not AI vendors); no other HTI-1 content changed, and the column continues to cite no effective, deadline, or compliance dates. The two v0.2 verdict upgrades were re-audited against a record generated by the deployed pipeline on August 13, 2026 (live `per_type_counts`, `redaction_count`, and a `satisfied` CC6.1 "Redaction proof" status with per-entity detail): both remain **Partially answers** — the packet documents the redaction safeguard operating, but not the rest of Appendix F §4's safeguard set, so no cell was upgraded to Answers. This document is linked from the Trust Center's Reviewer documentation section.