Canonical lifecycle-boundary demonstration
Synthetic review-request delivery lifecycle
Seven fixed synthetic lifecycle scenarios and four rejected commands are passed to the canonical boundary. This is read-only demonstration evidence, not a delivery console or production workflow.
Synthetic delivery lifecycle — no request is sent or persisted
The lifecycle validates only the supplied record, command shape, authorization boolean, verified-event boolean, allowed transition, and terminal time. Trusted regional code must still authenticate the actor, establish authorization identity, scope, and freshness, verify provider signatures and replay controls, load current state, create suppression where required, classify retryability, transact persistence and delivery-attempt updates, recheck dispatch controls, enqueue or retry, decrypt only at the approved provider boundary, and call an approved regional provider. Accepted provider work cannot be recalled; later verified complaint and opt-out evidence may update the lifecycle. Exact terminal state-and-time replay is idempotent, but this lifecycle does not prove event identity.
No campaign, request, customer, contact, message, webhook, suppression, retry, queue item, delivery attempt, database row, audit event, production evidence, or provider request is created.
Fixed canonical outcomes
Scenario 1 of 7
Delivered journey
Allowed- Ordered state path
- queued → dispatching → accepted → delivered
- Final state
- delivered
- Terminal time
- 2026-07-20T09:00:00.000Z
- Authorization input used
- Trusted authorization: true for start dispatch
- Verified-event input used
- Verified external event: true for acceptance and delivery
A verified delivery result becomes terminal at the supplied canonical time.
Scenario 2 of 7
Out-of-order verified delivery
Allowed- Ordered state path
- dispatching → delivered
- Final state
- delivered
- Terminal time
- 2026-07-20T09:00:00.000Z
- Authorization input used
- Trusted authorization: true established dispatching
- Verified-event input used
- Verified external event: true for delivery
The canonical boundary allows verified delivery directly from dispatching.
Scenario 3 of 7
Verified provider failure
Allowed- Ordered state path
- dispatching → failed
- Final state
- failed
- Terminal time
- 2026-07-20T09:00:00.000Z
- Authorization input used
- Trusted authorization: true established dispatching
- Verified-event input used
- Verified external event: true for provider failure
A verified provider failure becomes terminal at the supplied canonical time.
Scenario 4 of 7
Later verified complaint
Allowed- Ordered state path
- delivered → failed
- Final state
- failed
- Terminal time
- 2026-07-20T10:00:00.000Z
- Authorization input used
- Trusted authorization: not required for provider complaint
- Verified-event input used
- Verified external event: true for later complaint
Later verified complaint evidence may update a delivered lifecycle to failed.
Scenario 5 of 7
Later verified opt-out
Allowed- Ordered state path
- delivered → opted_out
- Final state
- opted_out
- Terminal time
- 2026-07-20T10:00:00.000Z
- Authorization input used
- Trusted authorization: not required for opt-out evidence
- Verified-event input used
- Verified external event: true for later opt-out
Later verified opt-out evidence may update a delivered lifecycle to opted out.
Scenario 6 of 7
Unknown reconciliation
Allowed- Ordered state path
- accepted → unknown → accepted
- Final state
- accepted
- Terminal time
- Not terminal
- Authorization input used
- Trusted authorization: not required for reconciliation event
- Verified-event input used
- Verified external event: true for unknown and acceptance
Verified reconciliation moves accepted work through unknown and back to accepted.
Scenario 7 of 7
Authorized queued cancellation
Allowed- Ordered state path
- queued → cancelled
- Final state
- cancelled
- Terminal time
- 2026-07-20T09:00:00.000Z
- Authorization input used
- Trusted authorization: true for cancellation
- Verified-event input used
- Verified external event: not required
Only queued work can be cancelled; accepted provider work cannot be recalled.
Fixed rejected commands
| Scenario | Attempted command | Starting state | Canonical error code |
|---|
| Unauthorized dispatch | start_dispatch | queued | REVIEW_REQUEST_AUTHORIZATION_REQUIRED |
| Unverified acceptance | provider_accept | dispatching | REVIEW_REQUEST_VERIFIED_EVENT_REQUIRED |
| Cancellation after acceptance | cancel | accepted | REVIEW_REQUEST_COMMAND_NOT_ALLOWED |
| Opt-out time regression | opt_out | delivered | REVIEW_REQUEST_COMMAND_TIME_REGRESSION |