.png&w=256&q=75)
🤓 Latest Submissions
ShelfCast: AI demand planner on AMD MI300X
Problem: every week a store decides how many of each product to order. Replenishment systems extrapolate recent sales and cannot see a holiday, a promotion or what the manager knows, so planners patch numbers by hand. The cost is empty shelves and waste. ShelfCast is an AI demand planner that turns a forecast into the right order. It (1) computes a statistical baseline with calibrated quantiles; (2) builds an evidence brief: past event and promotion effects measured against that baseline and kept only if they clear the product's own noise, price moves, a classical uplift model and any free-text planner note; (3) asks an open LLM (Qwen3-30B-A3B, vLLM on ROCm, one AMD Instinct MI300X) for five judgments in one request under a JSON schema, each naming its drivers; (4) guards, recalibrates and orders the cost-optimal quantile (newsvendor). The LLM is never the only forecasting method. Results from the full MI300X run (2,600 backtest forecasts, each made only from the past): - Real Walmart sales (M5, 60 products, 26 weeks): inventory cost -8.0% from ordering the cost-optimal quantile; 90.1% of outcomes inside the 90% range. On these anonymised items the model's net effect is within 0.6% of the baseline (its guard blocked 92 of 389 changes). We report this openly: it is why the LLM is a judgment layer, not the forecaster. - Planner notes (synthetic store): in weeks with a free-text note, 19.4% more accurate than the baseline, 17.6% more than a no-LLM rule with the same evidence, inventory cost -21.9%. AMD: 256 forecasts a minute on one MI300X (4,722 output tokens/s, 100% valid JSON), $0.19 per 1,000 forecasts. Open weights on the retailer's own GPU: sales data never leaves. Demo: yy5652-hash.github.io/shelfcast · Code (MIT): github.com/yy5652-hash/shelfcast
18 Oct 2026
.png&w=828&q=75)
ChipQC Guardian: Citation-Exact RAG on ROCm
ChipQC Guardian is a containerised retrieval-augmented question-answering system for Match 3, built on the mandated rocm/pytorch base with all weights shipped inside the image, so nothing is downloaded at evaluation. Pointed at a folder of mixed enterprise documents (PDF datasheets including withdrawn revisions, DOCX roadmaps with tables, XLSX part lists, CSV ticket databases, production logs, release notes, Python source, diagrams and photos) it indexes everything once, then answers each question with the bare value and the exact set of files the value came from. On AMD Instinct GPUs a resident server holds Qwen3-VL-8B-Instruct (bf16) and Qwen3-Embedding-0.6B behind a unix socket, so each per-question invocation is a thin client that returns in seconds and never loads a model. Ingestion is defensive: an empty directory, an unreadable file, an encrypted PDF and an unknown binary are skipped per file without stopping the walk. Spreadsheets and CSVs are indexed row by row with their headers so a ticket id lands on the row carrying its value; Python files contribute their constants and parameter defaults; images and image-only PDF pages are transcribed by the vision model at index time and re-read from the image at answer time. Retrieval fuses identifier-aware BM25 with dense embeddings, and a second hop follows identifiers the model asks for, which is what makes log, ticket and fixed-in-version chains answerable. Citations are filtered for necessity rather than relevance: withdrawn or superseded documents are dropped, chain links are kept only with directional evidence (a shared ticket, part or error identifier plus the question pointing at that document), redundant sources are reduced to one primary source, and a verification pass rejects values that belong to a different item. When the value is not in any excerpt the system returns an empty answer and no citations. It never guesses.
1 Dec 2026
Nightwatch Foundry: a four-seat dark factory
Nightwatch Foundry is a dark factory built on BAND Desktop: four Codex seats share one room and turn a single human dispatch into working software, stage by stage, with no steering afterwards. The Foundry Coordinator plans each stage, splits ownership and sends the complete specification to the other seats as numbered handoff parts that must be acknowledged before work starts. The Systems Engineer owns integrity-critical behaviour: state, concurrency, idempotency and recovery. The Interface Engineer owns the HTTP surface, the browser product and presentation quality. The Independent Verifier works from a fresh clone, runs the official isolated harness and its own specification-derived probes, and may reject promotion; a stage is accepted only against an exact commit. In the scored run the factory completed all four tablekeeper stages in 10 h 39 min from one dispatch. The shipped checks pass on a fresh clone: 120/120, 25/25, 7/7 and 6/6. Review was real: the verifier rejected candidates six times and withdrew its own acceptance twice while the official checks were already passing, and every time a builder changed the code. The band made 381 commits across all four seats and used about 662 million tokens. The four mandates are generic: they describe ownership, handoffs, evidence and rejection rules and name no endpoint, field or error code. FACTORY.md documents setup, design choices and their cost, what failed (Stage 1 took five hours because nothing ranked the verifier's findings) and the revised mandates we would run next. The repository holds the mandates, the unedited room export, one buildable folder per stage and the band's evidence.
6 Oct 2026
