Frozen document. Dates and status refer to its original source. Private resources and unreviewed images are unavailable.
Workflow contract
Status: accepted. The owner approved the proposed workflow behavior on September 22, 2026. The authoritative resolution lives in Define workflow ownership, human decisions, and exception behavior.
This contract applies the accepted demo scope, roles, record ownership, fictional rules, and bilingual form contract. It defines observable behavior and process boundaries; it does not deploy BPMN or select a runtime edition.
Process boundaries
Use explicit process definitions for application intake, insurance claim/benefit review, employer leave, return to work, annuity withdrawal, and payment execution. Product-specific entry paths call reusable evidence-request, human-review, and payment activities where their contracts match. Sharing activities must not erase product or employer/insurance decision boundaries.
| Journey | Process outline |
|---|
| Life/Medicare supplement intake | Persist draft, submit, validate, review, request missing information/EOI if needed, review again, record approve/decline, create coverage on approval. |
| Disability/LTC benefits | Submit against coverage, validate, review evidence, request information if needed, record benefit decision, initiate separate payout if approved, show payment outcome. |
| Dental claim | Submit, validate, review, record decision, update permitted benefit use once through the coverage owner. No separate payout path. |
| Employer leave | Submit a continuous date range, validate reporting/employer context, manager review, request information if needed, record approve/decline. No automatic insurance-benefit approval or payment. |
| Return to work | Submit proposed return and required evidence, assigned reviewer evaluates evidence, manager receives only permitted status/return information, manager approves or requests information/declines. No medical document exposure to the manager. |
| Annuity withdrawal | Validate positive amount and available balance, review, authorize/reserve through the contract owner, initiate disbursement, finalize successful withdrawal once or recover/release an appropriate reservation after a confirmed terminal failure. |
| Premium collection/payment execution | Validate an authorized obligation/instruction and its synthetic account reference, attempt simulated payment, persist success/failure, reconcile uncertain outcomes, return the authoritative payment result. |
Leave and RTW have their own process instances linked to the employer case. Disability processing can run alongside them. Records are correlated by business identifiers; a related case does not inherit another case's permissions or outcome.
Starts, tasks, and assignment
Drafts persist outside a running Camunda process. Pin the compatible form bundle at first persistent draft/case creation, as already accepted. A validated submission creates a durable start request with a business correlation and duplicate guard. The UI may show submitted/processing while the start is being acknowledged. Repeated submission must not create a second business case or process for that purpose. The accepted Experience Layer contract defines durable start intent, owner deduplication, delivery receipts, and reconciliation. The selected engine start protocol requires focused verification in the later spec.
Use Camunda user tasks with the custom Atlas form-reference adapter. The task resolves a logical form from the business record's pinned release bundle. Neither a new task nor a language switch selects a newer form release. Process/task definition versions and their compatibility references are retained throughout the case.
For each user task, BPMN configuration supplies a stable logical screen/form reference and the task's allowed transition names. Camunda supplies task state and assignment; the BFF combines those facts with the authorized business record and the pinned Contentful release to build the server-driven UI response. Contentful supplies presentation and declarative field validation, while the business owner supplies data and domain checks. A request-for-information loop can select a different screen in the same pinned bundle without changing the case's release. Draft screens before process start resolve from the selected journey and draft state.
Assign customer-information tasks to the case owner, manager tasks to the employee's eligible reporting manager, and review tasks to an eligible seeded insurer reviewer for that product/case type. The initial demo uses deterministic assignments rather than a general claimable team inbox. Do not expose unassigned case evidence to all reviewers.
Manager delegation, impersonation, and an operational reassignment UI are deferred. If an assigned actor becomes ineligible or unavailable, the task remains pending/on hold; the system must not substitute a broader role automatically. Controlled reassignment and complex workload balancing can be added through a later scope decision. Reminders do not change the permission boundary.
Before accepting task actions, verify the authenticated actor, employer/personal context, assignment, task state, pinned release, and reviewed business revision. Duplicate or stale decisions must not cause another business update. The API contract requires durable action correlation and owner revision checks; only an accepted task decision may produce its authorized business effect. The later spec must detail recovery when engine acceptance races with a competing business update. Keep a durable correlation between the requested action, engine transition, and resulting business command so uncertain outcomes can be reconciled.
Human and business state
Human review outcomes are approve, request information, or decline with a customer-facing reason. Requests for information continue the same business case and include a customer task. Do not expose freeform reviewer notes or technical diagnostics as customer reasons without an approved field contract.
Represent business status separately from orchestration and payment status. A useful conceptual progression is draft, submitted, under review, awaiting information, decision recorded, fulfillment pending, and completed; declined and withdrawn are explicit business outcomes. Payment status remains separate, for example not initiated, pending, succeeded, failed, or outcome unknown. Exact enumerations and API mappings will be specified later.
A task completing means the human step was accepted, not that coverage creation, benefit-use update, or payment settlement succeeded. When business fulfillment is pending, say so. A payment failure must not turn an approved insurance decision into a declined claim. The UI translates the stable status/error codes into en-US or es-US from the pinned/current appropriate presentation catalog; changing language does not change process state.
Timers and technical failures
Timers create in-portal reminders and overdue indicators. They do not automatically approve, deny, medically clear, or pay a case. Use configurable intervals and a short demo setting rather than inventing statutory deadlines. External email/SMS notifications are outside the initial demo.
Represent business validation/rejection as explicit business paths. Retry transient technical failures within a bounded configured policy. Exhausted retries create an operator-visible incident and a suitable customer processing-delay status. Operators may retry or reconcile technical work within their role; they do not override reviewer decisions or edit business records.
If an external command's outcome is unknown, reconcile using its stable command/correlation reference before issuing another effect. Blind retries must not create duplicate payments, withdrawals, coverage, or benefit use. A temporary timeout is not evidence of payment failure or permission to release a withdrawal reservation.
Cancellation and financial consistency
Customers may discard their own drafts and request withdrawal of submitted work before the authoritative approval/financial-commitment boundary. The owner of the business record checks current state and revision. Only an acknowledged business cancellation interrupts the corresponding process/tasks. A race between approval and cancellation has one authoritative winner; no side relies solely on the button or cached task status.
After an approval or payment commitment, self-service cancellation of that action is outside the first demo. Reversals, refunds, post-issuance cancellation, and manual financial overrides are deferred. Exact commitment boundaries must be defined per operation in the API/workflow specs; the UI must not offer cancellation in uncertain or committed states.
Withdrawal availability checks and reservations are enforced by the contract owner. A confirmed successful disbursement finalizes the withdrawal once. Release a reservation only after an authoritative terminal failure/cancellation permits it; unknown outcomes remain in reconciliation. Dental benefit-use and payment updates also enforce their constraints atomically in their owning modules. The engine's retry behavior is not a substitute for these business invariants.
Capture the authorized synthetic payment-account reference on each instruction. A later account-profile change applies to future instructions; it does not silently redirect an existing one. Exact account-change verification belongs to the security/API decisions.
Evidence and boundaries
Keep correlation and history for submission, assignment, request-information loops, decisions, cancellations, retries, and resulting business outcomes. Record the pinned release, process version, actor/context, business revision, and submission locale where relevant. Exact audit fields, retention, and document permissions belong to the security decision.
The later specs must demonstrate an information-request loop, a stale/duplicate task action, separate leave and benefit decisions, a payment with an initially unknown outcome, a cancellation race, and resuming work in either supported language without changing its release. These are behavior contracts, not implementation tests written during discovery.