A freight brokerage onboarding a new carrier needs a packet back: a setup form, a tax worksheet, a non-disclosure agreement, a payment election and evidence of insurance. Most of this the carrier supplies, and an agent that sends the packet, reads what comes back and chases what is missing takes days of work off a desk.
The evidence of insurance is different. A certificate of insurance is issued by the carrier’s insurance producer, and it is the document a fraudulent carrier is most motivated to fake. A brokerage that accepts a certificate forwarded by the carrier has accepted a PDF from the one party with a reason to alter it.
The desk we built encodes this as a rule it cannot break: a certificate forwarded by the carrier never passes. The desk finds the producer’s details in the carrier’s insurance evidence, emails the producer directly, and only a certificate that arrives from the expected producer’s address counts. The carrier cannot be approved until it does.
Trust boundaries in automation
This is a general lesson. When a workflow is done by hand, the person doing it carries a sense of who is allowed to vouch for what, and applies it inconsistently, usually under time pressure. When the workflow is automated, that sense has to be written down as a rule about sources, and then it is applied every time.
For each document in the packet, the desk knows who may supply it. The carrier supplies its own forms. The producer supplies the certificate. The brokerage’s staff supplies the approval, with a click, after a compliant file is assembled. A document from the wrong source is not rejected rudely; it is quarantined, visibly, with the reason, and the desk goes to the right source for the real one.
Deterministic coverage rules
Once a certificate arrives from the producer, the rules are arithmetic. Liability and cargo limits at or above the brokerage’s minimums. A minimum remaining term. The named certificate holder matching the brokerage’s certificate-holder name. Each rule shows pass or fail in a visible audit beside the document. The model extracts the figures from the certificate; the rules decide; a person approves.
The brokerage’s requirements will differ from these, and so will yours. They live in one configuration file. What should not differ is that the rules are rules, not a model’s impression of adequacy.
Everything else the desk does
Staff type a carrier’s name and email. The desk generates the packet per carrier, sends it, polls the mailbox, classifies returned documents (PDF, image or scan, with a manual path for low-text files), extracts what it can, follows up for what is missing, and requests the certificate from the producer. The dashboard shows every case at its stage and every document with its verdict. When mail is not configured, the desk runs in a practice mode with fictional replies, and a practice email scenario shows a reply being accepted or quarantined on the strength of its sender address alone.
Why this matters beyond freight
Every document workflow has a certificate of insurance in it: the one document that the counterparty must not be allowed to supply. In vendor onboarding it is the bank letter. In compliance it is the audit report. In lending it is the appraisal. The first design question for automating any of these is not what the model can read. It is who is allowed to send what, and what the system does when the wrong party sends it.
About the authors. Neugent Consulting designs and builds AI systems for operators. The examples in this piece come from client work; clients are anonymised and details are simplified.
