ADR-051: Person Full-SSN Custody and the Federal-Export PII Path

persons.ssn is a FieldScheme::BlindIndex registry field (crates/craig-cases-fields/src/persons.rs): CGEF ciphertext at rest, with a deterministic ssn_full_hmac sibling under its own HKDF domain (field_domain = "ssn_full", v1) — domain-separated from the last-four’s "ssn" domain so the two columns can never be correlated. Full SSNs never rest outside cases' encrypted columns: not in reporting’s DB, not in the object store, not in logs, not on the event bus.

ssn is excluded from the persons search descriptors: full-SSN equality search would hand realm-flat caseworkers a confirmation oracle. The HMAC
partial index exist for write-time duplicate detection and #162’s future SDX/BENDEX matching only.

The API accepts ssn on person create/update (digits with space/dash separators; canonicalized service-side; SSA range-validated — area not 000/666/9xx, group not 00, serial not 0000 → 400 INVALID_SSN). No read surface serializes ssn or ssn_full_hmac (#[serde(skip_serializing)] on the store model — person reads return the model directly).

Setting ssn derives and overwrites ssn_last_four + ssn_hmac in the same statement — one source of truth. Direct last-four entry while a full SSN is on file (or both fields in one request) → 400 SSN_LAST_FOUR_MANAGED; the on-file check runs inside the update’s FOR UPDATE locking transaction.

Entry is web-only: the person-edit page carries a masked input. The CLI deliberately has NO full-SSN argument — command-line values persist in shell history and process listings.

Verification state is person-level (ssn_verified + at/by/method; DB CHECKs make partial state unrepresentable, including ssn_verified ⇒ ssn IS NOT NULL). The lifecycle is value-bound:

Authorization: Action::Approve on ResourceType::Person, PLUS an in-handler pure-service denial (claims.acting_worker().is_service() → 403): machine identities never attest — the person rulesets grant service principals allow-all, and the literal is_service() check would wrongly 403 craig-web’s BFF (service token + lifted actor). Per-jurisdiction consequence, pinned by L3 tests: the person ResourceRef carries no supervisor linkage, so under the Texas ruleset i_supervises can never match — TX attestation is admin/regional only; GA admits admin+supervisor via existing allow-all rows (no ruleset change; added rows would be dead rules).

DELETE /v1/cases/persons/{id}/ssn (reason required; Action::Approve + an in-handler admin gate — a ruleset-routed check alone cannot be admin-only since GA supervisor rows are allow-all; pure-service denied) clears all four SSN columns — ssn, ssn_full_hmac, ssn_last_four, ssn_hmac — plus verification state. The derived last-four is wrong-person PII residue and MUST go with the SSN; a still-valid standalone last-four is re-entered through the normal path afterward (permitted once no full SSN is on file). This is the wrong-person / merge / data-subject-correction remedy; ssn is deliberately non-clearable via ordinary update.

The revoke/clear reason reaches the durable audit trail via the case.person_ssn_admin_action event (→ audit_log through the # subscriber) — deliberately NOT via tracing: free-form correction text can carry PII, and service logs are neither access-controlled nor durable. It is the one person-event payload carrying worker-authored text; the UI labels the field "audited" so authors know where it goes.

POST /v1/cases/persons/federal-export (service-only: require_service_caller() + the craig-reporting allowlist) returns demographics + ssn_last_four + ssn_present/ssn_verified + ssn_digest (for the blocked gateway-199 transmit re-affirmation — consumers cannot compute it), and the decrypted full ssn ONLY when the caller sets include_full_ssn = true AND the row is ssn_verified. Unverified SSNs never leave cases through this purpose. Responses carry Cache-Control: no-store; ids are capped at 5,000 per call (400 BATCH_TOO_LARGE; consumers chunk).

Every call stages case.person_pii_exported on the transactional outbox — the repo’s first read-access audit event — carrying the requestor service, the person-id list (UUIDs are not PII; an incident must be able to answer "whose SSNs left"), the include_full_ssn flag, and a purpose string. It reaches audit_log via craig-security’s # subscriber.

Anticipated exception: #162’s SOLQ verification will need UNVERIFIED SSNs (verification is the point). That is a distinct purpose mode — its own allowlist entry (craig-exchange), unverified emission permitted, the same audit event with a purpose discriminator — specced at #162 pickup. Until then this endpoint is the only full-SSN-emitting surface.