Supply-chain operations and applied AI, ranked by proof

Claude scored 680 postings against my written rubric in October. Only a job confirmed open on the employer’s own site is published: on the day that rule shipped, the check found 7 of 9 known-live postings and opened none of 5 known-closed ones. A cheaper model ran beside it for a week, agreed on 92% of its calls, and dropped 12 of the 34 postings the stronger one kept, so the stronger one stayed.

Every morning it searches job sources for the supply-chain and applied-AI roles I target, and Claude scores each posting against my written rubric. Only a job confirmed open on the employer's own site reaches the public board, and its card opens that posting. Every score is remembered, so no posting is paid for twice, and a guessed score is marked and never published. Each week my verdicts on the private desk teach the scorer what I turned down.

A fingerprinted pack of my build rules loads into the platform’s own agent, so every app it builds starts from my template and my checks. Its self-test refused 13 of 13 planted faults. On a real rebuild, all 26 shared files matched the pack byte for byte and 23 guards passed. My scheduled tasks there ran as the platform’s own agent.

Given a vague answer to “what counts as done?”, a planning step demanded a checkable finish in 7 of 9 runs with one instruction, against 1 of 9 with it removed (one-sided Fisher p = 0.008). The same instruction asked for a giving-up point in 6 of 9 runs, against 0 of 9 for the old wording. A control input that should not move drew 0 of 3.

A cheaper model tied the stronger one on two benchmark tests, so my search helpers moved to it. In real use its answers fully held 21 of 47 times, against 73 of 95 before. I moved them back and accepted about three times the usage per search.

A change-order tracker read engineering PDFs with a chat model, and a planner cannot see what a model misread. I had that reader replaced with the rule-based one my other change-order tools share. It re-read all 10 change orders to the same 419 lines the old app held, and a checker holds each order to its PDF line for line.

One of the agents produces and publishes my podcast. A week’s trial cut their cost per turn from $0.137 to $0.079, before both moved to a smaller model on their own capped keys. Their acceptance suite passed 340 of 340, and a judge model’s scores count only after it rates an empty answer low and a reference answer high.

An always-on agents box running autonomous Claude agents: a coding agent that answers task issues with pull requests, a Telegram personal assistant that also produces the podcast AI From the Floor, and a shared runtime with its own verify harness — work continues while the operator sleeps.

Both effort levels passed 33 of 33 errands. The lower one cost $0.0030 a run against $0.0033 and finished in 12 seconds against 14, so the assistants run at the lower one.

A small team of named AI assistants sharing one always-on computer: one browser, a terminal and files. I reach them from my phone or my PC, and they run errands on the web, keep files and carry checked copies of my career record. A bot that wants to change its copy of that record asks me, and never edits it. A runner watches the computer's memory and closes the longest-idle browser tab before the container runs out of room.

On the build that planned its own write-up, handing off to a fresh session read 113.0 million tokens against 165.5 million kept in the planning window: 31.7% fewer, in one measured session.

A Claude Code kit that turns three of Anthropic's published practices into rules the harness enforces: plan before building, let Claude interview you, and build the spec in a fresh session. A plan cannot leave plan mode until the person seals its statement of intent, and every decision reaches them as a real choice. It is a lighter cut of the setup I run every day. A walk-away build is refused unless the fresh session opens with a goal that grades it.

One of 12 founding members of the manufacturer’s AI champions group, and one of 14 on its global supply-chain AI team, the only one from a plant. I teach with working tools: my October session closed on one container followed through the Container Tracker below.

On a held-out week it never saw, it flagged 98.7% of the next week’s misses, and 87.3% of its top-63 worklist was right. Materials that simply keep failing account for 66% on their own, and that floor is reported rather than credited to the model. A question panel answers in plain English by having Claude call the engine’s own tools.

Genuinely-predictive order-confirmation analytics: forecasts which materials will miss confirmation next week, splits the at-risk book into recoverable vs structural, and hands the operator the specific lever to pull. Backtested across a run of historical weekly snapshots and validated on a held-out week.

Open it now: a fictional manufacturer and synthetic data. Its Ask tab has Claude answer by calling the forecaster’s own tools, and the same tools serve other AI clients over MCP. A 42-check gate fails the build if the engine cannot recover the pattern planted in the data.

Supply-chain order-confirmation risk service, built end to end: risk as a conditional probability table measured from week-to-week transition history, served over an API and an MCP server, with a React operator console on top. Fictional company, synthetic data.

Open it now. It runs on 160,000 repair jobs I invented over three years, so it shows the method and never a result. Every method learns from the history before the last 92 days and is scored on those days as if they had not happened yet. Every gain carries a control built to take it away: shuffled history drops the parts predictor back to the national top-parts list, shuffled technician skills drop the dispatch rule below the one that ignores skills, and shuffled AI answers lose the AI step’s gain. Each check plants a fault it must catch, and one clones the public repository fresh and runs everything there.

