Use the reviewed order state reference contract

Driver App presents orders through current, past, grouped, logistics, detail, and action-specific views. These views combine returned order data with client configuration, local transformations, cached state, and realtime hints. A label, tab, card position, or visible action is not authoritative workflow state.

This reference intentionally omits internal numeric status values. Integrations must use reviewed semantic categories and server-owned transition contracts.

Availability

Surface	Current public boundary
Current orders	Configured pending, in-progress, or combined active categories
Past orders	Configured completed and cancelled categories
Detail	Returned status plus client-derived phase and conditional controls
Grouped cards	Client display transformation of related returned members
Logistics requests	Separate assignment-request lifecycle, not a standard order category
Driver availability	Profile/account state for receiving work; not a guard on every detail view
Offline/realtime	Cached rows and events can alter presentation without proving convergence

Prerequisites

• Use an authenticated Driver and only records the Driver is authorized to view.
• Preserve the distinction between returned server state, configured category, client-derived phase, local cache, and realtime event.
• Re-read authoritative state before any action; never use a card label or control visibility as transition eligibility.
• Treat grouped members and logistics assignments individually unless a reviewed server contract explicitly provides atomic group behavior.
• Keep list, detail, socket, storage, location, assignment, and status effects outside documentation runtime.

Responsibility boundaries

Owner	Responsibility
API/order domain	Authoritative order state, ownership, allowed transitions, concurrency, and receipts
Assignment domain	Logistics request ownership, expiry, decision, and assignment state
Driver App configuration	Map returned states into visible semantic categories
List controller	Filter, paginate, sort, transform grouped rows, and apply local/socket changes
Detail UI	Render returned state and client-derived phase; expose conditional controls
Availability owner	Determine whether the Driver can receive work; not retroactively authorize order actions
Offline/realtime owners	Cache and transport hints; not workflow authority

Inputs and result

Categories and client-derived state

Current and past tabs are presentation categories assembled from configuration. Detail components can derive a broader phase from returned fields and use it to show copy or controls. The same order can therefore appear differently across a list, detail, grouped member, cached view, or later event.

Treat the returned server state as one input, not as permission to perform the next action. The server must validate the requested transition against current ownership, state, locks, configuration, and related requirements.

Availability and order access

Driver availability controls receiving-work behavior, but current detail source does not consistently guard visibility or every action with the profile toggle. An unavailable Driver may still have accessible assigned work. Conversely, availability does not establish ownership, assignment, or transition eligibility.

Grouped and logistics distinctions

Standard grouped cards are a client transform over related returned orders, not a user-selectable grouping rule or one atomic server entity. Current composition hides group mutation controls by default; members can still have separate detail navigation.

Logistics cards represent assignment requests with their own expiry, ownership, and decision lifecycle. Do not classify them as ordinary grouped orders or infer acceptance from visibility.

Security and privacy

• Do not publish internal status codes, private transition maps, endpoints, payloads, record identifiers, socket rooms, or operational data.
• Enforce ownership and current state on the server for every transition.
• Use optimistic/local/socket state only as presentation until reconciled with an authoritative read and result receipt.
• Apply authorization per grouped member and per logistics request; never trust client grouping as an authorization boundary.
• Treat cached rows, card assets, customer/business data, and event payloads as private and potentially stale.

Limits and failure states

State	Required interpretation
Current/past tab label	Configured category, not universal workflow taxonomy
Card visible	Returned/cached/local candidate, not current ownership or eligibility
Control visible	Client condition passed; server acceptance remains unknown
Detail phase	Client-derived presentation, not a portable server state
Driver unavailable	Receiving-work state; existing detail may remain accessible
Group card	Display transform; members can differ and effects need not be atomic
Logistics request	Assignment candidate with separate lifecycle
Realtime move/update	Transport/local change, not ordered durable truth
Offline card	Cached state with unknown freshness
Empty category	No visible matching rows, not global absence

Troubleshooting

List and detail show different states

Compare the selected category, cached/realtime state, and client-derived phase. Re-read through the approved order source; do not trigger a status action to force convergence.

A status control is visible for an unavailable Driver

Do not treat availability as the action guard. Verify assignment, ownership, current state, lock, configuration, and action-specific requirements separately.

A grouped card looks ready for one action

Inspect members separately. Current group actions are not productively available by default, and source does not establish atomic success across members.

A logistics request appears in Orders

Use the assignment-request contract. Visibility does not prove that the request is pending, unexpired, owned, or successfully accepted.

Related guides: Find deliveries · View grouped deliveries · Review logistics requests · Understand an active delivery · Edit Driver profile and availability