The pilot requires continuous ride updates, while drivers report material coverage gaps and the current architecture has no durable offline queue or reconnect synchronization.
Source alignment
Every quote below is an exact substring of its linked fixture source and is checked against stable chunk offsets.
“Ride status updates must be recorded continuously from driver acceptance through trip completion so the operations desk can monitor every active journey.”
MetroMove pilot management requirements
Open complete source“Drivers reported that mobile data frequently drops on the eastern and hillside routes, sometimes for ten to twenty minutes.”
Driver discovery interview notes
Open complete source“All ride-status transitions are written directly to the online application API. There is no local event queue, durable offline store, or reconnect synchronization.”
Current architecture and feature summary
Open complete sourceOperational / business
Operations may lose visibility of active journeys, and riders may lose confidence when trip progress appears stale during the pilot.
Technical
Ride-state transitions can fail or disappear when connectivity drops, leaving server state incomplete or out of sequence.
Introduce a local event queue with idempotent replay, visible pending state, and reconnect synchronization before pilot expansion.
Acceptance criteria
Linked deployment workstream
Preserve ride-state transitions and operational visibility across temporary connectivity loss.