ClearPath

Inspiration

This project started with my friend Mohsin — a founding engineer at Omi, the open-source AI wearable company — who, on top of writing firmware and the mobile app, somehow also ended up owning logistics. Real hardware, real lithium batteries, real customs forms: thousands of units moving from a Hong Kong warehouse to customers around the world.

Here's what Mohsin's day actually looks like: a device with a tiny 0.925 Wh li-po battery is, depending on who you ask, either a completely ordinary package or a regulated dangerous good. The answer lives scattered across the IATA DGR, packing instruction PI967, 49 CFR 173.185, each carrier's own lithium battery policy, and a pile of national postal prohibitions that change without warning. Ask three carriers whether they'll take the same box and you get three different answers. He's had shipments refused at the counter, lanes silently closed by an operator variation nobody knew existed, and entire evenings lost cross-referencing a PDF from 2024 against a rule that changed in 2026.

And here's the part that surprised us: there is no real tool for this. His actual workflow today is pasting IATA excerpts and carrier PDFs into a chat with an LLM and manually cross-checking every answer against the source documents — because a raw LLM will happily hallucinate a packing instruction, and in this domain a confident wrong answer means a seized shipment or a banned carrier account. The existing commercial tools are duty calculators and HS-code lookups; none of them answer the question he's actually asking, and none of them can prove their answers. The state of the art is a smart person babysitting a chatbot with a stack of PDFs.

That was the itch. Every "AI compliance" tool gives you a verdict — approved or blocked — when what an operator needs is a plan. "Blocked" is not information. "DHL won't take standalone cells without DG approval, but FedEx will if you keep state of charge under 30%, and here are the countries where the postal channel is closed regardless" — that's information.

And Mohsin wasn't alone. As we dug in, we talked to other people who ship hardware, and they had the same scars — the three-different-answers problem, the lane that silently closed, the evening lost to a PDF. This isn't one person's edge case; it's what everyone shipping batteries quietly deals with. So we built the agent Mohsin wished existed — grounded in his experience at Omi and validated against a range of other operators who'd hit the same wall.

What it does

Give ClearPath a product — describe it, fill the structured spec fields, or drop in its MSDS PDF and it extracts the battery details for you. It returns:

1. A verified compliance profile — HTS classification, UN number, packing instruction, section, required marks and documents, landed cost, and a live sanctions screen — with every determination linked to the source text that justifies it, and an independent model confirming each citation actually says what we claim.

2. A live feasibility matrix — carriers × destinations, every cell resolved to SHIP, CONDITIONAL (with the exact unlock conditions), or CLOSED (with the citing rule and, where possible, the nearest open alternative). A closed cell is never the end of the answer. Drag a state-of-charge slider and watch entire columns flip red in real time.

3. Lane playbooks — click any viable cell and get the service to book, the documents to prepare, the marks to print, and the landed cost broken down to the line.

Formally, each cell is the intersection of three independent rule sets:

$$ \text{cell}(c, d, m) \;=\; R_{\text{reg}}(p, m) \;\cap\; R_{\text{carrier}}\big(c, \text{DG}(p, m)\big) \;\cap\; R_{\text{country}}(d, p, m) $$

where $p$ is the product, $m$ the transport mode, $c$ the carrier, and $d$ the destination. Modeling shippability as this intersection — rather than one monolithic "is it legal?" question — is the insight the whole system hangs on.

How we built it

Our design law, enforced in code review: models read, rules decide. No LLM output ever becomes a final decision or a matrix cell directly — it passes through a deterministic rule engine first.

• Three open-source models on Nebius, deliberately from different families: a planner (Llama 3.3 70B) that reads free text and MSDS PDFs into a structured product profile — and asks when a required field is missing instead of guessing (it flags a contradiction rather than silently picking one); a classifier (Qwen3-235B) that walks the HTS General Rules of Interpretation over regulation text; and an independent verifier (DeepSeek-V4-Pro) that receives only (claim, cited source passage) and answers one question — does this text actually support this claim? Using different model families for proposer and checker is itself a safety argument. Three models, live, at a fraction of a cent per run.

