The Date That Looks Cleaner May Be Less Certain
An archive digitizes old workshop permits that contain handwritten dates, local abbreviations and occasional missing years. A processor might extract text such as 03/04/21 and also provide a normalized date field. That structured value is convenient for sorting and validation, but a cataloger cannot assume the day and month order without checking the source context. A software-friendly date is not proof that the historical interpretation is right.
Google Document AI documents normalized values for specific supported fields, alongside the literal extracted text. This guide uses a deliberately ambiguous invented permit to explain the review path. No actual document has been uploaded or processed, and the diagrams are not examples of real Google Cloud output. The objective is to preserve uncertainty while making verified records usable.
Separate Raw Mention Text From normalizedValue
Document AI uses entities, text anchors and field-level information to represent extraction results. For supported normalized fields, the result can include entity.normalizedValue in addition to the raw mentionText or text referenced through the original document’s text anchor. Google states that mentionText, representing what literally appears in the document, is not changed by normalization. That separation is essential for audit.
Retain both forms, plus the source file identifier, page, entity type, extraction revision and any human decision. A catalog that stores only the normalized value discards evidence for how the machine interpreted a shortened date or currency symbol. A reviewer should be able to click the standardized field and see the source string and the physical region on the scan.
Check Whether the Processor Supports the Field
Not every processor or field returns normalizedValue. Google documents supported categories such as money, date, timestamp, address, boolean, integer and float; availability depends on processor and field. Do not assume that any extracted name, ancient-language label or local archival abbreviation will be normalized. Inspect the actual response schema and the capability documentation for the configured processor version.
Plan for an optional normalized value in your ingest pipeline. A missing field should remain absent or under review, not be filled with a fabricated default. Treat normalization and entity enrichment as distinct operations where relevant. If the processor changes versions, evaluate whether field shapes, types or output consistency change before moving the new values into the searchable public catalog.
Audit Ambiguous Dates Instead of Guessing
The invented permit shows 03/04/21, without a written month name. Depending on local convention, that could mean March 4 or April 3; the century may also be unclear. An automatically normalized form might choose one representation, but source provenance, jurisdiction, other entries on the page and collection knowledge are needed to validate it. Preserve the raw text and note the uncertainty explicitly.
For public search, a curator could decide to retain the original date string and a reviewed range or explanatory qualifier rather than an unsupported exact day. If a calendar field requires ISO format, populate it only when the source interpretation meets institutional rules. This reduces the risk of downstream sorting silently turning a guess into an accepted chronology.
Compare Three Dates With Different Evidence States
The first illustration shows a calendar-friendly value with no link to the source. The second displays the literal permit field alongside the machine’s normalized representation and an unresolved ambiguity marker. The third records the original text, authorized decision and evidence that resolves or preserves the ambiguity. These are schematic examples; their values were invented for teaching, not copied from an OCR response.
A similar issue applies to money and addresses. A normalized currency amount may be structured but still misread a handwritten symbol. A standardized address might lose historical spelling or a name that no longer exists. Do not overwrite culturally meaningful original notation just because a modern schema can store a cleaner value. Provide distinct raw, machine-proposed and human-reviewed fields.
Design Human Review Around the Risky Fields
Route ambiguous date formats, unusual currency marks, cross-border documents, poor scans and conflicting nearby fields to specialist reviewers. Show the crop of the source, any extraction confidence that is actually returned, nearby context and a side-by-side representation. A reviewer may accept, correct or mark a field unresolved; record which option was chosen and why. The model’s structured output is not a legal decision about permit validity.
Use synthetic records when testing the pipeline and keep actual sensitive permits under the organization’s privacy and retention policies. An OCR service may process names, signatures or restricted location data. Limit who can access full scans or diagnostics, and do not leak private text into routine application logs. Keep the original master scan immutable so changes to the catalog can be independently checked.
Version the Pipeline and Recheck Changes
Persist processor identifier, version and field mapping with the extraction result. Before upgrading a processor, rerun a controlled sample of invented or permission-cleared pages and compare raw mentionText, normalizedValue, missing fields and required review decisions. Changes that improve format consistency may still alter an important ambiguous field. A passing schema test alone cannot verify historical accuracy.
When staff correct a normalized value, store a correction event rather than silently replacing the machine field. Downstream reporting should use the reviewed field only after approval. If the result is genuinely uncertain, display a qualification instead of a confident timestamp. That is especially important when collection records are used to support an exhibition chronology or a rights inquiry.
Publish a Verified Meaning, Not Just a Parsed String
The release checklist asks whether the source string is preserved, the normalized field is supported by the processor, ambiguity has been evaluated, provenance is intact, and staff have approved the displayed date or amount. Public records should distinguish original transcription, standardized representation and editorial interpretation. If a field could not be resolved, say so visibly rather than fabricating a plausible completion.
Google Document AI normalizedValue can reduce repetitive formatting work. It does not eliminate the need to interpret old paperwork. The strongest workflow uses its structured convenience while leaving every important historical claim tied to the source page and the qualified person who reviewed it.
How We Research
We consulted the following official developer documentation on November 8, 2026: Google Cloud Document AI: Normalization; Google Cloud Document AI: Enrichment; Google Cloud Document AI: Document schema. We compared the documented parameters, data flow and stated limitations with this hypothetical editorial scenario. The diagrams are original instructional illustrations, not real vendor screenshots or outputs. We did not submit private archive material, run a production API evaluation, measure tool accuracy, obtain legal consent, or test a live service configuration. Product behavior, access rules, quotas and supported settings may change; confirm the latest documentation and your organization’s policies before deployment.
Frequently Asked Questions
No. Google documents that normalization does not change the raw mentionText.
No. Support depends on the processor and specific field type; verify your configured processor.
Not on its own. The source and historical context require human examination.
Keep the field missing or under review rather than inventing a date, amount or address.
No. They are invented instructional scenarios and original diagrams.