APP-07
Rider intent
OwnsConfirmed pickup/drop, selection and user acknowledgement
Must not inferUI cannot create booking, payment or driver state
AutoBuild your programPublic reference architecture
Mobility Orchestration & Rider
A truthful mobility promise from precise pickup to completed trip.
Separate serviceability, quote, booking, driver offer/acceptance, physical arrival, verified pickup, trip and support authority across platform and rider app.
Authority by layer
Know which component owns the state—and what it must never infer.
Every layer exposes an authoritative responsibility and an explicit non-authority boundary.
SAAS-07
Mobility platform
OwnsServiceability, quote, booking, assignment and trip lifecycle
Must not inferOffer is not driver acceptance or arrival
Driver app / fleet partner
Driver/vehicle source
OwnsAcceptance, arrival and trip execution evidence
Must not inferLocation proximity alone does not verify pickup
Payment / support / emergency
Partners
OwnsTheir own authorized transaction or response outcome
Must not inferPlatform receipt is not partner completion
End-to-end operating flow
State advances through evidence—not optimistic UI.
Each transition names both the action and the identity or version evidence that makes it reproducible.
- 01
Confirm pickup
Resolve entrance, side of road, landmark, accessibility and service area.
place/map identity · user confirmation · precision - 02
Quote
Bind service, ETA, price basis, terms, expiry and dependency.
quote ID/revision · fare/route versions - 03
Book and assign
Create booking against an immutable quote; offer eligible drivers distinctly.
booking/idempotency · assignment revision - 04
Verify pickup
Require declared driver/vehicle identity and pickup verification before trip start.
acceptance · arrival source · pickup proof - 05
Complete/support
Advance causal trip states and separate support receipt from human/emergency response.
trip revision · completion source · support correlation
Contract families
Interfaces that a production program must own.
Service/quote
Area, service class, ETA, price basis, terms and expiry.
Booking/assignment
Immutable quote binding, offer, acceptance and driver/vehicle identity.
Pickup/trip
Arrival, verification, start, progress, completion and cancellation.
Payment/support
Partner request/receipt, escalation and explicit response boundaries.
Designed degradation
Failure states stay truthful and useful.
Pickup ambiguous/out of area
Block price/booking until precise eligible pickup is confirmed.
Quote expired/stale
Reject booking and require a new quote; never silently reprice.
Driver proximity but no verification
Keep arrived/awaiting pickup; do not start trip.
Partner/payment/support unavailable
Expose pending/failed receipt without claiming transaction or human response.
Security & privacy controls
Privilege follows the narrowest useful boundary.
- ✓Trip/role-limited driver, vehicle and live location access
- ✓Pickup/contact masking and personal-safety controls
- ✓Quote/booking/trip revision and idempotency
- ✓Payment credentials remain with approved partner boundary
- ✓Support and emergency wording tied to authoritative response
Release evidence
A green demo is not a production acceptance case.
- 01Pickup entrance/side-of-road and accessibility journeys
- 02Quote expiry, assignment and cancellation race tests
- 03Driver acceptance/arrival/pickup causal state tests
- 04Offline rider/driver event replay and privacy
- 05Partner/payment/support outage and uncertain outcomes
Independently scopeable products
Compose the system without collapsing product ownership.
Each product can be bought and operated independently while sharing identity, context and lifecycle contracts.
OEM program workshop
Turn the Mobility Orchestration & Rider reference into your program architecture.
Confirm target products, vehicle and cloud boundaries, source systems, contract versions, deployment, validation and lifecycle ownership.