Frozen document. Dates and status refer to its original source. Private resources and unreviewed images are unavailable.
Record ownership and domain boundaries
Status: accepted. The owner accepted the proposed ownership model with "Yes. proceed" after reviewing the component boundaries and the persistent modular backend simulator. The authoritative resolution lives in Assign authoritative business records and domain boundaries.
The component diagram below predates the later BFF decision and names MuleSoft as the mediator. For the selected implementation and the supplied reference-diagram comparison, see Atlas system context and ADRs 0008, 0009, and 0010. The record-ownership rules on this page remain accepted.
Component responsibilities
| Component | Authority | Boundary |
|---|
| Contentful | Authored content, form templates, and publishing metadata. | Does not own submitted answers, customer applications, claims, bank details, or private uploaded evidence. |
| Camunda | Process instances, tasks, assignments, timers, and orchestration progress. | Variables hold business references and minimum step data. Process state is not the authoritative policy, claim, or payment record. |
| MuleSoft Experience Layer | Authorized experience/system API mediation, aggregation, mapping, and integration transport. | Does not own the business ledger or replace Camunda's BPMN orchestration. |
| Simulated systems of record | Persistent business records, drafts, submitted answers, decisions, and business statuses. | Fictional data and integrations still have durable, internally consistent state. |
| Document storage and registry | Storage holds file bytes. The business registry holds metadata, versions, links, and access context. | Private evidence is not stored as Contentful assets or copied into workflow variables. |
| Keycloak IAM | Login identity, credentials, MFA configuration, and assigned identity roles. | Employer membership, reporting lines, policy ownership, and case relationships remain business records. |
| React SPA | Rendering and temporary interaction state. | Persisted drafts and submitted records belong to their backend owners. |
The owner agreed to one deployable backend simulator with logical business modules and persistent structured storage, plus document storage. Module boundaries remain explicit even when modules share a deployment. Database and document-storage products are not selected by this decision.
Logical ownership diagram
This diagram shows authority and record references, not a final network topology or API call sequence.
flowchart TB
CMS["Contentful: content and form definitions"]
BPM["Camunda: processes, tasks, assignments, timers"]
IAM["IAM: login identity, credentials, MFA, identity roles"]
API["MuleSoft: experience and system API mediation"]
UI["React SPA: rendering and temporary state"]
subgraph SOR["Persistent modular backend simulator"]
PEOPLE["People and organizations"]
INTAKE["Intake and saved answers"]
COVERAGE["Coverage and benefits"]
CLAIMS["Claims and benefit requests"]
LEAVE["Leave and return to work"]
MONEY["Billing and disbursements"]
DOCS["Document registry"]
end
FILES["Document storage: file bytes"]
INTAKE -. "form release reference" .-> CMS
BPM -. "business record references" .-> SOR
PEOPLE -. "identity reference" .-> IAM
DOCS -. "storage reference" .-> FILES
CLAIMS -. "related case reference" .-> LEAVE
CLAIMS -. "authorized payout instruction" .-> MONEY
API -. "mediates access; does not own records" .-> SOR
UI -. "consumes API views" .-> API
The Camunda assignment is authoritative for a workflow task. A reference or read view in another component must not become an independently editable copy of that assignment. The accepted workflow contract defines deterministic assignment and checks assignment, eligibility, task state, and reviewed business revision before an action is accepted.
Business modules
| Logical owner | Owned business records |
|---|
| People and organizations | Customers, employers, employees, reporting relationships, and links to IAM identity. |
| Intake | Applications, persisted drafts, submitted answers, requests for evidence, and application decisions, with references to the form release and process version used. |
| Coverage and benefits | Policies, annuity contracts, ownership and insured relationships, beneficiaries and dependents, enrollments, entitlements, and benefit-use records. |
| Claims and benefit requests | Claims/requests, evidence references, review outcomes, and authorization of benefit-payment instructions. |
| Leave and return to work | Employer leave cases, requested dates, business approvals, RTW status, and links to related disability claims. |
| Billing and disbursements | Premium obligations, synthetic payment-account references, debit authorizations, collection attempts, received payout instructions, and simulated payment outcomes. |
| Documents | Document metadata and versions, associations with business records, storage references, and access context. |
Each module updates its own records through explicit contracts. A shared deployment does not allow one module to mutate another owner's records directly. The Experience Layer contract defines owner-controlled commands and delivery. Exact schemas and persistence products remain downstream.
Claim approval authorizes a payment; the payment outcome is a separate record owned by billing/disbursements. Similarly, employer leave approval and an insurance benefit decision remain separate facts even when cases are linked. Dental benefit-use records belong to coverage/benefits; a claim outcome drives an explicit update rather than silently changing another module's data.
Identifiers and relationships
Use stable identifiers for business records and explicit references between people, employers, policies/contracts, applications, claims, leave cases, payment instructions, and documents. Keep business identifiers distinct from IAM subjects, Camunda process/task keys, and Contentful entry/release references.
A customer's personal policy does not become employer-owned because the person also has an employment relationship. Employer context and personal ownership are separate links. References between an employer leave case and an insurance claim do not expand manager visibility. The accepted role matrix applies when resolving any linked record.
Draft and submitted answers are persistent business data. The accepted form contract pins an immutable bilingual release when a persistent draft/case is created and records submission locale. A derived release resolver/registry is a separate logical module in the backend deployment; it retains reproducible published content without becoming a new authoring authority. The workflow contract defines process/task binding behavior. Exact interfaces and storage products remain downstream decisions.
State and consistency
The record's owner is authoritative for its business state. Other components use identifiers or explicitly non-authoritative read views. Camunda is authoritative for orchestration state. Completing a task does not by itself prove that the corresponding domain update, coverage creation, or payment completed.
Coordinate cross-component work using acknowledged, retry-safe commands and correlation identifiers. Expose pending or recovery states when a result is uncertain and reconcile outcomes. Do not assume one atomic transaction across Contentful, Camunda, MuleSoft, and business storage. The workflow contract establishes bounded retries, explicit pending/unknown outcomes, and reconciliation before repeating uncertain effects. The accepted Experience Layer contract specifies durable operations, owner outboxes/consumer receipts, polling, and duplicate/revision checks. Exact schemas and recovery sequences remain for specs.
For example, a reviewer completes a claim-review task, the claim owner records the business decision, and the payment owner records a separate simulated payout outcome. A linked leave case keeps its own status and manager-visible information. A timeout after any step must not be presented as proof of either payment success or failure.
Downstream decisions
- Accepted form contract: the schema/release/binding design is agreed; later specs supply exact content types and interfaces.
- Accepted workflow contract: process/task boundaries, assignment, completion, cancellation, and recovery are agreed; later specs supply exact BPMN and state enumerations.
- Accepted Experience Layer contract: commands, queries, errors, idempotency, and reconciliation boundaries are agreed; later specs supply exact schemas and protocols.
- Accepted security contract: Keycloak, MFA, enforcement, secrets, document access, audit, and retention requirements are agreed; runtime details and validation remain downstream.
- Runtime topology: runtime profiles, persistence products, deployment arrangement, and required accounts.
This decision does not select product eligibility rules, storage vendors, infrastructure resources, or implementation language.