
In factories, a new technician learns a procedure like lockout/tagout by shadowing a senior expert. That expert's time is scarce, and a skipped step can mean injury. Ghost Expert clones the expert. 1. Author: the expert films the procedure once while narrating. Whisper transcribes the narration, SigLIP finds scene changes, and Gemma 3 groups the segments into steps, each with an instruction, a visual check, a safety flag and a common mistake. The expert fixes anything in a simple editor and approves. No coding. 2. Coach: the trainee points a camera at the work area. A fast tier (SigLIP embeddings) tracks which step they seem to be on every frame. A slow tier (Gemma 3 vision on vLLM) verifies steps on 4 recent frames and returns strict JSON. A deterministic rule engine owns the state: a step counts as done only when Gemma confirms it, and before accusing anyone it re-checks skipped steps. Skip a safety-critical step and the screen turns red, a voice says what was missed, and the expert's own clip of that step loops until it is done. Minor slips get a hint. If the model is unsure, it asks instead of accusing. 3. Ask: the trainee holds a button and asks out loud ("where does the new filter go?"). Gemma answers in two sentences, grounded in the procedure and the expert's narration, and plays the relevant expert clip. 4. Record: at the end, a printable training record shows the verdict, trainee vs expert time per step, the mistakes caught and the questions asked, for the training or EHS manager. Coaching works in English and Italian, with the voice from Kokoro TTS. Everything runs on a single AMD Instinct GPU on ROCm: Gemma 3, SigLIP, Whisper and Kokoro together, with a live benchmark strip showing VRAM, frames/s and Gemma latency. Frames are never stored: a coach, not surveillance. Who benefits: trainees get a patient expert at their side, experts teach once instead of per hire, and plants catch mistakes before they cause harm.
18 Oct 2026

Double-Blind is a dark factory for the pocketful track (a Venmo-style wallet and payments service), built on BAND with five OpenCode seats served through Featherless. After the task is dispatched, no human directs any step. The idea is to specify the service twice, blind. The Builder implements the service from the written requirements. The Second Reader, on a different model family and unable to see the Builder's work, reads the same requirements and builds an executable conformance kit, a reference for how the service should behave. Because the two models differ, their misreadings fail independently. A Referee then compares the two mechanically. Every disagreement is either a defect in one side or a gap in the requirements. The Lead settles each one by quoting the specification word for word and keeps an ambiguity ledger, so rulings trace to the text rather than to opinion. A Surface seat writes the user-facing layer. Neither side is presumed right. That matters most where money must never be created, destroyed or spent twice, because a single confident misreading is the likeliest way to break that guarantee. Mandates are generic, with no track-specific detail. FACTORY.md documents the seats, the design choices, what failed and what it cost. Each seat commits under its own git identity, so authorship of the work is auditable.
6 Oct 2026

Software teams spend most of their time reading code — about 58% of it (Xia et al., TSE 2018) — and almost all of our tooling measures the wrong side of that. We count tokens, lines and cyclomatic complexity: over 120 readability metrics have been proposed and Scalabrino et al. showed they fail to track human judgement. The newest idea, asking an LLM "is this readable?", is worse: CoReEval found the model's ratings correlate with humans at roughly ρ ≈ 0. Opinions, all the way down. **The insight: don't ask, check.** Predict what the function returns, then run it. A wrong prediction is not a style complaint — the code genuinely misled a reader. Five readers who disagree with each other are five readings of the same source, and the executing program decides who was right. **Pipeline.** Rashomon picks functions from a diff or by git churn, generates probe inputs from each signature, and executes them in a subprocess with a timeout to record ground truth. Five independent readers — `careful-stylist`, `speed-reader`, `regex-allergic`, `api-historian`, `edge-case-hunter` — see only the source and the inputs, never the outputs, and each returns a prediction per probe. Every prediction is graded against execution-derived rules, with abstentions counted as wrong. Separately, `git log` plus a source-diff filter counts how often each function has actually been fixed. The result is a misread rate, a disagreement count and a bug-fix history for every function. **Users.** Developers and reviewers, especially teams whose code is edited by AI agents: an agent's rewrite that is easier for five readers to predict is a rewrite that is easier for the next human *and* the next model to maintain. **How it is used.** In Bob, mode `rashomon` runs the skill that fans out the five readers as isolated subagents. `make gate` turns a run into a non-blocking PR comment that fails only when a function gets more confusing. Mode `clarifier` rewrites one confusing function, and `equiv` proves the copy behaves identically before the new reading is measured. The static leaderboard ranks functions by misread rate and overlays bug-fix counts. **Novelty.** CRUXEval uses code to grade models; Rashomon inverts it: independent readers, ground truth, disagreement metric — a lab study turned into a CI check that runs on every pull request. **Measured results (bundled demo, recorded session).** 9 functions, 5 readers, 135 graded predictions, 21 wrong (16%). `parse_duration` was misread by 7 of 15 readers (47%) while `mean` was read by all 5 — the ranking separates the confusing code from the clear code with no human label anywhere. **Live run on `boltons` (30 functions).** Five independent `gemini-3.5-flash-lite` readers, 410 graded predictions: 9 functions are *Consensus misread* (every reader wrong), 4 *Scattered* (readers disagree), 17 *Clear* (all readers clean). Side-effecting APIs like `iteritems` are misread 100% of the time. Misread rate correlates with real bug-fix history — Spearman ρ = 0.394, p = 0.031, 95% CI [0.03, 0.71] — so the score tracks maintenance pain, not style opinions.
27 Sep 2026

