Continuous Correctness Audit
We audit whether your software does what you promised.
A Continuous Correctness Audit is a standing engagement against a written bar. We formalize the requirements for one component you choose with us, your engineers approve them, and we prove and test the code against every approved clause. The findings, the proofs and the audit gate stay in your repo, where your CI re-runs them on every release. The claim is bounded on purpose: within a declared scope, for declared behaviors, with evidence commensurate with the consequence of failure.
Every finding is signed by name, so we take a limited number of engagements each quarter. Scoping requests go through the form at the end of this page.
How it's bought.
01 · fixed fee
The install
One component, chosen with you; a fixed fee quoted before work starts. Roughly four weeks from requirements approval to a gate in your CI, re-verification of your fixes included. Everything it produces is yours, whether or not you continue.
02 · monthly, flat
The standing audit
After the install, the audit that doesn't expire: re-runs on the cadence you choose, per release, weekly, even daily. Each quarter, one more component comes under the bar, install-grade, sized into the retainer at scoping. § 4 is what a month buys.
03 · optional
Fix sprints
Every register entry ships an agent-ready prompt with the reproducer as the finish line; your engineers or your coding agents can burn the queue down. When you want it done for you: fix sprints, scoped and priced separately, delivered as pull requests your engineers review and merge. The gate grades every fix.
One rule holds across all three. Fix work is never bundled into the audit fee, so the audit's economics never depend on how much fixing it finds, and the party grading a fix has no stake in having written it. The audit reads your code; it does not write it. Only fix work writes, and only through pull requests you accept.
Four weeks to stand it up.
Week one · Requirements the owners approve
We index the component first: the code, as the source of truth for what it actually does. Then its history, and the systems where intent lives: the issue tracker, the support queue, the docs nobody updated. Code knows what it does; it doesn't know why. The why is what we recover, and the engineers who own the component approve every requirement before any code is judged, about two hours of their time, because the drafting is ours. In our first engagement the approval step alone surfaced seven undocumented design decisions the team itself disagreed about.
Week two · Formalize and prove
Approved requirements become formal properties. We check the spec itself first, for realizability, consistency and vacuity, so a bad clause cannot condemn good code. Then proofs and coverage runs begin.
Week three · Gap analysis and findings
Where the code and the approved requirements disagree, we write it up. Every finding ships under the reproducer guarantee in § 8, or it does not ship.
Week four · The gate goes live
The evidence corpus lands in your repo and the audit gate wires into your CI. We walk your team through every finding and every proof. That is the end of the install, not of the audit.
Then it runs.
The four weeks are the expensive part: intent recovered, requirements approved, proofs built, the gate wired. What they buy is a corpus that makes every audit after them fast. From week five the audit runs on the cadence you choose, per release, weekly, even daily: new and changed code held to the approved requirements, new behavior formalized into new clauses, every break a finding with a runnable reproducer, the register current for anyone who asks what is open.
Most engagements continue past the install; it is priced as the expensive part precisely because everything after it is flat and compounding.
The gate re-runs mechanically on every merge regardless. The cadence you buy is how often an auditor reads what changed, extends the bar, and re-judges severities. Month twelve checks strictly more than month one. Life after the audit shows what a year of that looks like.
What stays behind.
your-repo/ ├── specs/ │ └── <component>.req.yaml ← approved by your engineers ├── src/… ← // SW-REQ-XXX ├── tests/… ← // Verifies: SW-REQ-XXX └── evidence/ ├── findings/F-XXX_test.go ← fails on main until fixed └── formal/<component>.log
A file tree in your repo, not a PDF in your inbox: reproducers, regression pins, condition-level MC/DC, formal checks on the requirements, plain YAML and executable tests. The dashboard is a window over that corpus; the record itself stays in your git. Prefer no hosted portal? The same views ship as generated static reports. The shape is the same as the public reference: homepage walkthrough · jsonparser dashboard.
What changes after week four.
After week four, the register does the work. Known issues become scheduled fixes the gate grades: your engineers, your coding agents working from the attached prompts, or our fix sprints when you want the queue off your plate. When a customer reports a bug, you check the register before you open a debugger. And when a defect does slip through, we widen the bar so its whole class cannot slip through again. The full picture, month two to month twelve →
Security promises are promises.
Half of what a component promises is negative space: nobody but the account owner can read this record; malformed input cannot take the parser down; a crafted string reaches the database as data, never as a query. A break-in is what it looks like when a promise in that half fails. So we audit that half the same way we audit the rest. Attack classes named at scoping become written obligations, and each one ends in a test that shows the attack failing on your tree, or a finding with a runnable reproducer that shows it succeeding. The selection is never a framework checklist run at you: every requirement gets its own worst-case analysis, and the catalog grows classes specific to your application as we learn it. The review is white-box: full source, full history. Our public register carries this in practice: severity-scored memory-safety findings on jsonparser, reproducers attached, live.
Five commitments, in the contract.
- Reproducer guarantee. Runnable or it does not ship. Every finding arrives with a reproducer that fails on your current main and the name of the reviewer who validated it.
- Severity escalation. A finding we assess at our highest severity reaches your named contact within one business day of validation. It does not wait for the weekly report.
- Regression guarantee. Every fixed defect becomes a regression test in your CI. If the defect returns, your build fails before anyone has to remember it existed.
- Bounded claims, in writing. The scope, the behaviors and the depth of evidence are written into the contract. We sign what we checked and nothing beyond it.
- Zero lock-in. The gate runs without us. The corpus is plain YAML and executable tests in your git. If you cancel, everything that runs stays yours; what ends is our ongoing involvement.
What we will not claim.
- This is not a certified penetration test, and it does not satisfy a compliance requirement for one. Security promises inside the scoped component are audited like any other; black-box red-teaming, infrastructure testing, and social engineering stay with the security firms.
- Dependencies are held to their declared contracts. Auditing a dependency's internals is its own scope, quoted separately when you need it.
- This does not replace static analysis. Pattern scanners catch known bug shapes cheaply; keep them running. We audit against requirements the owners approved, which no scanner has read.
- We will not claim total correctness. No audit can. Our signature covers the declared scope and declared behaviors at the stated depth of evidence, and it stops there.
- Performance is out of scope. Throughput, latency and capacity belong with your performance engineers.
- Severity labels are ours: our assessment, weighted by reachability and impact; a starting point for your triage, not a CVSS determination.
The longer table of what this audit cannot see is on the methodology page.
Before the form.
Worth your time if
- You can already name the component. Most readers who get this far can.
- A failure in it costs money or trust you can put a story to.
- Your release process is settled enough to host a gate.
- The engineers who own the component will give week one about two hours.
Not a fit if
- You need a certified penetration test or a compliance checkbox alone — we will say so at scoping and point you to a security firm.
- There is no owner who can approve requirements for the component.
- You want total-correctness guarantees; no audit can sell those, including this one.
Today we audit Go, Rust, JavaScript, TypeScript, and Solidity at production depth. Python, Zig, Java, and C# are newer; we will tell you honestly where each stands. C and C++ arrive through the compiler's own coverage measurement, in the same gate. Another stack? Say so on the form and you get an honest timeline.
Request confidential scoping.
Findings are signed by name; who signs is its own page. Your email is enough to start; the note is optional. We reply personally, with a scoping call or an honest no. Fees are quoted after scoping and fixed before work starts. For private code, we countersign your NDA before reading a line — access models and data handling are on Trust.