.png&w=256&q=75)
🤓 Latest Submissions
Sottovoce: lessons a blind child can follow
When a teacher in a lesson video says "look at this", a blind child is left out. Audio description fixes that, but it needs a trained describer, so fewer than 5 in 100 educational videos have it (DCMP survey). Sottovoce describes lesson videos for blind and low-vision children. It transcribes the teacher, finds every moment they point at the screen and pauses the lesson there. Gemma 4 on AMD Token Factory writes each line for the child's age (5-8, 8-13 or 14-18), in English or Italian, reading numbers and formulas exactly. Qwen3.8, a different model family, checks every claim against the frames, and only checked or teacher-approved lines are voiced. In two NASA lessons, 24 of 32 lines were longer than the teacher's pause, so the lesson waits instead of dropping them. With a false detail planted in every line, the checker caught 24 of 32 and never flagged a correct line. The models cost under a tenth of a cent per minute of lesson. The child can stop the lesson and ask about the picture by voice. The answer is checked before it is spoken, and if the picture can't answer, Sottovoce says so. Pressing M says where each thing is, panned left or right in stereo. Teachers can also just write to the desk, an Evolus agent on Gemma 4 on AMD. It reads the link, language and age, then starts the lesson through Sottovoce's own MCP connector or asks for what is missing. It answers questions about WCAG and the ADA from a knowledge library. When a lesson is done, it writes easy-read notes for the child and an Evolus AI Tool translates them for the family. The workspace runs two workflows, a sub-agent and the chat widget, and the app drives it through the Evolus API. Built with Google ADK (served over A2A), Google Cloud Text-to-Speech and Cloud Run. Live at sottovoce-ai.web.app.
18 Oct 2026
Coord: where nobody grades their own work
Anyone can get an AI agent to write code. The hard part is trusting what comes back. Coord is a four-seat software factory in BAND Desktop that turns trust into evidence. It built Tablekeeper, the restaurant-reservation track, from one human message, with no input after it. Coordinator turns each spec into a numbered requirements ledger (105 obligations for stage 1) and routes self-contained handoffs. Builder writes the code and never grades it. Verifier writes its own black-box tests from the spec without reading the code. Gate is the only seat that can accept: it rebuilds the exact commit, runs the organisers' checks in graded isolated mode, re-runs the tests itself, audits the ledger and the code, then plants bugs to test the tests. The mandates never name the product, so the factory can take any spec. What it caught: a valid booking with a field nested 1,000 levels deep crashed the server with a 500 while the shipped checks and 377 tests passed. Gate rejected it and Builder fixed the cause. Each fault-probe survivor became a new test. It found that the organisers' harness runs zero tests in graded mode on Windows, and when Docker froze it paused itself and resumed on its own. Results: all 4 stages accepted, each on an exact commit, in 5 h 19 m. 2,173 independent tests, full ledger coverage, 2 real rejections fixed, about $145 at list prices, 0 human messages after dispatch. Tablekeeper never double-books: a lost response is retried with the same key and returns the original booking, never a second one.
6 Oct 2026
Lishbor Trace: Green CI, Broken Requirement
Problem: A traceability matrix says which test proves each requirement. It stays green as long as that test passes, even when the test no longer checks what the requirement says. In August 2024, PyJWT, Python's most downloaded JWT library, merged a typing cleanup (#970) that changed isinstance(issuer, list) to isinstance(issuer, Sequence). A string is a Sequence, so a single expected issuer became a substring check. All 271 PyJWT tests passed, including the issuer test. The change sat on main for 101 days, shipped in 2.10.0 and became CVE-2024-53861. Solution: Lishbor Trace answers two questions on every merge request: would the tests notice if a requirement broke, and did this change break one? 1. Map: IBM Bob reads the specification (the RFC 7519 PDF) and maps each normative requirement to the implementing method and the test that claims to prove it, quoting the document. Lishbor accepts a mapping only if the quote appears word for word and the test passes. 2. Probe: parallel Bob tasks write, for each requirement, a witness test plus a realistic change that breaks it. Lishbor keeps a probe only if fresh checkouts show the witness passing on approved code and failing on the broken code. For PyJWT all eight probes held, every mapped test missed its probe's violation, and for five of the eight the entire suite still passed. 3. Review: on each merge request, Lishbor runs mapped tests, probes and the project suite on base and head. On the replayed #970, PyJWT's suite passes and Lishbor marks the issuer requirement violated. 4. Repair: Bob fixes the violation. Lishbor shows the patch only after a fresh checkout passes every probe, every mapped test and the full suite with no new skips. 5. Strengthen: Bob writes the regression test the project was missing. Lishbor keeps it only if it passes on approved code and fails on every probe mutant. PyJWT's new test fails on #970's commit: with it merged, the change behind the CVE could not have passed CI. Target users: teams shipping regulated or security-critical software who must show that each change was tested against its requirements (SOC 2 change management, IEC 62304, the EU Cyber Resilience Act). How they use it: paste a GitLab merge request URL into the web app, or run it as a CI gate that fails the pipeline on a requirement regression. The report shows the matrix, each requirement's evidence strength, Bob's verified repair and an audit manifest of commits, input hashes and Bob task IDs. What makes it unique: spec-driven tools write requirements first; test generators add tests. Lishbor aims every mutant at a quoted normative sentence, confirms it on fresh checkouts, and replays it as a gate on each merge request. Bob proposes; fresh checkouts decide. Efficiency: probes are written once per approved baseline and replayed free on every merge request. A verified repair or test costs about 0.2 Bobcoins, and the whole PyJWT scan and repair runs in 39 seconds on a laptop.
27 Sep 2026