When a kitchen runs out of a dish, the news travels by shouting. Servers keep selling it, so do the delivery apps — refunds, comped meals, angry reviews. Cooks can't tap screens with gloved or greasy hands, and kitchens are too loud for ordinary voice assistants. 86 It is a headset voice station for the line, built end-to-end on the AssemblyAI Voice Agent API. A cook says "86 salmon" and the salmon greys out on the kitchen display, the servers' screen and the online ordering page at the same moment. "Fire 12" / "Bump 4" / "Hold 9" move tickets. "How long on 7?" gets a one-second spoken answer. "Two short rib left" updates the count everywhere. Dangerous actions confirm first ("Void 7?" → "yes"), unknown items get "Which item?" instead of a guess, and kitchen chatter gets silence — a "dash" prompt rule plus a silent-reply gate keep the agent quiet unless a real command is heard. Technically: the browser streams audio straight to AssemblyAI over a single WebSocket (STT + LLM + TTS in one connection), sending prompt, 10 client tools, keyterms and voice focus inline in session.update — so config lives in git and applies on the next session. JSON-Schema enums keep the model on the real menu, keyterms cover kitchen slang, near-field voice focus isolates the cook, min_latency transcription and 1-5 word replies keep it fast. session.resume survives Wi-Fi blips, reply.create powers proactive late-ticket alerts, and a Worker mints temporary tokens so the API key never reaches the browser. State lives in a Cloudflare Durable Object that broadcasts to every screen. Eval: 43 clips (31 commands + 12 chatter) — 96.8% command accuracy, 12/12 chatter ignored, zero spoken false triggers, in clean air and under noise. 15 unit tests pass. Live demo: https://86-it.rd5510.workers.dev/station
30 Sep 2026

A language-driven bimanual agent: two simulated SO-101 arms in MuJoCo set a dinner table from plain-English commands. Six tasks span bimanual behaviour: single-arm placements (fork, spoon, cup), a simultaneous dual-arm place, a hand-off where the right arm relays an out-of-reach fork to the left arm via a shared pad, and a multi-step full setting. Success requires every object within 3 cm of target and resting on the table, cutlery within 45° of target yaw, the cup within 30° of upright, and all arms released. The agent runs a closed loop. An overhead depth camera gives object poses (mean error 0.6 mm). Qwen3-1.7B, INT4 on OpenVINO GenAI, fills a JSON-schema form per object; a critic checks it against the command (28/29 plans correct). A scheduler groups steps into simultaneous two-arm phases; unplannable steps switch arms or become a hand-off. mink IK + OMPL execute each phase with each arm planned against the other, and the camera re-checks every step and re-plans failures. On 10 held-out randomized seeds per task the agent completes 56/60 (expert with ground-truth poses: 57/60), 56/60 on unseen wording, 49/60 under 1.5x randomization, 56/60 with objects knocked off mid-task, and 45/50 free-form "arm A / arm B" commands. The expert's 293 randomized demos (LeRobot v3) train SmolVLA on all six tasks and an ACT baseline; on a laptop budget both are undertrained (<= 3/60). Both export to OpenVINO IR, including the full 10-step SmolVLA sampler as one graph, with PyTorch parity of 4.8e-4 (ACT) and 3.2e-4 rad (SmolVLA). NNCF INT8 cuts ACT from 66 to 34 MB and 42 to 26 ms per chunk (1.6x) with placements within one episode of PyTorch. All timings are from an Apple M4; scripts/intel_quickstart.sh is built to reproduce everything on Core Ultra CPU, iGPU and NPU in one command.
16 Sep 2026