Keeping document extraction with missing fields under control

Start with the output contract, not the prompt

The first decision is to define exactly what the system needs to return. A request such as “extract the supplier data” leaves ambiguities about names, formats, required fields, and how missing information should be handled. The contract should be written before choosing the model, because it turns an open-ended task into a verifiable operation.

For a hypothetical supplier record, the contract might require the legal name, trade name, CNPJ, address, city, state, email, telephone, banking details, and supply category. Each field needs a type, expected format, required status, and absence rule. For example, a CNPJ should be a normalized string, while an expiration date should follow a format defined by the company.

It is also useful to separate the extracted value, field status, and evidence. A conceptual object could contain value, present, operational_confidence, and source_excerpt. Confidence should not be treated as automatic truth. It helps prioritize validations, while the source excerpt makes it possible to investigate why a value was filled in or left empty.

• Define required, optional, and prohibited fields for each document type.
• Choose canonical formats for dates, numbers, identifiers, and telephone numbers.
• Use null values or an explicit status for absence instead of invented text.
• Record the page or excerpt supporting each value whenever possible.

Model absence as a valid result

A missing field is not the same as an unreadable field, a contradictory field, or a field that does not apply. This distinction changes the operational flow. If the contract accepts only a value or null, the team loses important information. A more useful structure uses states such as found, absent, unreadable, conflicting, and not applicable, accompanied by a short note.

Consider a supplier that submits articles of incorporation without banking details. The system should return banking_details with an absent status, rather than trying to complete the information from patterns or from another supplier. If two CNPJs appear on different pages, the status should be conflicting, with the candidate values preserved for a later decision. This rule reduces the risk of turning an incomplete document into an apparently complete record.

The output should also distinguish “not located” from “not provided.” The first describes a location or reading failure. The second indicates that the document was examined but does not contain the field. This difference helps determine whether to improve OCR, request an additional page, or ask for a complementary document. The recommended behavior here is an architecture decision, not a guarantee offered by the model.

• Create a status enumeration before writing instructions for the model.
• Do not allow the system to fill gaps with inferences unless an explicit rule permits it.
• Keep multiple candidates when the document contains conflicting values.
• Define which statuses block the record and which only create a pending issue.

Sources and references: [2]

Validate the record in independent layers

Validation should happen after extraction and should not depend only on generated text. First, validate the schema: types, permitted fields, null values, and enumerations. Then apply domain rules, such as digit counts, the CNPJ mask, state abbreviation, email format, and consistency between municipality and state. Finally, compare the result with authorized internal data when that comparison is part of the process.

In the hypothetical example, a CNPJ with extra characters can be normalized without changing its digits, but a CNPJ with the wrong number of digits should receive a validation error. A telephone number without an area code may be accepted as incomplete if that is a business rule. A bank account extracted from a blurry image, however, should be marked unreadable, not corrected by approximation.

These layers should produce understandable reasons for each pending issue. “Invalid field” is less useful than “CNPJ has the wrong number of digits” or “state is not on the permitted list.” Specific messages make it easier to correct the input document and measure which fields create the most problems. The application can then route only exceptions instead of treating every extraction as a manual case.

• Perform structural validation before applying any business rule.
• Keep normalization separate from correction so the original value is preserved.
• Associate each failure with a code and an actionable message.
• Block writes when an essential field is missing or a critical conflict exists.

Test real, incomplete, and adversarial cases

A demonstration with clean documents does not test the main risk. Build an evaluation collection with complete contracts, missing pages, tilted photographs, tables, stamps, abbreviations, documents in varied formats, and deliberately conflicting fields. For each file, write the expected output and the approval conditions. The collection should represent the distribution the process actually receives, not only the easiest examples.

Evaluate each field separately and the complete record as well. Metrics such as correct presence, exact value, valid format, absence status, and conflict detection reveal different failures. An output may correctly identify the legal name and still be unsuitable because it invented banking details. In structured tasks, tests for classification, comparison, and approval or rejection are often more useful than a subjective evaluation of the entire text.

Evaluation must continue after deployment, because changes to the prompt, parser, OCR, or model can alter behavior. Record inputs, outputs, validations, and pending reasons according to the company’s governance rules. Evaluation guidance recommends task-specific tests, edge cases, systematic logging, and continuous monitoring instead of relying on the impression that the system appears to work.

• Separate development, validation, and test sets to avoid weak conclusions.
• Include documents without required fields and documents with contradictory values.
• Measure false fills, not only correctly extracted fields.
• Repeat the evaluation after every significant pipeline change.
• Use failure examples to improve the contract and rules, not only the prompt.

Sources and references: [1]

Choose an operational flow that preserves context

Extraction does not need to end with an approved record. A safer flow stores the structured result, the origin of each field, validation errors, and the record state. When a required field is absent, the system can create a pending issue with a specific request, such as “send the page containing the banking details.” When there is a conflict, it should request clarification about the value rather than silently choosing a candidate.

Documents may contain textual instructions that are not part of the data, including content created to influence the system’s behavior. For that reason, extracted text should be treated as untrusted data, not as an execution instruction. Structured outputs with fixed field names, closed lists, and size limits help prevent document content from escaping into later steps such as queries, notifications, or record changes.

As a hypothetical example, a company could begin with only the legal name, CNPJ, address, and email, leaving banking details out of the first version. The flow would have three outcomes: record ready, information pending, and conflict requiring analysis. This narrower scope makes the contract easier to test and allows fields to be added only when clear rules exist for extraction, validation, absence, and updating.

• Define process states beyond approved and rejected.
• Isolate document text from instructions intended for the system.
• Limit which fields can feed integrations or automatic changes.
• Maintain enough technical traceability to reproduce the pipeline’s decision.

Sources and references: [2][1]