Continuous Correctness Audit — Session Live

Your CI goes red
until the promise holds.

A standing correctness audit on one component of your system. Findings arrive as tests that fail on your main — and keep failing until the fix lands.

┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐

proof audit — ci session FIG.0 · PRF-GATE-00 REV A

The build fails until the fix lands. Re-runs in your CI without us

└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

├── FIG.1 Public audit register — buger/jsonparser ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── PRF-REG-01 REV A ──┤

First public audit: jsonparser.

A Go JSON library with a decade of production use. Every number below links to a re-runnable artifact — including the one we got wrong.

Approved
requirements

Real bugs
found

Published
miss

Checks in
the gate

LIVE REGISTER → portal.reqproof.com/projects/jsonparser

├── FIG.2 The-Gate / 01 ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── PRF-GATE-01 REV A ──┤

A finding is a failing build.

Most audits end as a PDF. Ours ends as a gate in your pipeline: every finding ships with a reproducer test pinned to your main branch, and the audit re-runs on every commit. Nothing closes on assertion — only on evidence.

Contrast Unlike a code review, a finding here arrives as a test that fails on your main — and keeps failing until the fix lands.

H-01Silent data lossNamed · Reproduced · Pinned
H-02Panic classesNamed · Reproduced · Pinned
H-03Contract driftNamed · Reproduced · Pinned
H-04Unverified requirementsFormalized · Gated

├── FIG.3 Evidence / 02 ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── PRF-EVID-02 REV A ──┤

Evidence lives in your repo.

Specs, hazards, findings, coverage — checked in next to the code they govern. When we leave, the audit stays. When you doubt a claim, you re-run it.

E.1

Requirements as artifacts

123 approved requirements on jsonparser, each with per-requirement hazard analysis. Not a wiki — files under version control, reviewed like code.

E.2

Findings as failing tests

7 real bugs found, including one panic class reachable from 8 call sites. Each finding is signed by a named reviewer and lands as a reproducer that is red on main.

E.3

Coverage you can dispute

MC/DC — the avionics coverage bar — on every scoped decision. If a decision isn’t exercised in both directions, the gate says so.

jsonparser — audit tree READ-ONLY

jsonparser/
├── specs/
│   ├── system/requirements/      123 approved
│   └── hazards/                  per-requirement analysis
├── evidence/
│   ├── findings/
│   │   ├── F-001_panic_class_test.go   8 call sites
│   │   ├── F-002_contract_drift_test.go
│   │   └── F-003_reproducer_test.go    RED on main
│   └── coverage/mcdc/            every scoped decision
└── postmortem/
    └── MISS-001_set_data_loss.md   published · re-runnable

├── FIG.4 Failure disclosure — MISS-001 ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── PRF-MISS-01 REV B ──┤

MISS-001 · SELF-REPORTED

The miss we published.

A silent data-loss defect in Set() escaped our jsonparser audit — with 100% MC/DC on the affected code. The coverage bar was met. The bug got through anyway.

We wrote the postmortem, made it re-runnable, and put it on the public register next to the wins. An audit that only reports successes is unfalsifiable — which is another word for useless.

DefectSilent data loss in Set()

Coverage at escape100% MC/DC on affected code

Detected byPost-audit review, not the gate

DispositionPostmortem published · re-runnable

Registerportal.reqproof.com/projects/jsonparser

├── FIG.5 Method / 03 ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── PRF-MTHD-03 REV A ──┤

Flight-software discipline. Ordinary CI.

The techniques are decades old and boringly effective. What’s new is installing them as a standing gate in an ordinary CI pipeline — in eleven languages, Go, Rust, Solidity and Zig among them.

M.1 — Requirements

FRETish requirements language

Requirements written in FRETish — a structured natural language with NASA flight-software lineage. Precise enough to hand to a model checker, readable enough to hand to your team.

M.2 — Verification

Formal verification: Kind2 + Z3

Every formalized requirement is checked for realizability, consistency and vacuity with the Kind2 model checker and the Z3 SMT solver. Contradictions surface before code does.

M.3 — Coverage

MC/DC — the avionics bar

Modified condition/decision coverage on every scoped decision. Not line coverage, not branch coverage — the standard certification authorities demand for flight software.

M.4 — Hazards

Per-requirement hazard analysis

Each requirement carries its own hazard analysis: what breaks if this is violated, how it fails silently, which call sites are exposed. The panic class at 8 call sites came from exactly this.

Security firms audit whether your software can be broken into.
We audit whether it works.

46%vs33%

Developers who distrust the accuracy of AI output, versus those who trust it.

Stack Overflow Developer Survey · 2025

90%→30%

AI adoption among teams — while 30% report little or no trust in the generated code they ship.

DORA Report · 2025

├── FIG.6 Engagement / 04 ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── PRF-ENGT-04 REV A ──┤

Fixed fee. Four weeks. Then standing.

We don’t audit everything — we audit the component where being wrong is expensive, and we leave behind machinery that keeps auditing it.

STEP 01

Scope

Confidential

You name the component where correctness matters most. We agree on the requirement surface and a fixed fee. No meters, no scope creep.

STEP 02

Install

~4 weeks

We formalize requirements in FRETish, verify them with Kind2 + Z3, build the hazard analyses, and wire the 52-check audit gate into your CI.

STEP 03

Standing audit

Continuous

The audit re-runs on every commit — without us in the loop. Findings arrive as failing tests, signed by a named reviewer.

REQ-SCOPE · INTAKE

Request confidential scoping

Tell us where correctness is costing you sleep. We’ll come back with a scoped requirement surface and a fixed price.

Fixed fee, agreed before work starts
One component, precisely scoped
Findings signed by a named reviewer
Gate stays in your CI after we leave

Your CI goes reduntil the promise holds.