🤓 Latest Submissions
Article 14 Gatekeeper
Since 11 September 2026, every manufacturer selling software with digital elements in the EU must report actively exploited vulnerabilities under Article 14 of the Cyber Resilience Act. The deadlines are fixed: an early warning within 24 hours, a notification within 72 hours, and a final report within 14 days of a fix being available. Getting it wrong costs up to €15 million or 2.5% of global turnover. Today this is a manual release chore spread across tools. Someone runs a scanner and gets dozens of advisories. They read each one to guess whether the product is really affected, and paste the findings into a spreadsheet. Then they draft reports in a Word template, while tracking the legal deadlines in a calendar. In our demo product (fattura-lite), 12 advisories came back before the fix and 5 touched code the product actually runs. Both CVE-2020-14343 (CRITICAL, pyyaml 5.3.1, reachable at config.py:8) and CVE-2018-18074 (HIGH, requests 2.19.1, reachable at gateway_client.py:9) were blocking. Every false alarm costs reviewer time, and every missed dependency or deadline is a compliance failure. Article 14 Gatekeeper turns that chore into a release gate: 1. A deterministic core builds a CycloneDX SBOM, pulls advisories from OSV.dev, and merges duplicate GHSA and PYSEC records by CVE. 2. It statically proves reachability, giving file:line evidence for every vulnerable symbol the product uses. 3. It emits OpenVEX: every "not affected" carries a justification. 4. Signals of exploitation, from CISA KEV or the manufacturer's own intake, start the Article 14 clocks and generate draft reports that follow the fields of Art. 14(2). 5. The gate returns PASS or BLOCK as an exit code, so it works in CI, in git hooks and inside the IDE. IBM Bob 2.0 is the operator. In the custom CRA Release Officer mode, Bob runs three subagents in parallel: one fixes the vulnerable code and dependencies, one maps advisories nobody has mapped yet to vulnerable symbols and writes a reviewed VEX justification, and one completes the regulatory drafts. A Bob hook refuses git tag while the gate says BLOCK. A Lessons Ledger records every gate run, and Bob turns causes that recur into rules, so the same class of mistake is not repeated. Impact on the demo product: - The release went from BLOCK to PASS: before the fix, 5 advisories were affected; after, the gate reports 6 advisories and 0 affected. - Time to resolution: about 5 minutes from Bob's first gate run to PASS and the release tag (timed run, bob_sessions/dabii_task05c_timed_take2.md). - Both due Article 14 drafts (early warning and notification) were completed with deadlines computed to the minute, and the 14-day final-report clock started at the fix. By hand, all 12 advisories must be read and every report typed. Limits: Python/pip only; static reachability; the drafts are for a responsible person to submit, not legal advice.
27 Sep 2026
Apparecchiato
"You say ""set the table and pour me some water."" Two simulated SO-101 arms work out between them who can reach what, hand the PLATE across when neither arm can do the whole job alone, lay the place setting, and pour. THE PROBLEM WITH THE OBVIOUS APPROACH One end-to-end VLA policy for a multi-step bimanual task is the obvious answer, and it is the one that fails quietly. A policy that memorises a table layout looks excellent on the scene it was tuned on and collapses when the plate moves four centimetres. With randomised mass, friction, scale, lighting and placement, a demo either generalises or it is theatre. So Apparecchiato draws a hard line. The model decides WHAT to do. Geometry decides WHETHER IT IS POSSIBLE. A validator sits on that boundary. HOW IT WORKS Speech goes through Speechmatics real-time transcription. A vision-language model -- compiled to OpenVINO IR at INT4, running on CPU here and selectable to iGPU or NPU -- reads the overhead camera and the instruction and emits a task graph: nodes, arm hints, dependencies. That graph is then checked against the world before anything moves. Plans that reference objects not on the table, pick cutlery from a drawer they never opened, place what was never picked, or pin an arm to a target outside its workspace are rejected with a specific reason. If the model returns something unparseable, a deterministic planner takes over and the fallback is recorded in the plan -- the demo does not die live, and it does not pretend the model succeeded when it did not. The scheduler then assigns arms under three constraints: reachability including approach clearance, grasp state (an arm holds one object; you cannot place what you are not holding), and shared-workspace safety (the two annuli overlap in a lens, and only one arm may be in it at a time -- except during a hand-off, where both belong there).
16 Sep 2026
