Practical AI implementation guide · By Daks J
A supplier sends a product specification PDF. Someone opens it, finds the product code, copies the dimensions, checks the pack quantity, and enters everything into a product-data system. The next supplier uses a different layout, so the process starts again.
AI document intake can help prepare those records. A useful pilot must also show where each value came from, catch predictable errors, and recover cleanly when a file or integration fails.
Start with one low-sensitivity workflow: approved supplier specification PDFs for ordinary storage containers, producing draft catalog records in a staging system. Keep pricing, payment details, personal information, and safety-critical specifications outside this first trial. Every record receives human review before acceptance.
The objective is specific: can the team prepare correct, traceable product records with less manual handling?
1. Set a small, testable intake boundary
Choose one product family and a handful of supplier layouts. Define accepted languages, file types, page limits, and the fields the catalog actually needs. Reject unrelated documents before extraction.
A practical path is:
Approved upload folder → intake queue → text/layout extraction → field extraction → validation → review screen → staging database.
Keep the original PDF unchanged. Give it a document ID and a cryptographic content hash. The hash identifies byte-for-byte duplicates; a revised PDF with the same filename is a different input.
At intake, record the supplier selected through the approved upload process, filename, received time, and processing status. Check file type, size, readability, and malware status before passing a document to extraction. Never let text inside a PDF choose destinations or trigger external actions.
2. Define the record before choosing the model
The schema should describe a catalog record precisely enough for software to validate it. For this pilot, use eight extracted fields:
| Field | Expected representation | Important rule |
|---|---|---|
| Supplier SKU | String | Preserve leading zeros and meaningful punctuation |
| Product name | String | Use the source name without marketing embellishment |
| Revision label | String or null | Preserve the stated label; do not invent a revision |
| Length | Decimal or null | Must refer to the selected product variant |
| Width | Decimal or null | Keep distinct from length and height |
| Height | Decimal or null | Flag missing or conflicting dimensions |
| Dimension unit | Controlled value or null | Preserve original unit alongside any conversion |
| Units per pack | Positive integer or null | Distinguish individual units from cases |
Attach system metadata separately: supplier ID, document ID, schema version, extraction configuration, review status, and destination record ID.
For each extracted field, store the raw text, normalized value, evidence reference, and a status such as present, missing, ambiguous, or conflicting. A blank value should remain explainable. If a PDF lists several product variants, create separate candidates only when their rows can be associated reliably; otherwise request review.
3. Make evidence part of the output
OCR and layout extraction provide the material for field extraction. Microsoft's Document Intelligence layout model, for example, returns text, tables, and structural information. Those capabilities can support this design without requiring a custom model for every supplier. Microsoft layout documentation
Store a document reference, PDF page number, source excerpt, and available text span or bounding region with each field. Microsoft's response documentation describes spans as positions within extracted content and bounding regions as page-specific visual locations. Microsoft response documentation
Let the extraction model select evidence IDs from the parser output. Application code should resolve those IDs to actual pages and coordinates. Validate that the cited text exists; do not accept a model-generated page number as proof.
For an illustrative width of 450 mm, a reviewer should open the correct page and see the matching product row. Evidence that points to a neighboring variant is still an extraction error. Keep the original unit and conversion calculation visible when the destination uses another unit.
4. Apply deterministic checks after extraction
Request a structured object, then validate it independently. Correct JSON formatting cannot establish whether a value describes the right product.
Useful checks include:
- Required fields are present or explicitly marked missing.
- SKU values match the supplier's permitted format without destructive normalization.
- Dimensions are positive, use allowed units, and fall within agreed product-family limits.
- Pack quantities are integers, with conflicting case and unit descriptions flagged.
- Evidence references resolve to the retained document and expected variant.
- Repeated specifications agree, or the disagreement enters review.
Use explicit conversion rules with documented precision. A supplied 450 mm width may become 45 cm; a unitless 450 remains unresolved.
Treat validation success as eligibility for review. During the pilot, even records that pass every rule need checking. Otherwise the trial cannot reveal plausible but incorrect values that slipped through.
5. Give reviewers a focused exception screen
Show the candidate record beside its source page, with problematic fields highlighted. Display the reason for each exception: missing unit, ambiguous SKU, conflicting revision, or unrecognized supplier layout.
Provide approve, correct, and reject actions. Record the original extraction, final value, reviewer, timestamp, and correction reason. Preserve that history rather than overwriting the evidence of an error.
Track correction categories. If most changes concern dimensions taken from packaging diagrams, adjust the extraction instructions or layout handling and retest. Hexagon's workflow automation services cover the wider process around these review steps and connected applications.
6. Make integration replay-safe
Separate document identity from product identity. A content hash detects an identical file; a supplier ID plus supplier SKU identifies a catalog product. Neither establishes which specification revision should prevail.
Keep extraction attempts immutable. Approval should reference the exact candidate version the reviewer checked. If another attempt changes it, require review again. Route conflicting or uncertain revision order to an exception instead of allowing the last-arriving message to win.
For a database-backed staging system, use a unique business key and a conditional upsert. PostgreSQL supports conflict handling through INSERT ... ON CONFLICT, including atomic insert-or-update behavior. That database capability still needs explicit application rules for revision ordering and approved fields. PostgreSQL INSERT documentation
Write the accepted staging record and its processing receipt in one transaction where possible. A repeated request should return the existing outcome, leaving one intended record. If the destination is an external API, verify its idempotency support and read back the saved result before marking delivery complete. These requirements belong in the API integration design.
7. Recover failed work without losing its history
A queue lets extraction and staging proceed independently. Design consumers for repeated delivery: Amazon SQS standard queues, for example, can deliver a message more than once and explicitly require idempotent processing. Amazon SQS delivery documentation
Retry temporary timeouts or rate limits with bounded backoff and jitter, honoring provider retry guidance. A corrupt PDF, unsupported format, or missing required field needs correction or review. Repeatedly calling the model will not reliably resolve those conditions.
Keep document ID, stage, attempt count, error category, and next action visible. Isolate exhausted technical failures in a dead-letter queue; AWS documents this pattern for diagnosis and subsequent redrive. Replay only after fixing the cause, retaining the original idempotency identity. Amazon SQS dead-letter queue documentation
Define retention for source PDFs, parser output, model responses, review decisions, and diagnostic logs separately. Evidence must remain available for the agreed review and dispute window. Avoid full document text in routine logs, and make expiration visible so a retained record does not imply its evidence is still accessible.
8. Measure the entire pilot
Use a development set and a held-out evaluation set. An illustrative trial could contain 120 PDFs: 40 for tuning and 80 for evaluation, with representative scans, layouts, variants, missing fields, and revisions. Keep related copies and revisions together when splitting data to reduce leakage.
Have reviewers establish expected values and evidence locations. Measure:
- Field correctness, including correct missing-value decisions.
- Complete records requiring no edits.
- Records passing rules that still contain substantive errors.
- Reviewer handling time and total time to accepted staging.
- Technical failure rate, recovery time, and duplicate writes.
Suppose 624 of 640 evaluated field slots are correct: 97.5% field correctness. Suppose 52 of 80 documents pass the automated rules, but human review finds a wrong SKU in one of those 52. That false pass matters even though the overall field score looks strong. These figures are illustrative, not Hexagon client results or performance promises.
Deliberately test duplicate uploads, worker interruption after a write, destination downtime, and an older revision arriving late. Define acceptance criteria before the run and report results by supplier and layout. A small successful sample supports a bounded next trial; it does not establish universal accuracy.
Frequently asked questions
Not necessarily. Begin by testing a layout/OCR service plus field-mapping rules or a model that extracts the agreed schema. Compare that baseline against your held-out documents before adding training complexity. A custom extractor may be worth testing when recurring layouts or domain-specific fields remain unreliable. The decision should follow observed correction patterns, maintenance requirements, and measured quality on your documents.
It can expand later, but each format needs its own evidence strategy. Microsoft's documentation notes that bounding regions are returned for rendered files, while supported Office and HTML inputs are not rendered in that workflow. A spreadsheet cell reference or document section may therefore be more useful than a PDF-style page highlight. Keep the first trial PDF-only, then evaluate each additional format separately. Microsoft response documentation
Only after a separately evaluated rule identifies a sufficiently reliable subset for the business's error tolerance. Evaluate complete records, evidence correctness, and critical fields such as SKU, rather than relying on one average accuracy figure or a model's self-reported confidence. Continue checking a sample of automatically accepted records and route unfamiliar layouts, conflicts, and material changes to review. The initial pilot described here reviews every record.
Treat it as a new document version linked to the existing supplier and product, preserving the earlier extraction and decision. Compare changed fields and establish revision order using reliable source information or human review. A later upload timestamp alone does not prove a newer specification. Once approved, update only the intended staging fields and retain the prior version so a mistaken change can be investigated and reversed.
Build a pilot around a real document queue
Bring a representative, approved sample set, the target field list, and a description of today's catalog-entry process. Contact Hexagon IT Solutions to discuss the extraction, review, and integration work needed for a verifiable document-intake pilot.
