Before extracted fields become records, agree on what they mean

An extracted value is still a proposal

A maintenance coordinator opens a stack of equipment service reports. Each document has a date, a machine identifier, and some description of work. The coordinator wants records that can populate a maintenance system. That sounds like a small extraction job until one contractor uses “completed” for an inspection, another uses it for a repair, and a third leaves the completion box blank while describing replacement parts in the notes. A well-formed date and a true-or-false field can conceal three different meanings.

Dharma-AI introduced its Field Extractor on November 4. Its announcement describes a two-billion-parameter model that takes document images and returns JSON, either discovering fields or filling a supplied schema. The authors say schema-directed requests use the requested keys and return null for unavailable fields. They report results from their own benchmark, including requests for fields deliberately absent from documents. Those claims describe the developer’s evaluation, not testing conducted for this article. The release is a timely reason to inspect the agreement between an extraction tool and the record system receiving its output.

The maintenance workflow below is a hypothetical design exercise. Its central question is what a field means when software begins acting on it. Before a model’s output can close a work order, schedule another visit, or update an equipment history, a team needs definitions, evidence, and a review decision. These are useful requirements for any extractor. JSON is the container they can travel in, not proof that the decisions have already been made.

Source: Dharma-AI: Dharma Field Extractor: Any Document In, Structured Fields in JSON Out ↗ · JSON Schema: Object reference ↗ · W3C: An Overview of the PROV Family of Documents ↗

Define the field before choosing its type

Start with the person who uses the destination record. Ask what they need to decide from each field, then write a short definition. For this maintenance system, “service date” could mean the date the technician arrived, the date work finished, or the date the supplier issued the report. Choosing the type “date” resolves none of those differences. Define it as the date explicitly identified as the visit date, and record the issue date separately if it matters.

Define what counts as evidence as well. A report heading labeled “visit” is a different basis from a filename containing a date. If the filename is an approved fallback, state that rule and preserve its use in the record. Otherwise, leave the field unresolved. Avoid asking a model to choose whichever date looks most plausible. That instruction delegates a business rule without making it visible to the people who will rely on the result.

Machine identifiers deserve similar care. A printed identifier such as “00042” should usually remain a string if the zeroes are part of the identifier. A numeric field can discard their significance. For measurements, save the unit alongside the amount. A value of 12 has little operational meaning if the source could mean hours, months, or operating cycles. Store the original wording when normalization requires a choice that another person may need to revisit.

Give the definitions a version. A simple field dictionary can record the field name, meaning, allowed values, evidence rule, and destination. When a definition changes from visit date to completion date, that is a meaning change even if both fields still contain dates. Old records should not silently acquire the new interpretation. Plan the transition explicitly, including whether historical records need review, whether a new column is clearer, and which version applies to the next batch.

Give uncertainty more than one place to live

A single empty value cannot explain everything that went wrong. The service report might lack a completion-date field entirely. It might include that field but leave it blank. Its handwriting might be unreadable, or two pages might disagree. These cases may all prevent a usable date, but they call for different next steps. Asking the supplier for an omitted date is different from obtaining a clearer scan.

Use a small set of status labels that a reviewer can apply consistently. In the hypothetical workflow, “observed” means the source explicitly supplies the value. “Blank” means the field exists without a supplied value. “Not present” means no corresponding field or statement was found. “Unreadable” means relevant material is visible but cannot be reliably interpreted. “Conflicting” means competing values remain unresolved. Keep the raw value separate from that status, and make the application’s behavior for each status explicit.

This is an application design proposal, not a claim that Dharma’s model produces these distinctions. A tool that returns null may need a surrounding review process to establish why. Do not ask it to generate a detailed explanation and then treat that explanation as evidence without looking at the document. Explanations can be wrong for the same reason values can be wrong.

JSON Schema’s object reference distinguishes an absent property from a property holding null. It also explains that properties are optional unless made required, and additional properties are allowed unless constrained. Those are useful structural controls. They do not tell you whether “completed: false” means the contractor explicitly wrote “not completed” or merely left a box empty. For a field that could trigger follow-up, require an explicit source statement or a reviewer decision before converting uncertainty into false. A clean default can otherwise turn silence into a recorded event.

Carry evidence to the review screen

A reviewer should be able to reach the relevant source without reconstructing the extraction process. Give the uploaded document a stable identifier and version. Save the page number and, where the workflow supports it, the region containing the candidate value. A short transcription of the source label and value can help a reviewer orient themselves, but it should link back to the original page rather than replace it.

