ADR-004: Legally-Scoped Data Tenancy

IRS Pub 1075 requires that FTI be:

A shared database or shared audit log containing FTI alongside non-FTI data is not prohibited per se, but it requires the entire shared system to be subject to Pub 1075 controls — including IRS audit authority over the entire system. By isolating FTI to canopy-tanf and canopy-medicaid, Canopy limits IRS audit scope to those two services. The SNAP service, the worker portal, and the applicant portal are outside Pub 1075 scope by design.

CMAs under the CMPPA require that matched data be used only for the authorized purpose stated in the agreement. SSA audits CMA compliance. If SNAP-authorized SSA data and TANF-authorized SSA data share a database, demonstrating compliance with both CMAs simultaneously becomes complex. Per-program isolation makes each CMA independently auditable.

7 USC §2025(e) prohibits use of IEVS data for purposes other than SNAP administration. If IEVS data resides in a shared database accessible to Medicaid or TANF program logic, even incidentally, this creates a compliance exposure. `canopy-snap’s isolated database ensures IEVS data is physically unavailable to non-SNAP services.

The canopy.events RabbitMQ exchange is subscribed to by canopy-security via wildcard. This means every event published to the exchange is captured for audit purposes. Program services must therefore ensure that events published to canopy.events contain no restricted data fields — only IDs, status codes, timestamps, and non-restricted metadata.

The determination object (per ADR-002) satisfies this requirement: it contains the outcome of restricted data processing, not the restricted data itself.

Alternative 1: Unified compliance database with column-level encryption All program data in one database; FTI columns encrypted with program-specific keys. Rejected because column-level encryption does not satisfy Pub 1075’s access logging requirement at the granularity IRS expects, and a DBA with key access defeats the isolation.

Alternative 2: Shared compliance database with separate FTI schema One PostgreSQL instance, FTI in a separate schema with separate roles. Rejected because a single PostgreSQL instance means a single superuser can access all schemas. IRS auditors are not satisfied by role-based controls at the schema level when the underlying server is shared.

Alternative 3: Hardware Security Module (HSM) for FTI encryption HSM-encrypted FTI in a shared database. Not rejected outright — this approach can satisfy Pub 1075 but at significant infrastructure cost and complexity. Per-service isolation achieves equivalent compliance posture with lower operational overhead. HSM integration may be revisited for canopy-tanf if required by a future Pub 1075 audit finding.

The isolation-map entry this amendment adds (a mirror of the §Decision table structure; that table itself is unchanged):

A1 — Isolation-map entry (the authorization). canopy-reporting is an authorized restricted-data consumer for the T-MSIS and CMS-416 federal extracts, per the mirror row above. This closes the ADR-001 A1 §B8 gap (a shipped person-level PHI table held by an unmapped service).

A2 — HIPAA PHI is an explicit restricted class. The person-level T-MSIS extract is HIPAA PHI (all Medicaid program data is HIPAA PHI, ADR-001 A1 §B8); this makes explicit what §Decision holds only implicitly via `canopy-medicaid’s "HIPAA-scoped clinical data". CMS-416 as held is de-identified aggregate (45 CFR 164.514), named for extract-scope completeness, not as a PHI holding. The §Context source table is not edited — HIPAA is a compliance framework, not a new data source.

