Deployment Path
Workstreams are prioritized by pilot impact and linked directly to the Reality Gaps that created them. Engineering work and stakeholder decisions remain visibly separate.
Reliable ride-state delivery
Priority 2Funded and auditable driver onboarding
Priority 3Transaction and cancellation controls
Priority 4Pilot support and incident ownership
Preserve ride-state transitions and operational visibility across temporary connectivity loss.
Define idempotent ride-event envelope and ordering rules
Engineering · Not Started
Implement durable local queue and reconnect replay
Engineering · Not Started
Design pending, synchronized, and failed state feedback
Product · Not Started
Operations lead
Decision requiredApprove the maximum acceptable synchronization delay during the pilot.
A driver can complete all required ride-state transitions during a 15-minute simulated outage, and each transition synchronizes exactly once and in order after connectivity returns.
Verify: Automated outage/reconnect scenario plus an operations-observer pilot rehearsal.
High exposure
Owner: Engineering leadRepeated or out-of-order events could corrupt the authoritative ride state.
Use immutable event IDs, server idempotency, and explicit ordering validation.
Align authentication cost, verification decisions, and driver-facing review status.
Model SMS attempts, failures, retries, and pilot cost ceiling
Finance · Not Started
Define and implement driver verification state transitions
Engineering · Not Started
Finance and operations
Decision requiredApprove a capped SMS budget or a tested alternative onboarding method.
Operations lead
Decision requiredName verification reviewers and a stalled-review escalation owner.
Every supported onboarding path has an approved cost and tested failure path.
Verify: Finance sign-off and scripted delivery-failure test.
Every pilot driver has a visible verification state, assigned reviewer, timestamped decision, and retained reason before ride access is granted.
Verify: Review five seeded approval/rejection scenarios in the audit history.
High exposure
Owner: Operations leadAuthentication delivery or a stalled review could block eligible drivers.
Define a funded fallback and a named review-escalation owner.
Make wallet activity auditable and cancellation behavior operationally consistent.
Implement immutable wallet events and reconciliation export
Engineering · Not Started
Encode the approved cancellation decision table
Product · Blocked
Product, operations, and finance
Decision requiredApprove cancellation stages, fees, reasons, and support messaging.
Finance can reproduce each pilot wallet balance from ordered immutable events and identify every adjustment actor and reason.
Verify: Reconciliation test against seeded credits, debits, reversals, and adjustments.
Every ride stage has one approved, test-covered cancellation outcome.
Verify: Product decision-table review and transition test suite.
Medium exposure
Owner: Product leadUnresolved policy decisions may block consistent implementation.
Time-box a cross-functional decision workshop before engineering starts.
Give every pilot incident a severity, accountable owner, response target, and escalation path.
Define incident severity and escalation workflow
Support · Not Started
Publish pilot support and after-hours runbook
Operations · Not Started
Pilot sponsor
Decision requiredAssign after-hours incident ownership and approve response targets.
A pilot exercise routes urgent, payment, and routine scenarios to named owners within their approved acknowledgement targets.
Verify: Timed tabletop exercise with support, operations, finance, and engineering.
High exposure
Owner: Pilot sponsorShared ownership may still leave urgent incidents without a decision-maker.
Assign one accountable role per incident level and publish a backup rota.
Decision view