Using a Git Orphan Branch and DuckDB for Scalable CI Code Audit Storage and Analysis

Built something that uses DuckDB in a way I have not seen elsewhere, and this felt like the right room for it. corral is a code auditing tool. It plants deliberate faults in your code, runs your own test suite against each one in a sandbox, and reports which faults your tests failed to catch. The interesting part for this channel is not the auditing — it is where the results live. CI runners are amnesiac. A runner boots, measures something about your code, and is destroyed. Whatever it learned dies with it, and the usual fix is to stand up a database: a server, a schema, credentials in CI, a bill, all to hold what is really an append-only list of small facts. So corral does not stand anything up. Every verdict is written as one gzipped JSON file and committed to an orphan git branch in the repository itself. An orphan branch shares no history with main, never appears in your diffs, and lives somewhere every CI runner already has credentials for. Then DuckDB reads it in place, straight off GitHub over HTTPS, with no clone and nothing running: import duckdb, json, urllib.request repo = "pdbethke/corralai" names = [f["name"] for f in json.load(urllib.request.urlopen( f"api.github.com/repos/{repo}/contents/scans?…")) if f["name"].endswith(".json.gz")] urls = [f"raw.githubusercontent.com/{repo}/…/{n}" for n in names] con = duckdb.connect(); con.execute("INSTALL httpfs; LOAD httpfs") print(con.sql(f"SELECT kind, count(*) FROM read_json_auto({urls!r}, union_by_name=true) GROUP BY 1")) That runs against our own record right now. 104 entries as I write this: 2 audits, 43 cold reviews by other models, and 59 rulings where a person confirmed or refuted what a reviewer claimed. Some findings are still open and the record says so. A git branch is a strange database and I want to be honest about the tradeoffs. It is append-only by construction, every entry carries the hash of the one before it, and a clean clone plus one command tells you whether the chain holds. It is also unindexed, and every query reads every file, so this works because the row counts are small and the entries are one per audit rather than one per event. If that stops being true the same rows push to a real warehouse, which is where MotherDuck comes in: one repository's branch is a record, and md: is the view across every repository that pushes to it. The push is the same verb either way, and the destination is a DSN: corral certify --repo . --push md:my_database -- pytest -q corral certify --repo . --push ./audits.duckdb -- pytest -q First push auto-creates the schema: corral_scans, corral_audits (one row per audited file), corral_mutants (one row per planted fault and its fate), corral_model_calls (tokens and latency per call), corral_events, plus corral_reviews, corral_findings and corral_adjudications for the review side. There is also a corral_seal view that cross-references a signed statement's hash against the rows it produced, so a row and the receipt it came from cannot quietly disagree. Rows are append-only. Overwriting is how a trend is lost, and a trend is the entire reason to keep them. The questions that need the warehouse are the ones a single run cannot answer. Which files keep shipping demonstrated gaps. Whether a kill rate moved or just resampled, since the faults are generated fresh each run and one number is a sample. How much of what changed could be audited at all, which is the honest denominator nobody prints. The one I did not expect to care about: the warehouse is how the models get graded. corral models rank reads those rows back and ranks each seat by its own metric — a test writer by proven catches over survivors, a reviewer by claims that held of those checked, a verifier by verdicts that agreed with the outcome. Every number comes from execution or from a human ruling, never from a model's account of itself. It is a leaderboard whose evidence is a table you can query, and it prints an insufficient-evidence marker rather than a rank when a seat has fewer than five observations. One real number, so this is not an abstract pitch. Pointed at pallets/flask yesterday, at app.py: 40 faults planted, flask's own suite run against each in a sandbox, 29 killed and 11 survived, and a second model then wrote a test that actually caught 10 of those 11. Kill rate 0.72. That entry is on the branch and the query above will return it. The signed statement also went to Sigstore's transparency log at index 2759598612, so the receipt is checkable against a log I do not run. v1.0.0-rc.13, Elastic-2.0, Go. Honest state of things: it is a release candidate, I am the only maintainer, and seven rounds of cold review found real bugs in it including two ways a CI gate could pass an audit that measured nothing. Those are fixed and the reviews are entries on that same public branch, which felt like the only defensible thing to do with them. corralai.dev github.com/pdbethke/corralai Happy to talk about the branch-as-storage idea specifically. I am not certain it is a good idea at scale and would genuinely like to hear where it breaks.