AI-enabled transportation work: build an exception decision packet before changing operations

Bound the operating exception

Start with the decision, not the model. Name the event, affected route or asset, decision deadline, current operating state, relevant time zone, and conditions that would make the situation materially different. Separate observed facts from forecasts and assumptions.

The U.S. Department of Transportation AI activities page describes AI work across transportation-system integration and internal operations, research, and citizen-facing services. It also links the department's current strategy materials. This is evidence that the sector spans multiple modes and operational contexts, not proof that a particular AI recommendation is safe.

NIST's AI RMF Core calls for intended purpose, deployment context, knowledge limits, human oversight, and relevant risks to be documented. The framework is voluntary, and NIST states that version 1.0 is being revised. Here it supports a practical discipline: define the context in which a recommendation will be used before deciding how much reliance it deserves.

Sources: [1] [2]

Assemble the seven-part packet

Create one concise record with these fields:

Do not turn the packet into a generic checklist. A maintenance deferral, dispatch change, capacity adjustment, and public notice have different evidence and decision owners. Record only the fields that could change the decision or make it auditable.

• Exception statement: what changed, when it was detected, and which operation is affected.
• Evidence window: source systems, timestamps, freshness, missing records, and any conflicting observations.
• Constraints: safety rules, service commitments, crew or asset limits, customer needs, and authorization boundaries.
• Options: feasible responses, including continuing the current plan, with dependencies and reversible steps.
• Checks: calculations, source traces, threshold tests, and an independent comparison against the operating record.
• Decision: selected option, accountable owner, time made, and unresolved uncertainty.
• Follow-through: customer communication, monitoring signal, stop trigger, handoff, and later review.

Worked artifact: a synthetic missed-connection response

A fictional regional transport operator receives an AI-generated recommendation after a feeder service is delayed. The assistant proposes holding the final connecting departure for twelve minutes because it estimates that thirty-one passengers will otherwise miss the connection.

The exception packet shows that the estimate combines a live passenger count with yesterday's transfer manifest. Six passengers have already rebooked, the final departure has a crew-hours constraint, and the connecting platform closes five minutes before departure. The apparent twelve-minute option is not actually available.

The operator rebuilds the record:

| Packet field | Recorded evidence | | --- | --- | | Exception | Feeder service is 18 minutes late at 21:06 local time | | Evidence window | Live movement feed at 21:06; transfer manifest at 20:50; rebooking feed at 21:04 | | Constraints | Platform close, crew-hours limit, last onward service, accessible-transfer requirement | | Options | Depart on time; hold four minutes; arrange a road transfer for the remaining group | | Checks | Reconcile passenger identities, recalculate feasible arrival, confirm crew time with control | | Decision | Depart on time and arrange the bounded transfer, approved by duty control | | Follow-through | Notify affected passengers, monitor transfer completion, review manifest lag |

The packet does not simply replace the AI recommendation. It identifies why the estimate was wrong, tests the alternatives against current constraints, and records the authority for the chosen response. The example is synthetic and does not prescribe operating rules for a real transport provider.

Verify the chain before action

Check timestamps in the operating time zone and identify whether each source is live, delayed, forecast, or manually entered. Recalculate quantities from the underlying records when they affect capacity, timing, cost, or service commitments. Confirm that identifiers refer to the same trip, asset, route, customer group, and operating day.

Then run a counterfactual: what evidence would make another option preferable? If a four-minute delay would preserve the connection without breaching the crew limit, that fact matters. If the platform has already closed, the hold option is not a meaningful alternative. Record the deciding condition so a later reviewer can distinguish reasonable judgment from a lucky outcome.

Escalate when evidence conflicts, a required record is unavailable, authority is unclear, or the consequence falls outside the team's approved operating boundary. A confident response is not a substitute for dispatch, maintenance, safety, legal, or accessibility expertise.

Assess observable work without claiming sector assurance

A bounded simulation can present an exception, mixed-freshness records, a plausible AI recommendation, and a decision deadline. Observable evidence may include the participant's source reconciliation, constraint identification, option comparison, escalation, and final communication.

Report what the person did in that scenario and what evidence was available. Do not infer general transportation competence, regulatory compliance, safety performance, or future job performance from one exercise. Two Prune can structure evidence from a synthetic or approved non-sensitive assessment. It does not control live transportation operations, certify compliance, promise safer outcomes, or make employment decisions.