• A deterministic core with no LLM imports allowed: the dangerous-goods decision tree (IATA guidance and 49 CFR encoded as YAML), per-carrier acceptance rules and per-country restriction files, duty and VAT arithmetic, and denied-party screening against the live trade.gov Consolidated Screening List — a real match on the federal SDN list routes the shipment to a human. The matrix solver evaluates the intersection above for every cell and streams each resolution live, which is why you can watch the matrix solve itself, cell by cell.

• A hash-chained audit log: every extraction, retrieval, proposal, verification, and rule firing is an append-only entry linked to the one before it:

$$ h_i = \text{SHA256}\big(e_i \,|\, h_{i-1}\big) $$

Tamper with any past entry $e_i$ and every hash after it breaks under verification. Compliance without a tamper-evident audit trail isn't compliance.

• A conversational intelligence layer over the decision history: every compliance decision is logged, and CRAFT (Emergence) lets you query the entire audit history in plain English — "show every shipment we blocked this month," "which consignees hit a sanctions match" — turning natural language into SQL over the live decision store.

• Everything was validated against hand-labeled products — including deliberately nasty edge cases — that Mohsin labeled from real shipments he's handled at Omi. He worked async (9.5 hours ahead), encoding carrier and dangerous-goods rules into our files and spot-checking our outputs while we built in New York; his corrections became our test cases.

Challenges we ran into

The knowledge doesn't want to be structured. Carrier lithium policies are published as marketing-adjacent PDFs, IATA's rules are largely paywalled, and the ground truth is spread across documents that casually contradict each other. Turning "DHL's 2026 lithium guide, page 14, footnote" into an executable rule with a citation is slow, careful, unglamorous work — and it's exactly where the product's value lives.

Fighting the LLM's helpfulness. The models wanted to answer. Getting the planner to say "I need the watt-hour rating before I can make this determination" instead of confidently inventing one took more prompt iteration than any other component. Caution is a feature; we had to build it deliberately.

Our first version solved the wrong problem. We initially built a gatekeeper — one shipment in, APPROVE / BLOCK / ESCALATE out — and it worked, but a verdict alone doesn't tell an operator how to actually ship. So we built the feasibility matrix on top of it: the same deterministic engine, now enumerating the entire carrier × country option space instead of judging one lane. The gatekeeper became the foundation; the matrix became the answer.

Latency on stage. Three models, live citations, dozens of matrix cells. We kept the what-if interactions (drag the state-of-charge slider, watch columns flip red) under half a second by making them pure rule-engine re-evaluations — no model in the loop — and kept the LLM work at the edges where reading is genuinely required.

What we learned

• Verdicts are cheap; options are valuable. The difference between "blocked" and "blocked here, open there, conditional if you do X" is the difference between a demo and a tool an operations team would fight to keep.
• Determinism and intelligence aren't rivals. The most trustworthy system we could build wasn't the smartest model — it was a modest set of models wrapped around rules a human can read, audit, and correct. LLMs propose; code disposes.
• Verification changes what you're allowed to claim. Because every claim carries a citation and an independent model has checked that the citation says what we claim, we can put this in front of someone whose job is on the line. That's a different product category than a chatbot.
• Domain pain is a superpower. Our hard test cases came from real shipments that went sideways — Mohsin's at Omi, and problems other operators described hitting. You can't Google that dataset; someone has to have lived it.

What's next

• Precedent memory — store every human correction ("German customs asked for a CE declaration on this lane") as a validated precedent keyed on (product family, carrier, lane) and overlay it on future matrices, with precedents that expire when the rule they depend on changes.
• Deeper carrier coverage from source guides (each carrier is a YAML file, not an engineering project), plus ocean-freight rules and automated re-ingestion when carriers publish updates.
• Real tariff-table integration for landed cost via a duty API across all destinations.
• Wiring the matrix into fulfillment platforms, so "can we sell to Brazil?" is answered before the checkout button ever renders.

Built With

• craft
• deepseek
• emergence
• fastapi
• llama
• llm
• mcp
• nebius
• neon
• next.js
• openai-api
• postgresql
• pydantic
• pypdf
• python
• qwen
• react
• rest-api
• server-sent-events
• sha-256
• tailwindcss
• trade.gov
• typescript
• uvicorn