Model return workflow steps as durable facts with explicit pending states
The return row has one status called processing, hiding whether inspection, label issuance or refund is outstanding.
- Focused work estimate
- 1h 30m + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Workflow modeling · Uncertainty
Estimated field mix
- Distributed systems60%
- Backend40%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional equipment-rental service approves returns through several provider calls. Partial failures leave labels issued without inspections or refunds reported before provider confirmation.
Setup prerequisites
- Create synthetic return records and fake inspection, shipping and refund adapters.
- Use integer money values and no real payments or messages.
Preceding work
No earlier ticket is required. Complete the project setup above.
Acceptance criteria
- Represent each step's request and observed outcome separately.
- Define legal workflow transitions and terminal conditions.
- Keep unknown provider outcomes distinct from failure.
Implementation constraints
- Use synthetic provider receipts only.
Verification to include
- Trace a successful return through all declared facts.
- Timeout shipping after acceptance and retain an unknown label outcome.
Deliverables
- Return state model
Rollout and recovery
Review the state table before adding adapters; preserve ambiguous existing cases as unresolved.
Value of the work
For the engineer: Practice durable workflow state, compensation and uncertain outcomes.
For the team: Review recoverable business operations without assuming distributed transactions.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.