What the platform tracks, why it is append-only, and what it refuses to let happen.
Chain of custody is the platform’s primary regulatory differentiator. The architecture sits on three data structures — custody_events, assets, and implanted_devices — and a small set of locked workflow modules that drive them. This page describes the surface in roughly the order a case touches it.
Custody of the deceased from removal at the place of death to final disposition. Remains-level events recorded on custody_events with scan-driven event sources where the QR infrastructure is live and operator-attested entries where it is not.
Every item other than the remains that arrives with the deceased — wedding ring, glasses, wallet, clothing, religious items. One row per item on assets, with a tracking ID and bag ID, photographed on intake and decided per item during arrangement.
Pacemakers, ICDs, certain orthopedic and radiotherapy implants. One row per device on implanted_devices, examined in preparation and resolved before disposition. Removed devices become asset rows in their own right; cleared devices remain with the deceased.
Asset-level events reference the asset in description rather than via a polymorphic column. Polymorphic targeting is flagged in ADR-022 Future Work for when asset-level event querying earns the schema change.
Every state change appends a new row. The table grows; it does not change.
A correction is a new row that references the prior row with a captured reason. The original stays visible.
Family intent is captured during arrangement on intended_disposition; the operational status resolves at execution. The case cannot close while any asset sits between them.
returned, with_remains, or released; no asset in received or in_custody; no asset still at pending_decision. The third condition catches assets where a disposition decision was somehow skipped despite the locked execution module — belt and braces against silent loss of family intent.
The medical_device_check module runs in preparation, after remains_id_verify and before any disposition module. For cremation, aquamation, and green-burial-involving-cremation cases, it is a hard gate: every implanted_devices row for the deceased must resolve to one of three outcomes before the workflow proceeds.
Device is physically explanted. An assets row is created with category medical_device and intended disposition medical_disposal. A custody event records the removal.
Surgical screws, fixed dental implants, certain orthopedic hardware present no cremation hazard. The device row records the clearing reason and remains with the deceased.
Examination did not find the previously reported device. Rare; possible. The row records the discrepancy.
At case close, the platform generates a PDF report containing the full custody record for the case. The report is persisted as a case_document with a SHA-256 hash recorded on the row for tamper evidence. The same report can be regenerated on demand at any point in the case’s life as a derived view.
One universal format at MVP, designed to exceed the requirements of every Canadian province currently in scope plus the Illinois Integrity in Death Care Act. Per-jurisdiction variants are deferred to Phase 2 once specific gaps emerge.
custody_events row in chronological orderThis is the conceptual surface. The PRD that owns this aggregate is a stub today — see PRD/chain-of-custody-prd.md — pending the full rewrite when the chain-of-custody implementation arc surfaces. The workflow orchestration that drives the lanes lives in ADR-022. The four-layer audit architecture — including the supersession pattern and the Layer 3 mirror-entry mechanism — lives in ADR-014. The aggregate boundaries are set in ADR-016.
Out of scope here: the persona-specific UI surfaces (Rob’s scan flow, the daily prep board, David’s at-removal capture), the per-province regulatory mapping, and the post-MVP family-facing export. Those land when the PRD is rewritten.