Each engagement is written up in full and shipped with its own public repo: the attack plan hashed and posted before a line of the target was read, the baseline, the planted-defect matrix, and the findings. Two kinds of entry: a blind read, where the code is read at one pinned commit against a plan hashed first, and a matrix run, where catalogue defects are planted into a clean checkout and the project's own suite is run against each. The label on each entry says which. You don't have to trust the story. Every one links out to proof you can hash yourself: the pre-registration, and confirm it predates the audit, or, for the one read that predates the protocol, the report as sent with its timestamp. These are the load-bearing proof behind the method. If you want the method itself, start with how to verify AI-generated code.
A static read of a self-hosted restaurant ordering and reservation system, 65 of its last 100 commits agent-authored. One route let any signed-in customer read any booking with the customer's name, email and phone. Reported privately; it was a duplicate of a report filed six weeks earlier, and the fix shipped in 0.3.1 the evening my email arrived. The three correctness gaps were new: the maintainer confirmed all three and opened them as issues. Not pre-registered, and the entry says so.
verify-006 · blind read · building fault detection / Rust + SQL + Python · maintainer-fixedA pre-registered blind read of a fault-detection platform that publishes its 62 rules in two "parity-matched" flavors. Two of the pairs answered the same rule id differently, in a tolerance and an occupancy threshold, both outside the project's own parity harness. Reported publicly at 18:47; the maintainer replied at 18:52, shipped the fix that evening in 3.3.41, and added both rules to the harness.
verify-005 · matrix run · data pipelines / Python · maintainer-confirmedA pre-registered blind pass on a "never lose data" sync engine, blind-to-published in a day. The suite caught 14 of 20 planted defects; the six escapes were test gaps, two of them silent re-breaks of bugs the project had already fixed. The maintainers reproduced all six with control mutations and corrected two of my severities upward. The fix existed; the fence didn't.
verify-004 · matrix run · booking / reservations · maintainer-fixedPre-registered blind pass on a Payload booking plugin. Its suite caught 11 of 13 planted defects, but the default standalone install left collection access wide open: any logged-in customer could read, change and delete every other customer's booking, and set another customer's password to log in as them. Reported privately; the maintainer fixed all three findings in v4.1.1 the same cycle, then audited himself and shipped 4.1.2, and closed a second batch in 4.1.3, one of them by configuration with the residual documented. The withheld exploit now ships as the regression test, green against the fix.
verify-003 · matrix run · payments / double-entry · EXEMPLARYA pre-registered blind pass on a Stripe→journal engine. 810/810 green, and a planted-defect matrix caught 14 of 16 injected money-bugs, including every balanced-but-wrong account mutation. The two escapes were one benign test gap, disclosed publicly and gratefully. Shipped code correct.
verify-002 · matrix run · agent authorization / Go · maintainer-confirmedHash-anchored blind pass on a Go policy guard. 7 of 11 planted defects caught: a suite that tests its core; the method found seams, not holes. The maintainers reproduced the reported raw-input matching gap (kontext#477), which is Trenyx's first maintainer confirmation.
verify-001 · matrix run · algorithmic trading / Python · 8 confirmed defectsPre-registered pass on an AI-built Python trading system. Its green suite caught only 5 of 11 planted money-bugs (lookahead, a mis-anchored trailing stop, an ignored kill switch), and eight real defects were confirmed and disclosed (issue #99).
Each engagement links to its own public repo: the attack plan hashed before any code was read, the baseline, the planted-defect matrix, and the findings. Apply a patch, run their suite, check the work yourself. The pace is set by disclosure, not by the calendar.
Before reading any implementation, I write the attack plan from the public README alone, hash it (SHA-256), and post the hash to a public timestamp. That external clock is the thing you verify: it proves the plan was fixed while I was still blind, so the findings can't have been reverse-engineered from whatever I happened to find. Every audit here hands you the hash and the command to check it. Nothing about the result rests on taking my word for the order of events.