Canonical-store subject-erasure surface — register item 27, build half

Date: 2026-08-18 Lane: canonical-erasure-it27 (branch claude/canonical-erasure-surface-it27) Spec executed: docs/reports/CANONICAL_ERASURE_LEG_2026-08-12.md §4 (all five requirements) Truth discipline: everything below is implemented unless labeled otherwise; the platform ceiling built, pre-benchmark applies. Nothing here is deployed.

What was built

Store redaction primitive — Store.redact() in contracts/mizoki_contracts/store.py: tenant-checked (dotted-path support for nested tenant fields; a cross-tenant doc_id raises TenantMismatch before any write or audit record), overwrites with the caller's tombstoned body, then appends a doc.redact record to the audit chain. The chain is append-only and global, so erasure appends — never mutates — and verify_chain() stays intact (test-asserted). Absent docs return {"status": "absent"} (idempotent, no existence oracle).
Erasure module — contracts/mizoki_contracts/erasure.py. The §4.4 design decision this lane owned: redaction, never deletion. Envelopes are content-addressed and the platform promises deterministic replay, so a matched document keeps its event_id, hashes, and time axes; payload becomes a tombstone, entity_ids are removed (conservative — a matched row is about the subject), and outbox/DLQ rows get envelope_json re-serialized from the redacted envelope so a later publish or DLQ replay ships the tombstone (both directions test-proved with a seeded PII marker). Receipt contract is the cell33 pattern (count → redact → recount; worst-wins fold; zero receipts = failure; nothing reports erased without the verifying recount). Firestore documents have no streaming-buffer analogue, so the tri-state collapses to erased/failed — anything unconfirmable is non-2xx.
POST /api/v1/subjects/erase on services/service-canonical-ingestion/main.py — verify_caller + resolve_tenant, covers all three envelope copies (events, events_outbox, events_dlq, including the dead-row-in-both case), appends a subject.erase chain record carrying only the salted subject_ref and counts (the chain is immutable; raw identifiers written there could never themselves be erased — test-asserted). An audit-append failure downgrades the response to 502: an erasure the chain cannot attest is unproven. /health now declares subject_erasure: true and default_subject_salt_in_force (the CANONICAL_SUBJECT_SALT posture, same convention as Cell 38).
Tests — tests/governance/test_canonical_subject_erasure.py, 23 tests, the first tests this service has ever had, deliberately placed in tests/governance/ because CI runs that suite today (tests/remediation/ is largely un-gated — the PR-689 lesson). Coverage both directions: three-copy redaction, tenant isolation (cross-tenant rows untouched and cross-tenant redaction hard-refused), idempotent re-erase, unknown-subject 200, empty-identifier 422, failure injection → 502 with failed receipts, scan-failure-before-verification → 502, corrupt outbox row cannot fake an erasure, redacted pending row publishes the tombstone, DLQ replay after redaction ships the tombstone, chain intact after everything, salt sensitivity.

Measured gates

tests/governance (CI-gated): 207 passed (184 pre-existing + 23 new), fresh py3.14 venv, pip install -e contracts + CI's pins.
tests/remediation/test_execution_adapters.py (the pre-deploy gate of the workflow this merge dispatches): passed in the same venv.
tests/remediation/test_data002_outbox.py: passed. test_contracts_hardening.py: 1 failure, reproduced byte-identical on untouched origin/main (pre-existing, not CI-gated; venv lacks google-cloud libs — recorded, not chased in this lane).
Hygiene greps (V1/V2) clean on every touched file; claude_memory.py check --strict PASS.

Honest limits (open, with owners)

NOT deployed. service-canonical-ingestion has no CI deploy workflow (measured; it ships only via ops/remediation/deploy_all.sh, which deploys all ten governance services together). Merging this lane deploys the action-runner (its workflow watches contracts/**) but not the canonical service. The serving canonical revision keeps answering 404 on the new route until an operator deploy. Rule 04 says the fix for a missing CI path is a workflow — that is a .github/** protected-path change deliberately left out of this lane; it needs its own human-merged PR.
Gateway leg untouched, deliberately. The canonical_eraser client injection behind CANONICAL_ERASER_URL in service-marketing-connectors is the small, already-designed follow-up — left out because that path is claimed by the live cre-p2-takeover lane. The customers_redact compliance leg keeps reporting pending_in_build (test-pinned in both connector suites) until the client lands and the canonical service is deployed.
Scale: subject matching scans via list_all and filters in-process — correct and honest at today's measured near-zero canonical volume (register item 26: no BQ landing table, zero bus subscribers), stated in the module docstring; an indexed identifier query is required before high-volume ingest.
CANONICAL_SUBJECT_SALT is an operator secret; until set, default_subject_salt_in_force: true is served on /health and stamped in every erasure response.
Any future BigQuery landing table joins the three-copy list (§4.3 of the spec) — the erasure module's SUBJECT_COLLECTIONS is the single place to extend.