EDI exception triage in a freight operations team
This is a methodology scenario, not a client engagement. Chokmah has not delivered this engagement for a named client. The workflow, constraints and sequence describe how we would run it. Any figures shown are illustrative targets, not measured results.
EDI exception triage is the manual work of resolving EDIFACT messages that fail validation before they reach a booking system. It is a strong first agentic workflow because the queue is bounded, already logged and already measured. This page describes how Chokmah would run that engagement.
- The exception queue is the automatable workflow. The happy path is already automated.
- Failure modes, not trading partners, are the right classification axis in week one.
- Baseline time to resolution before the build starts, or the result is unprovable.
- The first release proposes corrections for human acceptance. It does not submit them.
- Segments carrying commercial terms stay under human sign-off permanently.
The situation
Freight and logistics GCCs run inbound EDI for a book of trading partners. Bookings, shipping instructions and status messages arrive as EDIFACT (IFTMBF, IFTMIN, IFTSTA), and are mapped into an operations or booking platform.
The happy path is usually already automated. The exception queue is not. Messages fail schema validation, carry a partner-specific code the mapping does not know, reference a container or party record that does not exist yet, or arrive out of sequence. Those messages fall out of the pipe and land with a small operations team.
Each one is opened by hand, read segment by segment, corrected in a staging tool and resubmitted. The queue is worked in arrival order rather than commercial urgency, because nobody has the time to triage it. Volume rises with partner count, not with revenue, so every new trading partner makes the problem slightly worse.
This is a composite. It is assembled from the shape this workflow takes across freight and logistics operations generally. Chokmah's EDI and EDIFACT experience is real production experience; this particular engagement is illustrative.
Constraints
- EDIFACT messages are legally significant trading-partner documents. A wrong correction is not a bad answer. It is a wrong booking.
- Partner-specific mapping variations are undocumented. The knowledge sits with two or three operations staff and in years of ticket history.
- The operations platform accepts corrections through a staging tool with no public API. Any agent must act through the same interface a person uses.
- Exception volume is seasonal and partner-driven. One month of data can misrepresent the queue badly.
- Audit requires a reconstructable trail: what changed which segment, when, and on whose authority.
How we would run it
- 1Week 1
Pull twelve months of exception history and classify by failure mode
Export the exception queue with the raw message, the correction applied and the time to resolution. Classify by failure mode rather than by partner. Most queues collapse into six or seven recurring shapes: an unknown partner code, a missing master-data reference, a segment order violation, a date-format variance, a duplicate submission, a genuinely malformed message. The distribution decides the whole engagement. If one shape dominates the volume, that shape is the build and everything else waits.
- 2Week 1
Shadow two operations staff for a full working day each
Sit with the people who work the queue and record what they actually do, not what the runbook says. The useful output is the judgement: which corrections they make without hesitating, which ones they escalate, and which ones they refuse to touch. That boundary is the specification for the human-in-the-loop design, and it cannot be derived from the data alone.
- 3Week 2
Baseline the workflow before anything is built
Fix the measurement before the build starts, because a number produced afterwards cannot be trusted. Baseline median and worst-case time to resolution per failure mode, rework rate, escalation rate, and how many exceptions age past their commercial deadline. Agree the definition of each metric with the operations lead in writing. If a baseline cannot be produced at all, that finding is more valuable than the build and we would say so.
- 4Weeks 3-4
Build a classifier and a proposal step, not an auto-corrector
The first working version reads the failed message, identifies the failure mode, retrieves the relevant partner mapping and prior resolutions, and proposes a correction with the segment and element named. It does not submit. An operations person accepts, edits or rejects. Acceptance rate on the proposal is the honest quality signal and it is available from the first day of use, long before any throughput claim can be made.
- 5Weeks 4-5
Stand up an evaluation harness on frozen historical cases
Take a fixed set of historical exceptions with known-good corrections and turn them into a versioned test set. Every prompt change, model change and mapping change runs against it before release. Score segment-level correctness, not overall similarity: a correction that is right about the container number and wrong about the party code is a failure, not a partial pass. The harness is a deliverable in its own right.
- 6Week 6
Hand over the repository, the harness and the runbook
The people who built it alongside us keep it. That means the repository, the evaluation cases, the deployment steps and a written description of the failure modes the system does not handle. An artefact nobody inside the team can change six months later is a liability, not a deliverable, and we would rather ship something smaller that survives.
What we would not automate
Unattended correction of any segment carrying commercial terms
Rate, quantity, party and date segments carry contractual weight. An automatic edit to one of them alters a legally significant document exchanged with a trading partner. The proposal step stays; unattended submission does not. This is not a maturity milestone that unlocks in phase two. It is a permanent boundary, and we would write it into the handover document as one.
Structurally malformed messages from a single trading partner
When one partner produces repeated structural failures, the correct fix is a conversation with that partner, not a model that learns to paper over it. Automating the workaround removes the pressure that would have fixed the source, and quietly makes your side responsible for someone else's data quality.
Exception triage during peak season, in a first release
Peak weeks are when the queue is longest and a wrong correction is most expensive. Introducing a new step into the highest-load, lowest-tolerance period of the year is how pilots get cancelled. A first release runs outside peak, with a rollback that is one configuration change and no data migration.
Illustrative targets
These are targets used to frame the engagement, not measured results from a delivered client project.
Illustrative target: Coverage of the exception queue at first release: The top two failure modes only
Exception queues of this shape concentrate. Scoping the first release to the two most common failure modes found in week one keeps the build inside four weeks and keeps the evaluation set small enough to be genuinely reviewed. The specific modes are set from your history, not from an assumption we bring.
Illustrative target: Time to resolution on the covered failure modes: Movement vs a written baseline
The commitment is to a baseline agreed before the build and remeasured after, using the same metric definition. We do not offer a target percentage before seeing your queue, because the achievable movement depends on how much of the current handling time is judgement rather than lookup.
Illustrative target: Proposal acceptance rate from operations staff: Tracked from day one
Acceptance rate is observable immediately and cannot be gamed by volume. It is the metric we would hold ourselves to during the build, because it measures whether the output is usable rather than whether the system ran.
Frequently asked questions
Not the whole of it, and that is the wrong target. The happy path in a mature freight operation is already automated by the mapping layer. What remains manual is the exception queue, and that is where an agentic system earns its keep: classifying the failure, retrieving the partner-specific rule and prior resolutions, and proposing a segment-level correction for a person to accept. Unattended correction of commercially binding segments is not something we would build.
Because exceptions are already logged, already timed and already owned by a named team, which means a baseline exists before you start. A workflow you cannot baseline is a workflow you cannot prove anything about later. The exception queue also has a natural human checkpoint already in it, so adding a proposal step changes the work without changing the control model.
This shape of work is a Workflow Sprint: four to six weeks, one named workflow, built jointly with three to five of your own people, who keep the code. Weeks one and two are classification, shadowing and baselining. Weeks three to five are the build and the evaluation harness. Week six is handover. If the classification in week one shows the queue is not concentrated enough to build against, we would say so and stop.
Three things, permanently. Unattended correction of any segment carrying commercial terms: rate, quantity, party, date. Structurally malformed messages from one partner, because the fix there is a conversation with that partner rather than a model that hides the problem. And a first release running during peak season, when a wrong correction costs the most.
No. Chokmah has not delivered this engagement for a named client, and this page is a methodology scenario rather than a case study. The EDI and EDIFACT experience behind it is real production experience (message parsing, partner-specific mappings, exception handling), but the engagement described here is illustrative and every figure on the page is a target, not a measured result.
Have a workflow like this?
We name the workflow before we start. Book a free AI Reality Check and build one live.