A WORKED EXAMPLE

What a deployment looks like when it's built to be handed over

This is the reference engagement behind the 0tomait method: a freight brokerage drowning in billing paperwork, two shipped automations, and the documentation discipline that keeps them alive after the engineer moves on.

note: Meridian Freight is fictional, built as the worked example for the published method. The discipline shown here is the real product, and every manifest artifact on this page sits in the public repository where you can read it in full. The tool views are stylized recreations, marked as such.

The setup

Meridian brokers truckload freight between shippers and roughly 900 carriers. Nothing gets invoiced without a signed proof of delivery on file, and matching that paperwork to loads by hand kept billing three to nine days behind. Two staff spent most of their week rekeying documents out of a shared inbox while days-sales-outstanding drifted past 45.

78h → 9h
Median time from delivery to invoice sent
23%
Documents still needing human review. The target was 20%; the manifest records the miss instead of hiding it.
2
Flows shipped: document intake and matching, gated invoice generation
PHASE 1 / EMBED

Learn what the code can't tell you

The first weeks produce no code. They produce the context that makes every later decision safe: what words mean in this building, who decides what, and which data quirks will silently corrupt a naive integration.

glossary

"POD" means proof of delivery. The signed document that gates all revenue. Newcomers confuse it with the BOL, issued at pickup. An AI agent would confidently read "pod" as Kubernetes. The glossary exists so neither mistake happens.

data quirk

Load numbers reset every fiscal year. Joining on load number alone silently mixes a 2025 load with a 2026 one. The safe key is fiscal year plus load number. This one line in the manifest prevents a data corruption bug nobody would trace for months.

who decides

Dana decides, Priya gates access. Anything a customer could notice needs Dana, the VP of Operations. All system access flows through Priya, an IT contractor reachable two days a week. Miss that fact and every schedule slips a week.

PHASE 2 / SHIP

Automation on the client's rhythm

Two flows went live. One watches the billing mailbox and files carrier paperwork against its load. Here is what that looks like in the field, minutes after the morning trucks report in:

billing@meridianfreight · inbox · polled every 3 min recreation
Swift Haul LLC
POD Load ML-471198 · signed_pod.pdf
filed · match 0.97
Baker Logistics
delivery paperwork, 4 loads · pods.pdf
split · filed 4/4
TNT Carriers
RE: RE: paperwork · IMG_2291.jpg
queue · handwritten 0.61

unread mail is the review queue: nothing is ever lost, it stays visible until a human clears it

The other flow runs on Meridian's twice-weekly billing rhythm and raises the invoices. Both fail closed: an item that errors is skipped whole and reported, never half-executed. The operator's interface is the run summary:

#meridian-alerts recreation
mb
meridian-billingAPP
The sweep is done. invoiced 214 loads · $407,180 skipped 3: 471544 customer-not-mapped · 471561 credit-hold · 471580 split-load → manual 1 draft over $25,000 awaiting review: INV-8841 ($31,400)
M
Marcus Bell
Added the QuickBooks mapping for Brightline Foods. 471544 will catch on the next run.

every skip carries its reason, and skips self-heal: fix the cause and the next run picks them up

Invoices over $25,000 stay human-approved, because the whole project was approved on that condition. And the manifest records how the intake flow fails, honestly:

manifest · flows.pod-intake.failure_mode
"on_failure": "Retries three times with backoff, then leaves the
  email unread and emits a CloudWatch alarm. Unread mail is the
  safety net: no POD is ever lost, it just stays in the inbox
  for a human.",
"who_notices": "CloudWatch alarm to #meridian-alerts, which Marcus
  watches. Nobody watches it on weekends."

That last line is deliberate. Weekend coverage was priced, declined by the client, and recorded. Honest gaps beat comfortable silence.

PHASE 3 / DOCUMENT

Decisions keep their reasoning

Every consequential choice is recorded with the alternatives that lost and the condition that should reopen it. Here is one: the mailbox is polled every three minutes instead of using push notifications, which sounds backwards until you read why.

manifest · decisions.poll-not-webhook
"decision": "Poll the billing mailbox on a 3-minute delta query
  rather than subscribing to change notifications."
"context":  "Subscriptions expire every three days and must be
  renewed by a running process. Meridian has no weekend coverage,
  so a renewal failure on a Friday would silently stop POD intake
  until Monday. Polling costs trivially more and degrades visibly."
"rejected": ["Graph webhooks: invisible single point of failure",
             "IMAP: basic auth disabled by tenant policy"]
"revisit_when": "Meridian establishes real on-call coverage."

A successor who prefers webhooks now knows this was a considered trade, what would make it wrong, and when to revisit. Without this record they would "modernize" the trigger and reintroduce the exact failure it avoids.

PHASE 4 / HAND OVER

Staffed roles and a talking deployment

Every human step has a named owner and a family tree. Meridian's queue has already survived one staffing change, and the record shows both the failure and what it taught:

Tina Okafor · queue-operator

2026-03-02 → 2026-05-30

Left Meridian. No walkthrough existed yet, so the queue reverted cold to her supervisor and a two-week backlog followed. The pairing script below was written as a direct result.

Marcus Bell · queue-operator

2026-06-02 → present · trained_via: wt-queue-morning

The next transition follows a procedure: close the tenure, open the new one, deliver the walkthrough.

The tooling then reads the document back and says what a polite consultant might soften. This is the actual validator output for this deployment:

$ node tools/validate.js --patterns patterns/ meridian.manifest.json
! warnings (2)
    systems[3] (accounting): System last verified 93 days ago.
    flows[0] (pod-intake): nobody is recorded as noticing this
      flow failing. Record it as a risk if genuinely unmonitored.

· notes (4)
    flows[0] (pod-intake): every human step runs through one
      person (Marcus Bell). The family tree shows no backup —
      a planned absence becomes an outage.
    systems[0] (tms).lineage[1]: Priya Chandran inherited
      'administrator' with no walkthrough on record.

The deployment also talks back. Operators' complaints become field reports with a tracked lifecycle, so the system surfaces its own gaps:

friction · open marcus-bell · queue session

"The handwritten ones take three or four times longer than anything else in the queue. Most mornings they are the whole queue."

gap · open dana-reyes · email

"I cannot see which delivered loads are still waiting on paperwork without asking Marcus. Before the automation I could at least see the pile on his desk."

bug · resolved marcus-bell · #meridian-alerts

A duplicate POD slipped past dedup when a carrier re-sent it with a cover sheet. The resolution is written down where the next engineer will find it.

Finally, the whole manifest compiles into a briefing an AI coding agent can maintain the system from. Your constraints become its hard rules:

compiled agent briefing · excerpt
## Hard rules — never violate these

- Do not write to the TMS from any deployed flow. Read only,
  and only against the replica. (technical)
- Invoices over $25,000 must remain human-approved. Dana
  agreed to the whole project on this condition. Removing it
  without asking her would damage the relationship well beyond
  the value of the automation. (political)
THE OUTCOME

This is what you'd be holding

Working automation, the reasoning behind it, staffed roles with walkthroughs, and a system that reports its own friction. Maintainable by the next engineer, your own staff, or an AI agent. The method is public; the engagement is yours.