Reality Map
The map separates requirements, constraints, assumptions, current capabilities, and unresolved questions before cross-source gaps are assessed.
Operations requires continuous ride-state visibility throughout every active journey.
Organizational intentMetroMove pilot management requirements“Ride status updates must be recorded continuously from driver acceptance through trip completion so the operations desk can monitor every active journey.”
Management requires SMS one-time passwords for driver onboarding.
Organizational intentMetroMove pilot management requirements“New drivers must complete onboarding using SMS one-time passwords before they can access pilot rides.”
Operations requires every pilot driver to be verified before participation.
Organizational intentMetroMove pilot management requirements“Only drivers verified by operations may participate in the pilot, and finance must be able to reconcile every wallet credit, debit, and adjustment each week.”
Finance expects weekly transaction-level wallet reconciliation.
Organizational intentMetroMove pilot management requirements“Only drivers verified by operations may participate in the pilot, and finance must be able to reconcile every wallet credit, debit, and adjustment each week.”
Organizational intentPilot budget and operating assumptions“The budget assumes that transaction-level history will already be available and does not fund manual reconstruction of balances.”
The onboarding design assumes a paid messaging provider without a funded fallback or cost ceiling.
Organizational intentPilot budget and operating assumptions“The onboarding estimate assumes one paid SMS delivery for every sign-in attempt through an external messaging provider.”
Technical realityCurrent architecture and feature summary“SMS one-time-password onboarding is designed around a paid external messaging provider.”
Drivers experience mobile-data outages lasting long enough to interrupt ride-state updates.
Field realityDriver discovery interview notes“Drivers reported that mobile data frequently drops on the eastern and hillside routes, sometimes for ten to twenty minutes.”
Field realityDriver discovery interview notes“Several drivers said they cannot tell whether a ride-status change was saved when the signal disappears, so they retry manually after connectivity returns.”
The approved budget excludes SMS and third-party verification costs.
Organizational intentPilot budget and operating assumptions“It includes no line item for SMS messages, paid identity checks, or third-party verification fees.”
The current ride-state implementation requires an online request and has no durable offline recovery path.
Technical realityCurrent architecture and feature summary“All ride-status transitions are written directly to the online application API. There is no local event queue, durable offline store, or reconnect synchronization.”
The current product has a verification flag but no complete submission, review, or audit workflow.
Field realityDriver discovery interview notes“They could not see whether a document was received, under review, rejected, or approved, and they did not know who to contact when verification stalled.”
Technical realityCurrent architecture and feature summary“Document submission, review states, reviewer assignment, rejection reasons, and verification audit history are not implemented.”
Current wallet records do not retain the immutable event history needed for reconciliation.
Technical realityCurrent architecture and feature summary“They do not preserve immutable transaction events, adjustment reasons, actor identity, or a reconciliation ledger.”
Allowed cancellation stages, reasons, and fees remain unresolved.
Organizational intentMetroMove pilot management requirements“The approved requirements do not define which ride stages allow cancellation, what reasons are required, or when a fee applies.”
Field realityRider support feedback summary“Riders said they need to cancel when a driver is delayed or moving away from the pickup point, but they do not know when cancellation stops being available.”
Technical realityCurrent architecture and feature summary“The service contract does not define permitted cancellation transitions after matching or after a driver starts toward pickup.”
Urgent incident ownership, escalation targets, and after-hours coverage remain unresolved.
Organizational intentPilot budget and operating assumptions“Incident escalation, after-hours ownership, response targets, and responsibility for service-wide failures have not been assigned.”
Field realityRider support feedback summary“In the current rehearsal, support agents could not identify who owns an urgent escalation after business hours or how quickly an incident should be acknowledged.”
Technical realityCurrent architecture and feature summary“The product has no incident severity, escalation schedule, assigned incident owner, after-hours rotation, or response target.”