.png&w=256&q=75)
🤓 Latest Submissions
T-24: Prove It Before the CRA Clock Runs Out
The problem. Since 11 September 2026, the EU Cyber Resilience Act (Article 14) requires every manufacturer selling software in the EU to send ENISA an early warning within 24 hours of learning that a vulnerability in their product is actively exploited, a notification within 72 hours, and a final report within 14 days. Missing these duties can cost €15 million or 2.5% of worldwide turnover. The clock starts before the hard question is answered: are we even affected? Dependency alerts name a library, not a code path. Engineers grep, read advisories, and argue for hours, and most alerts turn out to concern functions the product never calls. The result is either wasted emergency releases or, worse, a confident "not affected" that is wrong. The solution. T-24 turns that triage into minutes of evidence. An LLM reads the published advisory and extracts the vulnerable symbols. It never decides anything: any symbol not found word for word in the advisory is dropped, and version ranges always come from the published record. A deterministic engine decides the verdict. It checks the installed version, builds an AST call graph of the product from its real entry points, and scans the library's own source for internal callers. The output is an OpenVEX verdict per advisory, with the exact evidence path (file, line, function) or the exact reason it cannot be proven. For an actively exploited finding, T-24 starts the CRA clock and drafts the ENISA early warning and notification, citing file:line evidence in every claim, marked for human review. An IBM Bob custom mode and skill then write a failing regression test, apply the fix, prove the test passes, and rescan to mark the finding fixed, while the reporting clock keeps running, because the Act still requires the reports after a patch. Demo results. On a Flask service pinned to four real vulnerable libraries, one scan with a live model took 16 seconds (about 1 second replayed from cache): PyYAML CVE-2020-14343: affected, via app.py:14 upload_config to config.py:5 yaml.full_load. The regression test sends a real exploit payload; the vulnerable app returns "EXPLOITED-42", the fixed app rejects it. Pillow CVE-2023-50447 and Jinja2 CVE-2024-22195: not affected, proven. Two emergency releases avoided. requests CVE-2023-32681: under investigation, because requests calls the vulnerable function internally (sessions.py:245). Simply trusting the code path would have produced a false "not affected" here; the deterministic library-caller check caught it. Why it is trustworthy. "Not affected" requires every file to parse, no dynamic access such as getattr or importlib, no product path to the symbol, and no internal caller in the library. Otherwise T-24 says "under investigation" and shows why. We attacked our own engine with 19 adversarial projects; every false "not reached" became a test (166 tests in total). Impact. Security teams answer "are we affected?" with proof in seconds instead of hours, avoid needless emergency releases, and meet a legal 24-hour deadline with regulator-ready drafts backed by code evidence.
27 Sep 2026
Neuro-Genesis Engine
Neuro-Genesis Engine is a self-expanding Mixture-of-Experts network that autonomously repairs its own architecture, live, during training. Think of a hospital that hires its own specialists: when a patient shows up that nobody on staff can treat, the hospital doesn't wait for HR — it writes the job spec, interviews the candidate, verifies credentials, and puts them to work the same shift. Neuro-Genesis Engine does exactly that for a neural network. When training loss spikes — a sign the network hit something it can't handle — a local LLM, Gemma-2-2b-it, writes the actual PyTorch source code for a new expert module. That code is statically screened, sandboxed, smoke-tested, and hot-swapped into the live network without stopping training. If a candidate is rejected, the exact rejection reason is fed straight back to the model, which corrects its own mistake and retries. No human is involved at any point. This isn't a simulation or a toy demo. The system passes 44 tests, has been through three independent rounds of adversarial review, and survives a genuine OS-level Ctrl+C interrupt mid-registration with full checkpoint/resume. It's verified end-to-end on real AMD hardware — a Radeon Pro W7900D running ROCm 7.2 — with Gemma-2-2b-it running entirely on-device, no external API calls. Every long-lived model deployment eventually meets data it wasn't built for — perception systems drift, fraud patterns shift, edge devices see conditions nobody trained for. Today, fixing that means a human notices, a retrain gets scheduled, and a new version ships days or weeks later. Neuro-Genesis Engine is a step toward infrastructure that repairs a model's blind spots the moment they appear, instead of waiting on a human in the loop. A live, interactive visualizer replaying a real training run — showing the network growing from 4 to 11 experts across 7 spike-detect-generate-register cycles — is hosted at neuro-genesis-engine.vercel.app.
13 Jul 2026
BandWidth - The Autonomous Code-Review Crew
BandWidth is an autonomous code-review crew: five specialized AI agents that collaborate THROUGH Band to plan, review, fix, test, and document every GitHub pull request — and escalate to a human when they're genuinely stuck. The problem: code review is the most expensive recurring coordination tax in software. PRs stall waiting on a reviewer, context is scattered across diffs, CI logs, and chat, and the loop from "found a bug" to "fixed and verified" takes days. Teams don't lack tools — they lack coordination. When a developer opens a PR, a webhook spins up an isolated Band room and the crew goes to work. The Architect triages the change, drafts a plan, and seeds the room with the diff and full source. The Reviewer reasons over the code and issues a structured verdict, routing it to exactly one teammate. On a blocker, the Engineer rewrites the file and pushes a real fix commit to the branch, which retriggers the loop. On a pass, the Tester runs real pytest in a sandbox. Finally the Documenter — silent until the pipeline converges — synthesizes the whole room into a polished PR description. Band is the collaboration layer, not a notifier. Agents discover each other, hand off work by agent_id (one recipient, never a broadcast), share structured context through the room, and emit typed task-state events so coordination is a first-class, visible primitive. In strict mode the Reviewer and Engineer debate; when an attempt cap is reached the crew escalates to a human with a handover document instead of looping forever. Humans stay in the loop both ways — a reply on the PR flows into the room and the answer flows back to GitHub. It is cross-model by design: agents reason on different providers (Featherless/DeepSeek, AI/ML API/GPT-4o), all coordinated through Band — proof Band orchestrates across models, not one vendor's stack. Hours of human glue become minutes of autonomous, auditable collaboration.
19 Jun 2026
