the audit · end to end
Four weeks with your engineers. Then the gate runs without us.
One component, chosen with you. We read the code with the people who own it, recover what it was supposed to do, and write the promises down where a machine can check them.Onboarding is personal and it takes our team. That is where the accuracy comes from.
- Week 0
Pick the component
We agree the shape and the fixed fee, and countersign your NDA before reading a line of private code.
- Weeks 1–2
Recover the promises
We write them down with your engineers, numbered and testable. They read each one and approve it.
- Weeks 2–4
Checks, findings, the register
The promises compile into checks. A person validates every finding before it reaches you.
- From week 5
The gate runs in your CI
Every commit is held to the signed promises. The dashboard keeps the register readable by people who will never open the repo.
What you walk away with.
Four artifacts, and you keep the requirements and the tests whatever happens to us afterwards. They sit in your repository under your licence, in plain text your engineers can read and edit.
A written set of requirements for the component
Numbered, testable, and approved by the engineers who own it. The reference for every check that follows.
New hires read them. So do your agents.
A register of known issues
Each entry carries a severity, a description your product manager can read, and the requirements it breaks. Fixed entries stay on the record, so a bug that came back is visible as a bug that came back.
A test suite bound to the requirements, running as a gate
Every reproducer we wrote stays in your suite and runs on every commit, in your CI, on your runners. Red blocks the merge.
An audit page your board and your customers can read
Public or private, your call. It answers the due-diligence questionnaire with a link.
the requirements are written as numbered, testable statements in your repository. FRETish patterns are used where a requirement needs a temporal shape.
Severity is arguable. The reproducer is not.
We write the severity argument down so you can push back on it. The reproducer settles itself: it runs red on your main branch or it does not. This is what a validated finding looks like when it reaches you.
trueish → parsed trueprefix matchedYour engineers run the test, watch it fail, apply the fix and watch it pass. The fix arrives as a pull request they review, or as a commit from your own team. The same test passes on the merge commit.
Then the finding is pinned: the whole defect family gets a check that runs on every release after, and removing that check fails the gate. The bug you paid to fix stays fixed.
fig. 02 · Schematic of the finding card for KI-11, from the public jsonparser register. The reproducer is generated against the requirement, then minimised.
A fix closes one bug. The family comes back two releases later.
In a different function, written by a different hand. That is the whack-a-mole every platform team knows. When we close a finding we pin the class it belongs to, and the check for the family runs on every release from then on.
fig. 03 · A defect class stops recurring. Schematic. Each cross is the same defect family coming back; after the pin, bringing it back turns the gate red instead.
The terms, on one card.
Scope
One component, chosen with you. The one you can least afford to be wrong about.
Time to install
Roughly four weeks, working alongside the engineers who own the component. This part is not self-serve, and that is why the requirements are yours rather than ours.
Commercials
Fixed fee, agreed before work starts.
Afterwards
It re-runs on the cadence you choose. Optional fix sprints arrive as pull requests your engineers review.
Every run
Nothing lands in your dashboard until a person has checked it. The machines run the checks on every commit and produce candidates; a person decides which of them your team ever sees.
proof · reqproof.com · sheet 02 of 05 · rev continuous