Bringing AI Parsing into a Business Workflow: OCR, Structured Fields, and Human Confirmation

When building AI business features, the first gap I noticed was the distance between “parsing succeeded” in a demo and “I can continue working” in a workspace.

Upload a file, receive plausible JSON from a model, and the demo can move on. But someone handling an actual inquiry still needs answers: Which page supplied the board thickness? Why was the quantity missing? Which value should be used when two attachments disagree? If answering these questions requires reopening every file, structured extraction has simply moved the checking work elsewhere.

While developing parts of the AIQS parsing workspace, I gradually shifted my attention from “Can we extract this field?” to “How can the result be checked, edited, and accepted?” This article uses synthetic PCB inquiry documents to explain that path. It contains no real customer files and makes no claims about unmeasured recognition accuracy.

Four stages for one set of documents

Suppose an inquiry includes scanned instructions, a specification sheet, and a follow-up email. The scan states a board thickness of 1.6 mm, the specification revises it to 1.2 mm, and no purchase quantity is provided. Returning thickness: 1.6 directly would hide an unresolved conflict inside a neat number.

I separate the process into four layers:

Layer	Main responsibility	Decisions it cannot make for the next layer
Document parsing / OCR	Obtain usable text, tables, page numbers, and other information	Which business value should ultimately take effect
Model extraction	Organize candidate values and supporting evidence according to field definitions	Whether missing information may be filled in without confirmation
Field mapping	Connect parsed fields to business fields and perform deterministic conversions	Whether to overwrite data confirmed by a user
Human confirmation	Check sources, resolve conflicts, and complete required fields	Leave the item pending when it cannot be confirmed

A working OCR service proves only that document recognition is available. Model extraction can still fail because of configuration, quota, or response format. Conversely, a successful model call does not mean every cell in a scanned table was read correctly. These stages need separate diagnostic records, and the interface should retain the corresponding failure location.

Represent candidates before conclusions

A simple key-value object works for submitting results, but cannot carry the entire confirmation process. This TypeScript example explains the design; it is not a complete definition of an existing API:

type Candidate<T> = {
  value: T | null;
  unit?: string;
  source?: { fileId: string; page: number; excerpt: string };
  state: 'suggested' | 'missing' | 'conflict' | 'confirmed';
};

const thickness: Candidate<number> = {
  value: 1.2,
  unit: 'mm',
  source: { fileId: 'demo-spec-v2', page: 1, excerpt: 'Board thickness: 1.2 mm' },
  state: 'conflict',
};

conflict matters here. It lets the system recommend a value while acknowledging another source that still needs attention. A recommendation policy might use document versions, explicit revision markers, or a user-defined source priority. Without such evidence, the system should present the candidates rather than ask the model to guess on the business user’s behalf.

A missing quantity should remain null, rather than receiving a typical quantity just to complete the form. 0, an empty string, and a missing value are not interchangeable either. Whether zero is allowed depends on the field’s rules; one truthiness check cannot handle every field.

Source information should ideally come from page numbers, regions, or text excerpts that the parsing pipeline can locate. A page number produced by a model needs validation too; valid JSON alone does not make it reliable evidence.

Keep the checking path short

I prefer document previews and field editing in the same workspace. Clicking a field’s source takes the preview to the relevant file and page, while the original candidate remains available after the user edits the field. That way, “Why do I trust this value?” no longer depends on memory.

Status feedback also needs to be specific. Instead of one spinner for all attachments, show separate states such as “Recognizing document,” “Extracting fields,” and “Some results need confirmation.” If the second attachment fails, results already obtained from the first can remain, but the user must be able to see that this run is incomplete.

On mobile, there is no need to squeeze two columns side by side. Users can switch between preview and fields; what matters is preserving the connection between the current field and its source, and keeping the editing position when they return. For keyboard users, source buttons, error messages, and confirmation buttons also need a clear operating order.

Make confirmation an explicit data submission

A risky approach is to update the official record whenever the model returns a field. A later retry, upload, or parsing run could overwrite edits the user has just made.

A more understandable flow is:

File snapshot → Parsing task → Candidate fields
                                     ↓
                            User checks and completes
                                     ↓
                         Confirmation → Business record

Here, the parsing task owns its results, and the official record owns its current values. Confirmation should validate required fields, units, allowed ranges, and the file version associated with the task. Systems with multiple editors should also consider record version checks so that confirmation based on an old form cannot overwrite newer edits. This is an additional design requirement; disabling a frontend button alone cannot implement it.

Parsing again should produce new candidate results. To update an existing record, show the differences first and let the user decide which fields to change. This differs from “apply a mapping configuration once when creating a record,” whose boundaries are discussed further in the article on dynamic business fields.

Validate the whole business path

Synthetic documents can provide test scenarios with known answers: different thickness units, conflicting files, a missing quantity, attachment recognition failure, and another parsing run after user confirmation. Check both extraction results and whether sources can be located, errors can be recovered from, and manual edits are preserved.

Reporting accuracy requires a field-level definition, sample scope, rules for scoring missing and conflicting values, and separate counts of manual corrections. A few correct fields in one demonstration do not establish that the entire workflow is reliable.

This retrospective focuses on data and interaction boundaries. A complete model for candidates, evidence navigation, and version validation still needs to be implemented in the context of the actual system; these examples do not mean all those capabilities already exist. To me, a useful AI workspace should offer the speed of machines while making it clear when users need to take over.