The W3C’s PROV overview describes provenance in terms of the entities, activities, and people involved in producing something. A small extraction system can borrow that organizing idea without implementing the whole family of standards. The report is an input entity; the extraction run and normalization are activities; the tool and the approving reviewer are participants. Recording those relationships helps answer a practical question later: how did this particular value enter this particular record?

Keep the model proposal separate from the accepted value. Suppose the report visibly says “03/04/26.” Save that original string. If a reviewer determines from the document’s explicit format instructions that it means April 3, record the normalized date, the reason, and the reviewer. Avoid replacing the original string everywhere with the interpretation. A later audit may uncover that the contractor changed its form format midway through the year.

Document identity also protects against a common operational ambiguity: a revised report arriving after an earlier version was accepted. The new extraction should reference the new document version and identify the existing record it proposes to change. Show reviewers the differences rather than silently overwriting values. A correction to the machine identifier may matter more than several added sentences in a work description. Preserving both versions lets the team examine that correction without treating the newest file as automatically authoritative.

Review the consequences, not just the boxes

Place incoming extraction results in a staging area. Structural validation can check whether the payload parses, whether required keys exist, and whether values have allowed types. Business checks can flag a completion date earlier than the visit date or an identifier that does not match the chosen machine. These checks are useful ways to find candidates for review. A payload that passes them may still describe the wrong machine or attach a note to the wrong service line.

Build the review screen around a decision. Show the candidate value, its source region, the proposed destination, and what accepting it will do. If acceptance would close a work order, say so beside the relevant control. A reviewer should not have to know that an innocent-looking checkbox updates a downstream status through another integration. Give unresolved records a useful destination: a queue with an owner, a reason, and a way to request better evidence.

Review table relationships as carefully as individual strings. Imagine a report containing three machines and a note that only one needs a replacement filter. Correctly reading “replacement required” is not enough if the value lands beside all three machines. Show each row with its identifying context. Preserve source order when it helps comparison, but do not rely on row position as the permanent identifier; an amended report may insert a new row at the top.

Keep extraction separate from authorization. A contractor’s note requesting another visit does not itself authorize spending or establish that an internal manager approved it. Likewise, text inside the source should not be able to tell the workflow to skip review. Treat the document as evidence to interpret under the field rules. The surrounding application should decide which actions are allowed and who can approve them. This separation makes it easier to investigate both accidental mistakes and attempts to manipulate an automated process.

Make rejection a first-class outcome, too. A reviewer might discover that a document belongs to another supplier, that its pages were combined with another report, or that the scan omits the signature page the workflow requires. Allow them to stop the proposed import and record that reason without manufacturing values to satisfy required fields. If they upload a replacement, connect it to the rejected candidate so another operator can understand why the earlier result never became a record. This is particularly helpful when a colleague returns to a queue after an interruption and needs to distinguish a deliberate hold from an abandoned task.

Measure the errors your destination cares about

Before accepting unattended updates, assemble examples that challenge the definitions. Include blank fields, absent fields, revisions, crossed-out values, repeated machine identifiers, and ambiguous dates. Have knowledgeable reviewers mark both the expected value and the evidence supporting it. Where they disagree, resolve the field rule before treating either answer as ground truth. A disputed definition makes a poor yardstick for a model.

Score the important distinctions separately. Track whether the extractor finds present values, whether it invents values where none are supported, and whether table values attach to the correct entities. Then inspect the consequences of those errors. A misspelled description and an incorrect machine identifier might count as one error each in a broad score while producing very different repair work. Define acceptance criteria by field and action rather than borrowing one overall result from a developer’s benchmark.

Also examine the review process itself. Record why candidates were changed, how often a reviewer needed a better source, and which field definitions caused repeated questions. Do not interpret quick approvals as evidence of correctness. Reviewers may be facing an interface that hides the relevant page, or a queue that encourages them to move on. Sample accepted records against the original documents and use the findings to improve the rules and interface.

Start with a reversible destination, such as a draft maintenance record, and make the first deployment small enough that people can inspect the whole path. Keep an explicit way to pause new imports while preserving the queue. Expand only when the team can explain representative failures and recover from them. The useful outcome is a record whose meaning survives beyond the extraction run: someone can see what the source said, what software proposed, what a person accepted, and what happened next.