// the problem

The pack is checked by eye, at the worst possible moment

Every shipment travels with a document pack - bill of lading, invoice, certificates, packing list - and every pack has to agree with the shipping instruction. In most trading desks that check happens by eye, draft by draft, field by field, usually on the day the vessel cuts off. The instruction sits in one place, the drafts in another, and the person in the middle is the control.

Then come the originals. Somebody has to remember that they were promised, notice they haven't arrived, and chase. That memory lives in inboxes and heads, which is why the missing original is discovered when the bank asks for it.

// how it solves it

The model reads. Fixed rules decide. A person approves

Ship-Doc watches one OneDrive folder per shipment. Every morning, and within minutes of a file landing, it names each file from its filename, checks the required documents are present, reads the fields that matter out of each draft with a model, and compares them with the shipping instruction you typed on a SharePoint list - by fixed rules, with a tolerance for numbers you set per document.

Nothing ships on the model's word. Presence is set arithmetic, agreement is a fixed comparison, and every failure names both values, so a discrepancy notice is an argument you can check, not a verdict to trust. A named person approves on a form; approving asks the counterparty for the originals and starts the chase clock - a nudge after three days, an escalation with your manager copied after seven, silence once the originals folder has the files.

The one message that quotes what the model read is marked as AI-generated, readable and machine-detectable; the chases and approvals, written by fixed rules from values people typed, are deliberately unmarked. That's Article 50 of the EU AI Act, handled where the work happens.

// how it works

Scan, compare, approve, chase

01
ScanFolders listed every morning and on every new file; documents named from an alias table, presence checked without a model
→
02
CompareA model copies the fields your requirement rows name out of each draft; fixed rules compare them with the instruction
→
03
ApproveA named person approves or rejects on a form; who and when is recorded on the shipment row
→
04
ChaseOutlook asks for the originals and escalates on a schedule, until the originals folder has the files

One workflow, 51 nodes, three SharePoint lists, no database. Runs on self-hosted n8n; without an Outlook credential everything still works, and nobody is emailed. Published as an n8n template: Check shipping documents against SharePoint instructions.

// what makes it different

Built for the desk that owns the shipment, not the IT department

data, not nodes
Requirements are data

Which documents a contract needs is one SharePoint row per document type: required or not, original to follow or not, which fields must agree, what tolerance applies. A new contract shape is typing, not workflow surgery.

your row
The instruction stays yours

The worklist is a SharePoint list a person already types. Your row is the shipping instruction; the workflow writes only the status columns beside it. Nothing overwrites what you entered.

bounded model
One job for the model

The prompt is generated from your requirement rows, so the model is asked for exactly the fields your contract cares about and nothing else. A call that fails is a document that could not be read - recorded as such, never a pass.

your stack
Runs where you already are

OneDrive, SharePoint and Outlook under one Azure app registration, orchestrated by self-hosted n8n. No new storage, no new inbox, no database to run. The model endpoint is a setting, so a proxy or a local runtime is configuration, not a rebuild.