Read rate confirmations, bills of lading and invoices into structured records, carry the page each field came from, and never generate, amend or replace the document itself.
Handwritten bills of lading are the cohort a total under-counts: a small share of the volume, a large share of the corrections. Nestack reports the correction rate by document type, not only in aggregate.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Handwritten bills of lading
5.1%
3.2×
Review
Scanned and faxed copies
4.3%
2.7×
Review
Non-English invoices
3.0%
1.9×
Watch
Digital rate confirmations
1.0%
0.6×
Normal
Bar: correction-rate lift vs. digital rate-confirmation baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
A cycle closes on a case, not a correction
An apology does not close a cycle; a case the next release must pass does. That suite is what the next document read into the system is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Corrections rise in one document type.
02Diagnose
No cause is accepted until the document, the page and the extracted field have been read back against each other.
03Improve
The correction is versioned, with the documents that motivated it attached.
04Verify
A failing case holds the release until it passes.
05Learn
The case is added permanently, and the extraction rules move with it.
Learn → DetectThe return edge. The next document read is measured against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, reading workflow, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Document workflow discovery and boundary definition.
02Document, TMS and EDI source assessment.
03Document-type rules and required-element field mapping.
04Document ingestion and field normalisation.
05Extraction logic and page binding.
06Confidence scoring and field routing.
07Acceptance workflow.
08Document-system integration.
09Field-extraction regression cases.
10Guardrails and acceptance controls.
11Document-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
Capability✓ in scope · — not at this tierPilotOne document type, one laneProductionProduction document systemsAdvancedMultiple formats / entities
Introduced at Pilot
Reading to your document rules✓✓✓
A person accepts each field✓✓✓
Extraction-accuracy baseline✓✓✓
Introduced at Production
Reporting by document type—✓✓
Acceptance workflow in your systems—✓✓
Approved record write-back—✓✓
Document-system integration—✓✓
Introduced at Advanced
Multi-format and multi-language rules——✓
Multi-stage acceptance approvals——✓
High document volume——✓
Multi-format document controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, transaction volume, approval controls and deployment requirements.
Separate from buildBuild pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bringWe build with it
01Your document types and where each one arrives→Document-type rules and required-element mappingWeek 1
02Representative documents, including the bad scans→Extraction baseline, field normalisation and page bindingWeek 2
03Your field definitions and the record they feed→Extraction-rule mapping and automation-boundary definitionWeek 1
04Access to relevant APIs, feeds or exports→Document, TMS and EDI assessment, then integration setupWeek 2
05Fields you would not want posted→Extraction cases and the evaluation suiteWeek 4
06What an extracted field may never replace→Confidence scoring, field routing, guardrails and acceptance controlsWeek 3
07Named people to accept extracted fields→Acceptance workflow, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Each band covers the weeks the work really takes, so week 5 carries evaluation and launch together.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Document workflow discovery, type rules and the automation boundaryW2Source integration and the extraction baselineW3Extraction workflow, confidence logic and acceptance controlsW4Evaluation suite, required-element checks and failure-mode testingW5Document-system integration, pilot documents and targeted correctionsW6One document cycle read under the operations team, then handover
Reading the bandA bar sits on the weeks its work is named in and no others. The week 5 overlap is real work, not padding.
At the end of W6Validation finishes on live documents and Agent Care assumes monitoring.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Transportation AI agent
Build a document agent around what may lawfully be done to each document.
Which documents may the agent only read, which may it compare, and who accepts a field before it moves? Show us where they arrive, and we'll map the workflow and set the boundary.