From Evidence to an Operating System
Rust · Tauri · Local OCR · Node.js · SQLite · React · Claude API · ElevenLabs · 2026
Overview
A regional freight brokerage moved from an entirely manual dispatch desk to a purpose-built operations platform in under two weeks. The work happened in two acts. First, a consent-based observation tool recorded one real workday and turned it into an evidence-linked map of how the desk actually ran. Second, that map drove the build of the operations platform: a load board, carrier vetting, automated chasing, a communications feed, and an assistant named Linda who finds answers, drafts the next message, and waits for a human tap before anything leaves the building.
The Starting Point
Every load lived in a dispatcher's head, an inbox, and a legacy transportation system that nobody trusted for status. Chasing a driver meant a phone call. Knowing which loads were at risk meant remembering. Carrier vetting meant opening three websites. The owners knew the desk was doing too much by hand, but nobody could say precisely where the hours went, and every improvement idea started from an argument about the process rather than a picture of it.
Act One: Observe Before Prescribing
Rather than interview the team and guess, I built a workflow observer and ran it on the dispatcher's own machine for one agreed workday. It recorded every monitor, the microphone, and window context to local disk, read-only, with a live preview of what was being captured and a pause button for private moments. It never clicked, typed, or touched the company's systems.
The analysis side is separate from the recorder by design. Speech-to-text, OCR, and vision run locally behind narrow, replaceable sidecars; a Rust core validates every input and output before anything becomes canonical evidence. Anything missing, timed out, or unreadable is recorded as a named gap instead of quietly disappearing. External AI only ever sees redacted derived text, never frames, audio, or verbatim transcripts.
| The pilot day | Result |
|---|---|
| Captured | 9.3 hours, four displays, microphone, zero gaps |
| Indexed | 581 frames, 4,262 spoken utterances, 2,415 screen states |
| OCR engine choice | Benchmarked on real frames: 96.3% on 409 human-reviewed targets |
| Derived | 62 workflow episodes, a 23-node process graph, 8 cited claims, 5 opportunities |
| Traceability | Every claim resolves to clips, frames, or transcript spans (116 links to 93 sources) |
| Human review | 4 of 5 on accuracy, usefulness and practicality; 5 of 5 on evidence defensibility |
The report was deliberately a discovery draft. It refused to export a final business case because the client decisions and economic inputs it would need did not exist yet. That refusal is a feature: the tool reports observed time, bounded estimates, and hypotheses as separate things, and it does not pretend to prove causation or invent savings.
What the Evidence Said
- Status lived in conversations, not in a system. The same question was asked and answered by phone and email many times a day.
- Re-keying between the legacy transportation system, spreadsheets, and email was the dominant form of friction, not any single slow task.
- Risk was invisible until it was a problem. Nothing surfaced a load that was quietly going late.
- Carrier vetting was repeated, manual, and inconsistent across people.
- The team did not want a generic system with features they would never use. They wanted their desk, made faster.
Act Two: Build the Operating System
With the map in hand, the build was scoped to the friction the evidence had shown, feature by feature, each one graded against a written contract before it counted as done. Six days of shipping produced a platform the team runs on today.
| Layer | Technology | Why |
|---|---|---|
| API | Node.js + Express | Small surface, one process, easy to reason about |
| Data | SQLite (built into Node) | Zero operational overhead, nightly backups, one file to restore |
| Client | React + Vite, installable PWA | Desk on a monitor, dispatcher on a folding phone, same app |
| Assistant | Claude API with tool use | Reads through the app's own routes as the signed-in user; never more access than the person asking |
| Voice | ElevenLabs, browser wake word | Hands-free on the phone; transcription and speech behind a fenced key |
| Federal data | Local FMCSA mirror | 4.5 million carriers, refreshed nightly, queried in milliseconds |
| Hosting | Ubuntu VPS, nginx, pm2 | Production from day one, not a demo |
What Shipped
The board
- One live board of every active load with a clock on each: open, appointment needed, picking up today, delivering today, quietly late
- Jeopardy math from miles, hours, and the last known position; loads at risk surface before they miss
- A driver check-in page with no login: one text, one tap, position and note logged against the load
- Inbound email parsed into the load's timeline, with a per-load reply address so answers land where they belong
Carrier vetting
- Live federal authority and insurance verification, re-checked nightly, with an alert when authority is lost
- A configurable grading rubric with hard gates (no authority, no insurance, out-of-service) and weighted components
- A full federal safety record on any of 4.5 million carriers: crash rate, out-of-service rate, connected registrations, phantom fleets
No more game of chase
- Every communication on a load, outbound and inbound, human and automated, in one feed grouped by load with unread marks per person
- Team-level message templates and a signature on every outbound email; the wording is the team's, not the developer's
- Sweeps that escalate unanswered requests up a per-load chain and chase dispatchers on a tightening cadence as appointments approach
Linda, the ops assistant
- Answers "where is 22131" or "is this carrier ok to use" from the app's own data, with every tool call shown as a chip under the answer
- Proposes actions (text the driver, email the customer, escalate) as cards; a human taps SEND or NO, and nothing sends without the tap
- Watches for loads that go quiet and drafts the chase with the load's context, leaving it as a card on the board and in her panel
- Talks and listens: a wake word on the phone, spoken answers in a voice the admin locks for the whole team, and "send it" as a valid confirmation when the person chooses it
- Follows the same money rule as the API: margin and commission never reach a role that should not see them, on screen or in her answers
Key Design Decisions
- Evidence before software — A day of recorded work settled the argument about the process before a line of the platform existed. The build list came from clips, not opinions.
- The assistant proposes, people dispose — Linda has no route that sends. Her write tools create a proposal row; a signed-in human executes it through the same code path the screens use, within a time limit, exactly once.
- Same permissions as the person asking — Her reads go through the app's own API with the caller's session. A read-only account gets a read-only assistant.
- Boring infrastructure on purpose — One Node process, one SQLite file, one VPS. The novelty budget went into the workflow, not the stack.
- Contracts and adversarial grading — Every feature pass started with a written contract and ended with a grade against the live system, by API calls and browser harnesses, before it was called done.
- Privacy as architecture — The observer has no network path out. Raw media never leaves the machine. Redaction, egress, and consent are code, not a policy page.
By the Numbers
| The platform | At the time of writing |
|---|---|
| Time from first commit to the team using it | Six days |
| Commits | 279 |
| API routes | 161 |
| Database tables | 33 |
| Automated tests | 71, run on every deploy |
| Carriers searchable offline | 4.5 million |
Outcome
- One source of truth for every active load, on the desk and in a pocket
- Loads at risk are visible before they are late, and the chase starts without anyone remembering to start it
- Carrier vetting takes one screen and is consistent across the team
- Every conversation on a load is in one place, with who has and has not seen it
- An assistant the team can talk to, that cannot act on its own
- A discovery report the client can challenge, clip by clip, instead of a slide deck of assumptions
What This Says About How I Work
Start with observation and measurable evidence. Keep sensitive data local and make egress an architectural decision. Use AI as a bounded, replaceable component with a human on every consequential action. Write down what done means before building, then grade against the live artifact. Finish with a system the team runs on, not a demo looking for a problem.