This page is an architectural specification for carriers and 3PLs evaluating touchless bill of lading and proof of delivery workflows. A document moves from a camera frame to a clerk decision and then to a staging row. Thresholds below are illustrative audit policy, not measured deployment scores.
Touchless, in this specification, means the clerk does not retype a clean document. It does not mean an unattended invoice. The safe default is human confirm before any financial post. A vision worker may propose fields. It may not bill a customer, close a claim, or rewrite a live dispatch row.
- Touchless means the clerk does not retype a clean document. It does not mean an unattended invoice.
- A quality gate rejects bad cab frames before extraction, and enhancement can never promote a reject.
- Every field carries its own confidence. A required field under the floor routes to a clerk.
- Exact keys match first. Piece-count breaks and exception stamps never auto-bill.
- The vision worker ends at a staging insert. It never updates the live dispatch load row.
Scope of this specification
The audience is an operations, billing, or IT lead deciding whether document intelligence is ready to sit beside a transportation management system. The boundary is freight paperwork: bills of lading, proofs of delivery, lumper receipts, and the stamps and signatures on them.
Strong Tower Consulting, LLC is the Minnesota freight systems consulting firm founded in 2008 by Scott Elliott (strongtoweronline.com). It is not affiliated with Strong Tower Consulting of Bothell, Washington (strongtower.consulting or strongtower.ai).
The work is defensive. It specifies how to reject a bad frame, hold a mismatch, and keep the original image for audit. It does not describe forging a bill of lading, changing a weight, copying a signature, or hiding a shortage.
Why driver-cab photos defeat naive OCR
A desktop scanner produces a flat, evenly lit page. A cab photo does not. Naive OCR assumes intact glyphs, a straight baseline, and stable contrast. Those assumptions fail together on a driver frame, and the recognizer still returns a confident string that is wrong.
Crumple splits a pro number across a crease or turns the crease into an extra digit. Glare on glossy stock erases a digit run while the rest of the page looks fine, so a page-level score stays high and the match key is gone. Night cab lighting, from interior LEDs or a phone screen, shifts color until thresholding drops the header and keeps the logo. Motion blur collapses stroke width so that 8, 0, and 6 interchange, and one substituted digit misses an exact key.
Thermal paper fade on a lumper receipt can leave the logo and erase the total. Copying the expected amount from the order is not a reading. A thumb over the pro number occludes the exact-match key. Guessing or inpainting those digits fabricates an identifier, so confidence is capped when a field overlaps an occlusion, and digit inpainting is refused. Skewed perspective slides one line's weight onto the next line. Low resolution, a short edge under the audit minimum, cannot support a weight digit. The quality gate rejects these frames or sends them to a clerk with the original image. A reject is not enhanced until it looks clean and then treated as accepted.
Reference pipeline
The reference pipeline fails closed at each stage. Capture takes a frame, stop id, user id, and device timestamp. The quality gate accepts, marks for enhancement, or rejects the raw frame. Pre-process cannot promote a reject. Layout detection finds the header, parties, line items, stamp band, and signature band. Few-shot extraction fills a fixed schema with a confidence on every field, using a small set of the carrier's own forms rather than a universal model. Entity resolution matches shipper and consignee to the party master. An unresolved name does not create a customer.
TMS line match tries exact keys first, then a narrow fuzzy comparison on commodity and weight. The exception queue holds low confidence, piece-count breaks, exception stamps, and identity conflicts. Human confirm is a clerk action with an audit record. Writeback inserts a staging row. The vision worker stops there. A separate poster, after confirm, is the only path toward the system of record. Touchless processing removes retyping on the clean path. It does not remove the person from the financial path.
| Stage | Input | Output | Fail closed behavior |
|---|---|---|---|
| Capture | Frame, stop id, user id, device time | Raw object and document id candidate | Missing stop id or unreadable file is rejected at the edge |
| Quality gate | Raw frame | Accept, enhance, or reject | Reject stops the pipeline and asks for recapture |
| Pre-process | Accepted or enhance-band frame | Deskewed, dewarped, masked raster | Re-measure after enhance; failure returns to reject |
| Layout detection | Clean raster and document class | Regions for header, parties, lines, stamps, signature | Missing required region routes to the clerk |
| Few-shot extraction | Regions plus a small labeled set of the carrier's forms | Schema fields with per-field confidence | Required field under the floor routes to the clerk |
| Entity resolution | Shipper and consignee strings, party master | Party ids or an unresolved flag | No new customer is created from a document string |
| TMS line match | Keys, commodity, weight, pieces, open orders | Order id and match class | No exact key and no in-tolerance fuzzy match opens an exception |
| Exception queue | Low confidence, stamp class, identity flags | Clerk work item | Item cannot be auto-billed |
| Human confirm | Proposed fields, original image, match | Accept, edit, or reject | Service account cannot confirm its own proposal |
| Writeback | Confirmed payload, document hash, order id | Staging row | Duplicate key is a no-op; live load row is not updated |
Pre-processing specification
Pre-processing is an audit specification, not a vendor claim. The carrier records the numbers in its own standard. Duplicate detection runs on the raw frame so two bursts of one page collapse to one document. Short-edge and blur are measured on the raw frame next. A reject there is final. Deskew, perspective dewarp, glare mask, and contrast normalization run only in the accept and enhance bands, then the frame is measured again. Enhancement cannot promote a reject.
- Duplicate detection. Runs on the raw frame so two bursts of one page collapse to one document.
- Short edge and blur. Measured on the raw frame. A reject here is final.
- Enhance in band. Deskew, perspective dewarp, glare mask, and contrast normalization run only in the accept and enhance bands.
- Re-measure. The frame is measured again. A failure returns to reject.
Deskew runs when skew exceeds 1.5 degrees. Above 12 degrees, or when the corner set is incomplete, the frame is recaptured. Perspective dewarp runs only when four corners are high confidence and fit a page prior. Otherwise the page is not stretched, because stretching can move a digit across a field boundary. A glare mask drops a field crop that overlaps it by more than an illustrative 20 percent. Contrast normalization after the mask uses a named clip limit. Gamma lifts and generative fill do not overturn a reject. The table states the acceptance thresholds, including short edge, blur, glare coverage, and duplicate-frame distance.
| Check | Accept | Enhance, then re-measure | Reject |
|---|---|---|---|
| Short edge | 1600 px or more | 1200 to 1599 px if glare and blur also pass | Under 1200 px, or any upscale used to fake the accept band |
| Skew | Under 1.5 degrees | 1.5 to 12 degrees, then deskew | Over 12 degrees, or corners incomplete |
| Perspective | Corners confident and near-rectangular | Material perspective with a full corner set, then dewarp | Low corner confidence; do not stretch the page |
| Glare mask | Under 5 percent of the page | 5 to 12 percent; mask and drop overlapped crops | Over 12 percent of the page |
| Blur | At or above the configured floor | No blur enhancement; blur is not repaired | Below the floor on the raw frame or after re-measure |
| Duplicate frame | Hash distance above 8 versus the prior stop frame | Distance 6 to 8; keep one and link the duplicate | Distance under 6; drop the later frame |
| Thermal total line | Ink still separates from paper after normalization | Weak total; send that field to the clerk | Total line gone; recapture the receipt |
Few-shot entity schema
Few-shot means the carrier labels a few dozen of its own pages per class and judges the extractor on that set. It does not mean a general model that already knows freight. Classes include a dry van BOL, a lumper receipt, a reefer POD, and a handwritten annotation. A lumper receipt requires vendor, date, amount, and a stop or pro reference, not freight class. Handwritten weight, pieces, and pro numbers always go to a clerk.
The BOL and POD field set is: shipper, consignee, BOL number, PO, PRO, pieces, handling unit, weight, freight class or commodity, seal, appointment, OS&D stamps, a driver-signature-present flag, and document date. Every field carries its own confidence from 0 to 1. Null is allowed only when the document class declares the field optional. Null is not a substitute for low confidence. A required field that the layout missed is confidence 0 and routes to a clerk.
Illustrative floor for a fast confirm path: 0.90 or higher, all at once, on PRO or BOL number, pieces, weight, shipper, consignee, and stamp class. Any miss routes the document to a clerk and does not post. The floor is policy, not a model benchmark. A dark corner mark is not a signature. Ambiguous dates are not auto-accepted. Seal and appointment may be null only when the class marks them optional.
Multimodal context contract
Multimodal, in this specification, means the image is read with a small amount of TMS context available to rank candidates: a known pro, a known shipper, a stop id. Context may reorder hypotheses. It may not replace a scanned numeral with the value stored on the order. The scanned token remains the evidence. If the image and the order disagree, the document goes to the exception queue. A model that "corrects" the bill so it matches the load will hide shortages, and that behavior is out of spec.
Context may reorder hypotheses. It may not replace a scanned numeral with the value stored on the order. If the image and the order disagree, the document goes to the exception queue.
The same rule covers lumper receipts. If thermal fade has removed the total, the pipeline does not copy the expected lumper amount from the order. The field stays empty and the frame is recaptured or clerked. Inpainting identifiers is prohibited. So is silent substitution of MC number, DOT number, weight, pieces, or pro number from master data. Allowed context is the document class, the open orders on that stop, and the party master used after extraction. Those inputs are logged with the proposal.
Line-item match to TMS orders
Match order is exact keys first. BOL number, PO, and PRO are compared as normalized strings: case folded, separators removed, check digits preserved. An exact hit on a key the carrier treats as unique can attach the document to that order. Fuzzy commodity text and weight tolerance run only after that, and only to support a keyed match. They are not a license to attach a document to any open order with a similar commodity.
Order weight 18400 lb, extracted weight 18320 lb. Tolerance is the greater of 2 percent or 50 lb.
max(18400 x 0.02, 50) = 368 lb; |18400 - 18320| = 80 lb (inside)
Extracted pieces of 21 against 22 still open an OS&D workflow. The row is not auto-billed.
Illustrative weight policy: plus or minus 2 percent or 50 lb, whichever is greater. Worked example, labeled illustrative, not a client result. Order 100245 shows BOL B-88421, PO 55219, PRO 441908, commodity canned food, weight 18400 lb, 22 pallets. Extracted weight is 18320 lb. The difference is 80 lb. Two percent of 18400 is 368 lb. The greater of 368 lb and 50 lb is 368 lb. 80 lb sits inside that tolerance, so weight alone does not open an exception. Extracted pieces of 21 against 22 do open an OS&D workflow. The row is not auto-billed. A second illustrative case: extracted weight 17000 lb against 18400 lb is a 1400 lb gap, outside the tolerance, exception, no auto-bill.
Piece-count breaks always open an OS&D workflow, including when weight is inside tolerance. Two cartons short is not one pallet short. A mismatch on pieces, handling unit, key, or weight does not auto-bill.
POD and exception stamps
Stamp class is a controlled vocabulary. The layout step isolates the stamp band, the extractor assigns one class, and billing and claims read that class. A signature crop stored with the document hash is evidence, not proof of condition. Drivers sign damaged, refused, and clean freight. Cartons and pallets stay distinct. The model does not convert cartons into pallet equivalents, and it does not auto-bill a refused, short, or damaged line.
| Stamp class | Claim state | Billing state |
|---|---|---|
| Clean, signature present | No claim opened by the document alone | Eligible for confirm, then stage |
| Shortage | OS&D shortage | Hold billing on the short line |
| Damage | OS&D damage | Hold billing pending disposition |
| Refused | OS&D refused | Do not bill the refused quantity |
| Cartons versus pallets noted | Count exception | Hold until the unit of measure is reconciled |
| Signature missing | Evidence gap | Clerk review; do not assume a signature |
| Illegible stamp | Unknown exception | Clerk review; do not map to clean |
Illustrative reefer POD: a missing temperature recorder stays a damage or temperature exception even when the signature flag is true. Billing holds and a claim state opens. The signature crop does not clear the stamp. Illustrative handwritten case: pencil weight on a dry van BOL forces clerk confirm on weight, pieces, and PRO.
Carrier identity controls tied to documents
These controls are a procurement and payables design. They are not a scoring product, and they do not replace registration checks a compliance desk already runs.
Compare the MC and DOT printed on the carrier packet, or on the rate confirmation in the packet, with the MC and DOT in the BOL header and with the registration record the desk already reviews. A header MC that differs from the packet MC opens an identity exception. The pipeline does not overwrite the printed MC with the packet value. TIN consistency is the same shape of control: the taxpayer identifier used for payment should match the vendor master. This page does not collect TINs and does not include sample identifiers.
A factoring notice that names a different payee than the vendor master blocks payment release until procurement clears it. A printed total that disagrees with the sum of line weights, beyond the illustrative tolerance, is flagged. The original image is the evidence. A signature crop whose perceptual hash matches a prior crop on a different order, date, or PRO goes to the vetting queue for a person to review. This specification stops at detection. It does not describe how a signature would be copied.
Carrier 411 style monitoring, when a carrier or broker already subscribes to that kind of external watch service, is an input to the same review queue. It is not a Strong Tower Consulting product, and this specification does not resell or replace it. Store the external alert id beside the document hash so a clerk can see both on one party.
Evaluation design
Go-live rests on a golden set the carrier builds from its own real documents: dry van BOL, lumper receipt, reefer POD, and handwritten annotation. A senior clerk labels the pages, and a sample is labeled twice. This page does not invent a page count, a client name, or an accuracy percentage.
Report precision and recall by field, not one page-level accuracy number. A page can look mostly right and still mis-state weight. Precision is the share of filled values that match the clerk. Recall is the share of clerk values the system filled correctly. Required fields for an acceptance decision are PRO or BOL number, pieces, weight, shipper, consignee, stamp class, and the signature-present flag. Strong shipper scores with weak weight scores are not a fast path.
A false auto-post and a false reject do not cost the same. Illustrative framing only: a false auto-post can bill the wrong weight or close an OS&D event that should have stayed open. A false reject costs clerk minutes. Threshold policy should make the false auto-post rare. The acceptance test is the field table plus queue aging, not a marketing accuracy figure. Readiness review sits in the carrier AI readiness evaluation guide. Vendor review sits in the carrier AI vendor due diligence checklist.
Writeback contract
The vision worker writes to a staging table on a read/write integration schema. It does not update the live dispatch load row. The database role used by the worker has insert rights on the staging table and no update right on the dispatch load table. That denial is part of the specification, not an optional hardening step. A poster job, running under a different role, reads rows a person has confirmed and applies them through the integration the carrier already uses.
The idempotency key is the document hash plus the order id. The same hash and order insert once. The same hash with a second order id is an exception unless a clerk marks a true multi-order document. A new hash on the same order, such as a corrected POD, does not overwrite the earlier image. Billing uses the clerk-confirmed row.
Do
- Insert proposals into a staging table
- Key on document hash plus order id
- Keep original bytes at the image pointer
- Post only after a clerk confirms
Avoid
- Updating the live dispatch load row
- Overwriting an earlier image with a corrected POD
- Inpainting or substituting identifiers from master data
- Auto-billing a piece-count break or exception stamp
Staging holds the hash, order id, field payload, confidences, stamp class, image pointer, and confirm state. Original bytes stay at the image pointer. A normalized raster is a sibling, not a replacement. Vision output does not emit an EDI 210 by itself. A later 214 or 210 feed is the separate TMS EDI 204, 990, 214, and 210 transaction lifecycle playbook. Dispatch constraints are specified in the predictive dispatch constraint solving guide, not here.
Operating model
The clerk queue needs an owner and an escalation. Illustrative policy, not a measured client service level: clean fast-path items are confirmed within the same shift; exceptions are worked within 4 business hours; older items escalate to a billing lead. The queue shows the original image, the proposal, the match class, and the reason code.
The original image is retained on the carrier's records schedule, addressed by document hash. A derivative does not replace it. The capture user can submit a frame and cannot approve it. The vision service account can insert a proposal and cannot confirm, override, or delete.
Override authority sits with a named billing lead or OS&D clerk role. An override does not delete the extraction. The append-only audit log records actor, time, document hash, order id, field, previous value, new value, and reason code, and it keeps both order ids when a match is corrected.
Identity review is specified separately in the freight brokerage carrier vetting and fraud prevention architecture. Rating guardrails are in the freight rate predictive modeling and margin guardrails note. A document workflow does not silently change a rate.
Frequently asked questions
Why do driver-cab photos defeat naive OCR on freight documents?
Cab photos combine crumple, glare, night lighting, motion blur, thermal fade, occlusion, skew, and low resolution. A single-pass OCR engine reads whatever glyphs survive and will drop or invent digits. This specification rejects those frames at a quality gate before field extraction.
What stages belong in a touchless BOL and POD reference pipeline?
The reference pipeline is capture, quality gate, pre-process, layout detection, few-shot field extraction, entity resolution, TMS line match, exception queue, human confirm, and writeback. Writeback lands on a staging table. Each stage fails closed.
When does low field confidence route to a clerk instead of posting?
A required field under the confidence floor, a missing exact key when policy requires one, a piece-count break, an exception stamp, or a carrier-identity conflict routes the document to a clerk. The vision worker does not post those rows, and it does not auto-bill a mismatch.
Why must vision writeback use a staging table?
The vision worker may insert only into a staging table on a read/write integration schema. The idempotency key is the document hash plus the order id. A later step, after human confirm, applies the row. The worker never updates the live dispatch load row.
Design a document pipeline that fails closed.
Strong Tower Consulting provides independent systems architecture, feasibility audits, and engineering roadmaps for motor carriers and freight brokers. Contact our advisory team or call 763-244-1373 to discuss your operational data and evaluate practical implementation paths for your fleet.
Published October 23, 2026 by Strong Tower Consulting, LLC. Founded 2008 in Minnesota by Scott Elliott.