It opens on the next day’s plan: which technician takes each call, what each truck loads tonight, and a to-do list for each team. For a booked repair, it ranks the likely parts by counting what fixed past jobs at three levels: the same model family and problem, the product type and problem, then the product type alone, so a new model with thin history leans on the wider group. Each night it loads every truck from tomorrow’s calls, keeping a part only while the second visits it saves outweigh the cost of moving and holding it. Each part on a list is marked as aboard, overnight from a distribution center, on a truck nearby, back-ordered, or locked to a certified technician. Claude Haiku 5.5 turns the customer’s own words into a problem code with a confidence, and asks one follow-up question when it is unsure. Dispatch replays every held-back day with sick calls and breakdowns, sending each call to the technician with the lowest expected cost of drive time, repair time and a second visit. Written in Python, SQL and JavaScript: 14 Python files invent the history, predict parts, load trucks, ask Claude, replay dispatch, write the pages and check it all; 10 SQL files hold the tables and the 9 metric queries; 2 JavaScript files run the hints and switches. Nothing is installed beyond Python.

It compares each forwarder report with the one before it, container by container, and scores the forwarder’s ETAs against real port arrivals: on 31 October 2026 they missed by a median of 5 days across 6 confirmed port calls. On its first platform an AI agent triggered the port read every three hours and reported whether the app answered. I presented it at an internal AI-adoption session.

Keeps every snapshot of an ocean-container shipping list and compares each new one with the one before it, container by container, recording a change whenever the ETA, vessel, arrival, delivery date, delivery location, shipment type or supplier moves, or a container appears or drops off. A snapshot arrives either by upload or as a spreadsheet attached to an email sent to the app, and both routes run the same pipeline. People subscribe to the containers, vessels or kinds of change they care about and receive an email listing only the changes that match.

The bill of materials decides scope, not the document: one 183-line, 28-page change table resolved to the 25 purchased parts it actually moves. It was tested on 7 real change orders. Its sibling tracker dropped a chat-model PDF reader for the one rule-based reader all three change-order tools share.

Turns one engineering change order into the purchased materials it moves, tied to the finished products they feed. A change order names assemblies and configuration records while a planner buys parts, so the tool walks the bill of materials down from every material the order names until it reaches purchased parts, and takes the affected products from the BOM structure rather than from the document, showing the document's own list beside it as a cross-check. It also measures whether the change has already been carried out, and says so when zero purchased parts is the correct answer. Its test run breaks the engine nineteen ways, each one a defect made while building it, and fails if the suite does not notice.

Picks the cut-over day so the old part runs out with the least scrap, from the change order, the BOM explosion, the production plan and the stock. Its tests hold it to figures measured by hand before any code existed.

Computes feasible implementation windows per Change Order with binding constraints, stock projection, multi-CO conflict report, readiness deadlines.

Reproduces all 13 weekly totals of the report planners already trusted. Its test suite catches 10 of 10 deliberately planted engine faults, so a pass means something.

Puts demand against supply by model and ISO week from the two SAP APO exports for one location, on one grid that switches between demand, supply, the difference and the running balance that shows the week a model runs short; any cell opens the orders behind it. Every demand and supply row type is a switch showing its row count, and the four demand types that start switched off are the four the planners' existing report already leaves out, which was measured rather than assumed. A stored pair is shared with everyone who has the link, a private look reads two dropped files in the browser without saving them, and a test proves both paths agree byte for byte. It does not schedule, forecast or write back to SAP.

Its first run caught a discrepancy of more than 40,000 units within minutes, and it was rolled out across the plant. Its tests hold the engine to an independent Python recomputation.

Per-bin physical-inventory integrity checks: impossible quantities, offsetting errors that net believable, line-side overstaging. The demo runs on synthetic data; the tool it stands in for reads SAP bin-stock exports and hands a planner the materials worth walking to: stock in the wrong place, a bin that cannot be right, a line position that has not moved in two years, and a quantity falling fast enough to run out before the next delivery. That tool now runs as an Abacus.AI-hosted Next.js + Postgres app whose one analysis engine is shared by the page, a background file parser, the test suite and an independent Python recomputation, and it measures movement by adding up the falls between readings rather than subtracting the endpoints. A first version ran on Abacus.AI in June 2026.

Compares quantities per material per week, never order numbers, because SAP renumbers orders. 122 tests with 26 planted defects, and 11 real export pairs agree with an independent recomputation.

Week-over-week production-plan volatility tracker: separates real reschedules from MRP renumbering noise, attributes changes to planner vs system.

Its guards refused 142 agent tool calls in the week to 31 October 2026. In a controlled test, a planning step given a vague answer to “what counts as done?” demanded a checkable finish in 7 of 9 runs, against 1 of 9 with that instruction removed. 341 of 403 recorded kinds of mistake had not come back when audited on 11 September 2026.

The entire Claude Code home directory as a maintained, restorable build: session hooks, permission policy, the skill-library mount, the status line, sync scripts and a written migration runbook, auto-committed on a schedule and restored in a weekly rehearsal so the machine's AI setup survives any single computer. The substrate the Claude skeleton map renders.