AI document extraction
Evidence before approval

An insurance team considering a claim workflow might ask which document supports a reported date. A manufacturing team reviewing a maintenance record might ask whether a returned number retains its unit and context. These are buyer questions, not accounts of deployments. Both expose the same handoff: a field can be easy for software to consume while still being difficult for a person to justify. In its September 29, 2026 engineering article, Microsoft argues that extracting trustworthy, traceable content remains a separate engineering discipline even as models improve. It describes the work behind formats, layouts, relationships across pages, confidence, normalization and error handling. That publication is the recent development here, not an October feature launch or incident. Its broader performance claims are vendor statements, not results established by this analysis.

The useful distinction is between obtaining a value and accepting its use. Microsoft's Content Understanding overview describes three field methods: extract takes values as they appear in document input; classify assigns predefined categories; generate produces values from input, such as summaries. A schema-shaped response does not erase those differences. Reviewers should know whether they are comparing source text, a category assignment or a generated interpretation. Version scope matters too. The overview recommends API 2025-11-01, labelled GA, for production workloads. API 2026-06-01-preview is for evaluating preview capabilities. The release notes say previews have no service-level agreement and are not recommended for production workloads. Neither label establishes that every capability is available for every input or configuration.

The July 2026 release notes describe confidence and source grounding for all document field types, including generate and classify, under both preview and GA. They identify the estimateFieldSourceAndConfidence and estimateSourceAndConfidence settings for enabling this behavior. That is a document-field statement, not a promise of identical signals across every modality. The overview describes confidence as a reliability estimate from 0 to 1 and grounding as locating supporting source regions. Neither is an independently measured accuracy rate for your documents or a demonstrated business approval threshold. Normalization creates another review boundary. The same July notes say supported typed values, such as dates and numbers, are automatically converted to canonical form. Normalization is not configurable, and the response does not provide separate raw and normalized values. A review record should therefore retain access to the source and distinguish the returned representation from its original wording. Do not promise reviewers a raw-value field that the documented response does not supply. If the wording remains ambiguous, a tidy format should not settle its meaning.

A successful request is not necessarily a complete field set. The overview explains that guardrails can restrict field generation while preserving extracted source content. Analysis can succeed with warnings even when some field values are absent; blocking can also limit extraction or prevent completion. Its instruction to review warnings before automated use is materially different from treating a success status as approval. A proposed handoff should carry the document and source locator, field method, returned value, relevant configuration and version, available confidence and grounding, and any missing information or warnings. The receiving team should be able to distinguish a field that was not returned from one that was reviewed and accepted. An integration owner should preserve those distinctions; a business owner should decide what they mean for the intended task. The diagram shows that proposed review sequence, not provider-enforced controls or observed outcomes.

For an insurance evaluation, ask what happens when a claim form and supporting attachment disagree about a date: which source is compared, who resolves the conflict, and does the next workflow wait? For manufacturing, ask how a reviewer checks a number against its table heading, unit and document revision before it reaches a maintenance task. These questions define evaluation work; they do not imply either sector has achieved a particular result. Agree acceptance conditions before evaluating representative documents. Include unclear source wording, missing values, generated interpretations and warning-bearing responses, not just clean extractions. Record whether the reviewer accepts a value for a named use, requests clarification or holds the handoff. If the source cannot support the intended interpretation, preserve that gap rather than converting it into a plausible answer. The useful deliverable is not merely populated JSON. It is a value whose origin and transformation can be inspected, whose exceptions remain visible, and whose permitted use has a responsible owner. That is the acceptance boundary a buyer can examine without mistaking structured output for permission to act.