RequiemOS handles that with a module pipeline: a library of reusable workflow building blocks, assembled into tenant-specific templates by Requiemos platform staff.
A case is not a fixed phase progression. It is an ordered sequence of module instances, each consuming and producing a shared context envelope.
48 reusable workflow building blocks. Platform-managed, not tenant-scoped. Each module has defined inputs, outputs, prerequisites, and a completion rule.
Tenant-scoped ordered sequences of module references. Platform staff clone starter templates and adjust per-tenant during onboarding. Versioned; in-flight cases stay on assigned version.
When a case is created, the appropriate template is materialized as a per-case execution. Each module instance gets its own execution record. The context envelope accumulates as modules complete.
A JSONB document that flows between modules. Each module reads what it needs, performs its work, writes its outputs. The envelope grows as the case progresses. Modules that don't apply pass it through unchanged.
The envelope carries routing and decision data only — not the system of record. Deceased person details live in the deceased table. Assets live in the assets table. CoC events are immutable in custody_events. The envelope just carries the flags downstream modules need to read.
Director answers initial call. Captures identity, time of death, death location.
Reads death location. Determines whether ME jurisdiction applies. Branches accordingly.
Arrangement conference. Major envelope-enriching module. Downstream modules read disposition_type.
48 module definitions across 7 phase hints. Phase is a library organization label only — templates can sequence modules from any phase in any order. Click any module to expand its definition.
A template is an ordered sequence of module references scoped to a tenant. Six starter templates ship at MVP. Pick any two below to see how dramatically the pipelines diverge — same module library, completely different cases.
A standard cremation at Kearney. First call Monday morning, cremation Thursday, remains returned Friday. Here is what the pipeline looks like in practice, grouped by phase. Each row is a module instance with its own execution record.
Compliance-critical modules — chain-of-custody scans, cremation authorization, asset terminal checks — are immutable in templates. Platform staff cannot remove them. Staff cannot skip them on a case. This is how regulatory compliance is enforced by design.
CoC scan modules (pickup, receiving, disposition) write to custody_events as immutable records. Corrections use a supersession pattern — the original record is never modified. The audit trail is permanent.
The asset_terminal_check module queries the assets table directly — not the envelope — and blocks case closure if any asset is not in a terminal state. Cremation authorization gate blocks crematory coordination. These are hard gates, not advisories.
The module catalog is a hypothesis. Discovery sessions with Kearney are needed to validate naming, sequencing, and boundaries before the library is seeded. The data model and engine (Sections 7–8 of the PRD) can proceed in parallel.
When a coroner hold is active, downstream modules need to suppress until released. MVP approach: an envelope flag that suppressing modules check via skip_condition, plus a manual "hold released" module. Dynamic module insertion is Phase 2.
Cases that originate from a pre-existing arrangement should auto-populate the envelope and mark arrangement modules N/A. Requires a pre-need data model that doesn't exist yet. Deferred to Phase 2 unless Kearney has active pre-need cases at pilot.
Repatriation involves multiple transfers, consular paperwork, and freight coordination. Open question: is it complex enough to warrant a starter template, or is it an optional-module overlay on an existing template? Validation needed from Kearney.
As modules accumulate, envelope keys risk collision. Proposal: namespace by phase (intake.*, arrangement.*, compliance.*) and maintain a key registry in a companion schema doc.
Canadian vs. US regulatory differences may require jurisdiction-aware locked modules. MVP: all locked modules are global. Filtering by jurisdiction is Phase 2.
Does arrangement typically precede transfer at Kearney, or follow it? Does this vary by death location? How many transfers does a typical case involve? These answers shape the starter template sequencing — top-priority discovery items for Zareef.
The existing case_status enum (intake, arrangement, preparation, disposition, closed) reflects a linear model. With the module pipeline, status becomes a derived display value, updated by system_event modules at key transitions. Mapping needs explicit definition before implementation.
PRD summary says 43 modules; the catalog actually lists 48. PRD says ~12 locked; catalog has 19. Worth a reconciliation pass before this gets seeded into the database.