From extracted fields to work queues: define the next action

On October 27, 2026, Red Hat described an Atos experiment in structured extraction with small models. This vendor case motivates our analysis of data handoffs, not a model ranking. Original case

A neatly completed table can suggest that every cell has undergone the same judgment. Yet a blank may mean the source said nothing, the system failed to read something, competing statements could not be reconciled, or the question did not apply. Each calls for a different response. If an interface delivers only an empty cell, the receiving system must guess. That guess often disappears into defaults, retry rules and reporting definitions.

How a blank becomes a business decision

Consider a hypothetical after-sales workflow, not a description of the Atos implementation. A customer writes: “The replacement arrived last week, but the original problem remains.” An extractor must supply an order date, product model and resolution status. The text gives no order date; the model might appear in an attachment; “remains” must be connected to the relevant problem. If all three fields are empty, the system cannot distinguish a request for purchase evidence from an attachment-reading task, or determine whether the original fault still needs attention.

The official JSON Schema documentation distinguishes null from an absent property. That technical distinction does not name the business states. A team must still decide whether an absent property means an older interface does not offer it or that processing did not run. Does an explicit null mean uncertain, or confirmed absence? Leaving these questions until integration allows different consumers to invent different answers.

One option is to retain a value and a processing status for important fields. Statuses might distinguish information not supplied, conflicting statements, pending processing and a supported result. Every field does not need a large enumeration. The useful distinctions are those that change the next action. A low-risk label may tolerate a simple blank; a field governing a refund, eligibility or account action deserves a more precise handoff. These are proposed design choices, not a universal industry standard.

Keep the material that explains the gap

A status label can itself be wrong. Important fields should therefore be traceable to the relevant input version and source location. Saving a supporting passage does not prove the judgment correct. It gives a reviewer a chance to see that the passage answers a different question or omits a qualification. A claim that information was not supplied also needs a processing boundary: absence from the main text says nothing about an unread attachment.

In the hypothetical ticket, the order date could be marked as not supplied in the text, the model as awaiting attachment processing, and the fault status linked to the customer's statement. The work queue can then separate a request for more material, an unfinished reading operation and a judgment about continuing support. There is no need to make a model invent a date to finish a table. Retaining an unknown hands the next task to the appropriate part of the process rather than declaring the whole process a failure.

The same contract should constrain normalization. Turning “last week” into a date range requires a reference date and time zone. Mapping a nickname to a customer's name requires evidence connecting identities. If only the normalized value survives, a reviewer cannot easily distinguish the source statement from the system's transformation. For consequential fields, preserving the relationship among the original expression, transformation-rule version and result is more useful than retaining an apparently standardized string alone.

Count review work alongside automation gains

More detailed statuses carry costs. They add storage, interface and training work, and can expand human queues. Teams must decide which unknowns warrant blocking an action, which can be held for later and which do not affect the present task. A missing model number may not prevent registering a complaint, but may prevent shipping a replacement part. The same field can require different release conditions before different actions. One extraction result should not become a permanent authorization.

Measuring only field completion encourages uncertain content to be filled in. Measuring only human escalation can punish appropriate caution. A more informative approach links eventual outcomes to the status recorded at the time: which supported results were later corrected, which supposedly absent details were actually reading omissions, and which reviews produced no new usable information. These records help improve a specific stage rather than assigning every failure to model capability.

There is also a reasonable argument for simple interfaces while an early product tests demand. In low-consequence, reversible tasks where a person examines every result, this avoids premature design. The difficulty is that interfaces acquire new uses without a formal announcement. A field intended as a suggestion is reused in a report, then consumed by an automatic rule. If that change of use does not trigger a review of its meaning, ambiguity that was once tolerable spreads.

Adding a status or changing the meaning of a blank therefore deserves downstream notification, much like changing a field's type. Teams can retain example inputs and expected handoffs to check whether an upgraded consumer still reads “unknown” as “no.” Historical data should not silently receive a new definition either. An apparent improvement in missingness may otherwise reflect a changed definition rather than better business information.

Structured extraction helps text enter a collaborative workflow. That workflow needs to know when action is justified and when another piece of information is still required. A model can perform extraction. The organization using it must define the field meanings, permitted defaults and responsibility for carrying unresolved questions forward.