A3 — Governing framework: Pub 1075 §4 (FTI-derived-or-PHI). Because Medicaid is a §6103(l)(12) FTI consumer and income_as_pct_fpl is MAGI-methodology-based and potentially FTI-derived (provenance pending #1257), reporting’s holdings are — fail-safe — governed under the Pub 1075 §4 control set (the superset of HIPAA’s minimum-necessary + audit obligations), authorizing reporting as a downstream holder of FTI-derived Medicaid data. #1257’s provenance determination MAY relax the classification to PHI-only; the mandated controls (A6–A8) do not change. (Resolved 2026-08-25: relaxed to PHI-only per Amendment 4, conditional on the IEVS estate staying IRS-free and on #785/#810 not writing FTI back into the persons fact corpus.)

A4 — Minimum-necessary scope. The authorization covers EXACTLY the fields the T-MSIS / CMS-416 federal layouts require — the enumerated medicaid_tmsis_eligibility_extracts columns (identifiers, eligibility/coverage status
dates, income_as_pct_fpl, the citizenship / disability / dual-eligible / managed-care / CHIP / restricted-benefit indicators). NO SSN and NO raw FTI are authorized or held. CMS-416 is authorized only as aggregate counts. Enforcement is projection (ADR-001 A1 §B4): unprojected restricted fields are never fetched, decrypted, or audited.

A5 — Sanctioned access path. canopy-reporting MUST acquire restricted data ONLY over internal HTTP (never cross-program DB — this half is the shipped reality) and MUST use the ADR-001 A1 §B7 async report_runs job model (itself not yet built), the §B1/§B2/§B3 keyset + total_in_scope completeness contract, and §B4 first-class projection (minimum-necessary). report_runs and its cursors live only in the reporting database (isolation preserved).

A6 — Independent Pub 1075 §4 / HIPAA access-audit log (MUST; not as-built). canopy-reporting MUST implement its own independent access-audit log satisfying IRS Pub 1075 §4, mirroring §Decision’s FTI-audit-logging requirements: every restricted-data persist (extract) AND every read/export is logged with user/service id, timestamp, purpose code, data elements accessed, and originating system; the log is stored in reporting’s own database, NOT the shared canopy-security audit log; and restricted fields are scrubbed from canopy.events payloads before publication. None of this exists today — this clause is normative.

A7 — Chain-v2 retention attachment (MUST; not as-built). Reporting’s restricted-holdings audit log is a NEW ADR-014 chain-v2 chain family (a new family under the C1 chain identity model), minted with a non-reusable chain_instance_id and attached via the #1246 substrate under the full C1–C8 apparatus. Retention is the per-jurisdiction ruleset value (ADR-014 A5 §C7), legal-hold aware, bounded below by the maximum of the applicable federal floors — the Pub 1075 §4 five-year floor (corrected to 7 years, Pub 1075 AU-11 — see the ADR-041-era retention amendment below; #1363) and the HIPAA 45 CFR 164.316(b)(2) six-year documentation-retention floor for the audit log.

A8 — Storage controls (MUST; not as-built). Reporting’s restricted holdings MUST be (a) encrypted at rest (an ADR-036 crypto-shred envelope or equivalent — not a reporting dependency today); (b) owned by a least-privilege restricted DB role, not the shared broad canopy role; and (c) exported only through an audited path (the current T-MSIS CSV export emits full person-level PHI rows unlogged; the QC / FNS-7176 export’s restricted classification is pending #1258 and is not authorized here — resolved 2026-08-25: non-restricted as held, Amendment 4).

A9 — Scope boundary. This amendment governs data tenancy only. The implementation (A6–A8 code + the chain-v2 family attachment) is a filed child, cross-linking the ADR-014 #1246 substrate. It does NOT re-classify the non-PHI extracts (FNS-388 / ACF-199 / FNS-7176-QC — ADR-001 A1 §B8) and does NOT touch bulk determinations (ADR-002 / #1237). Landing this amendment UNBLOCKS the T-MSIS + CMS-416 PHI-extract children (#1250).

The §Decision isolation mandates stand exactly as written: FTI audit logs live in a separate schema within the program-service DB (not the shared canopy-security log); every FTI access is logged with user/timestamp/purpose/elements/system; access is restricted to authorized personnel + IRS auditors; and the wildcard subscriber does NOT receive FTI — program services scrub FTI from event payloads before publishing (the scrub_fti_fields bus control + the publisher fail-closed guard remain distinct from the ADR-041 log-redaction facility and are unaffected).

Plaintext is permitted only for values the database engine itself must evaluate (filter / join / order / unique / group keys); every such column is enumerated with its justifying query. All other restricted-table content is sealed — an ADR-036 context-bound envelope (AAD = table tag + generation + row id, so a relocated ciphertext fails the tag), under a per-report-generation DEK.

Applied to the one restricted-as-held table, medicaid_tmsis_eligibility_extracts:

Threat model for the plaintext person/enrollment UUIDs: bare UUIDs are pseudonymous references — the linkage data (name/SSN/DOB) lives sealed in the other legally-scoped service databases. ADR-004 tenancy isolation is the linkage control; envelope encryption is the content control. The same pseudonymous UUIDs are therefore not sealed where they recur as engine keys — including in the shared report_run_universe / report_runs.progress run substrate.

Accepted residual — report_run_universe.aux. The scope of #1256 is the extract OUTPUT table only; the shared run substrate is left plaintext. Its per-row aux for the tmsis drain (TmsisDetAux) holds the covered person_id/household_id (pseudonymous keys), the assigned_coa
assigned_coa_track (identical to the coverage_group/chip_indicator this table already keeps plaintext as engine keys), AND the raw determination status (approved / filtered) — the one field of the same class as the sealed eligibility_status that is NOT sealed at rest. This is an accepted residual, not "no attribute content": the universe is transient, generation-scoped drain scratch (janitor-reaped with its generation), and sealing it would reintroduce per-kind branching across the SNAP/TANF/QC-shared substrate — the cost #1256 deliberately avoided. Tracked as follow-up #1459; a threat review decides whether the determination-status residual warrants sealing the aux or narrowing what the drain persists.

Reporting’s restricted rows are derived federal extracts. Person-level redaction happens at the source of record, after which the affected report regenerates — so the per-generation DEK is the correct granularity, not a compromise. When the generation janitor deletes a superseded generation’s ciphertext rows, its DEK becomes an orphaned live key; that lifecycle is owned by the general audit/retention work (#1303), not #1256.

Amendment 1 A2 states "CMS-416 as held is de-identified aggregate." That holds for the medicaid_cms416_reports OUTPUT table (age-band counts, no person id). It does not describe the shared report_run_universe working state, which durably holds person ids AND (for the tmsis drain) determination status + class-of-assistance in its aux (see the accepted-residual note above). Those stay plaintext in #1256 as janitor-bounded transient drain scratch, not a published holding; the determination-status residual is tracked as a follow-up.

Determination. No exported T-MSIS field is FTI-derived in the shipped codebase. A3’s governing framework relaxes from the Pub 1075 §4 fail-safe to HIPAA PHI (PHI-only). The provenance chain (all four hops verified 2026-08-25):

Effect. Reporting’s T-MSIS holdings are governed as HIPAA PHI. Audit-log labelling is PHI; the retention floor is unchanged in practice (A7 already takes the maximum of the applicable floors, and ADR-041 governs retention since Amendment 2). canopy-reporting remains ABSENT from class.fti in compliance/data-tenancy-authorisation.toml — correctly, as it holds no FTI.

The condition (tripwire — this relaxation is not unconditional). PHI-only holds only while BOTH stay true:

The isolation between IEVS values and non-SNAP uses rests on the ADR-027 human-transformation doctrine, not on data-flow segregation — Amendment 4 records that explicitly so a future source addition cannot assume a structural barrier that does not exist.

Determination. snap_qc_universe holds no IEVS-derived or otherwise restricted data. The ADR-001 A1 §B8 "non-restricted derived data" framing for the FNS-7176-QC extract is CONFIRMED, and A8(c)'s pending question resolves the same way: the QC export is non-restricted as held. Evidence (verified 2026-08-25):

The boundary (normative, so a future populater cannot drift). If the income/deduction stack is ever populated, its values MUST source from the canopy-persons fact corpus (attestation and ADR-027 worker-verified facts — the same non-restricted derivation the determination pipeline consumes). Values MUST NOT source from canopy-snap’s sealed IEVS stores (ievs_discrepancies, the sealed IevsReconstruction) — no code path exists today, and none may be added absent the Amendment-1-shaped authorization landing FIRST: an isolation-map row, a compliance/data-tenancy-authorisation.toml grant, and the sealing / least-privilege / audited-export controls the T-MSIS store carries. Absent that, canopy-reporting remains correctly absent from class.ievs.