For coding & RL data teams
Training data that knows what the code was supposed to do.
You already license source trees. What is scarce is the layer above them: what each piece was supposed to do, how it can fail, and which test proves it. A correctness label package recovers that layer as a machine-checkable graph of requirements, hazards, code and test links and evidence, packaged so you can re-run every check yourself, any day after delivery.
proof-jsonparser-sample-v1.zip · 442 KB · v1.0.1 · sha256 04b646a3…ca96729 · checksum file
Machines check every item before it ships. A person validates every finding before it reaches you. We claim no per-item signatures: requirements carry a named reviewer in the file itself, a field you can read rather than a signature you are asked to trust.
01 · Why this exists
Bug pairs teach “broken → fixed.” Agents need the middle layer.
A correctness label package is a versioned, re-checkable requirement graph over a codebase you already license. It carries what ordinary coding data almost never does: the intent hierarchy above the code, the graded ways each promise can fail, and the link from every claim to the code that implements it and the test that proves it.
What you have today
- Source trees, scraped or licensed
- Bug tags and preference pairs
- Unit tests, or an LLM judge as the reward
- Intent latent in commits and tickets
- Failure modes that surface only after incidents
- Hard to re-verify after delivery
Models see symptoms, not contracts.
What a correctness label package adds
- A full requirement hierarchy above the code
- A formal formula on machine-checkable claims, validated before any code is graded
- Hazard analysis on each claim: worst case and severity
- Machine-readable links: requirement ↔ code ↔ tests
- Condition-level coverage, formal checks where mature
- Findings with runnable reproducers, on the same graph
- A person validates every finding; the reviewer is named in the file
Source of truth moves to the requirement level.
02 · Not this
What we are not selling.
Three things this page does not offer, said plainly, because each is the obvious guess.
Bulk code
Not bulk unlabeled code. You already license trees. We do not compete with scrapers or corpus brokers.
Agent output
Not unverified agent output. Every shipped item passes a machine check where we claim one, findings carry runnable reproducers, and a person validates every finding before it ships.
Our own history
Not Proof’s own source history. We enrich your licensed component. We do not resell our own repository as training data.
03 · The unit
The unit is a requirement node with edges.
The hierarchy has four levels: Stakeholder (STK-REQ), System (SYS-REQ), Software (SW-REQ), Interface (INT-REQ). Parent and child links are explicit, and implementation and tests hang off the levels that matter, so the graph is queryable: pick any requirement and walk to its children, its code, its tests, its hazards and its evidence.
- Stakeholder intent
Why the product exists: acceptance-level needs.
- System requirement
What must always hold: product-level guarantees.
- Component contracts
Software and interface levels, when the graph needs them.
- Hazards
How this claim fails. Worst case and severity on every shipped requirement.
- Code and test annotations
Implements / verifies links: machine-readable, not wiki prose.
- Formula and evidence
Machine-checkable claims carry a FRETish formula (a structured-English template language descended from NASA’s FRET), compiled to temporal logic and checked for realizability, consistency and vacuity before any code is graded. Then coverage, findings, and a person’s validation on every finding.
04 · Fully wired
One requirement, fully wired.
The sample package spotlights one path through the graph: the data-loss class in jsonparser’s Set helper. Everything below is public — the package ships the same files, and the links open them on GitHub.
SYS-REQ-110system · approvedcomponent: parser
Set beyond array length shall append — never silently overwrite.
satisfies the mutation-helper intent under STK-REQ-005 · sibling of the general contract SYS-REQ-009 · the leaf partition for the data-loss class
The implementation, Set() in parser.go, is annotated with the requirement IDs that govern it, and the tests name the requirement they verify. Three graded hazard obligations hang off this claim:
-
boundary · high
Silent overwrite. An index beyond the array’s length destroyed elements the caller never addressed and returned a mutated document with no error. Discharged by MC/DC plus negative boundary tests.
-
nested · medium
Wrong offset. A beyond-length index inside a nested container scaffolds at the wrong offset: a sibling overwrite, or malformed JSON out.
-
partition · high
Whole-array loss. Scalar-first arrays took a replace-container branch and the entire array was destroyed. ✓ fixed — the regression is pinned under the same claim as
DEFECT-260727-WWWY.
The affected code carried 100% MC/DC at the time: every condition in the checked decision logic was exercised. Exercised is not correct, which is why this class produced two published misses, and why the corpus publishes them. The postmortem accounting is on public proof →
id: SYS-REQ-009 status: approved priority: shall component: parser fretish: the parser shall always satisfy !set_path_is_provided | set_target_exists | set_creates_missing_path | set_returns_updated_document | set_returns_not_found_error formalization_strategy: fretish traces: satisfies: - STK-REQ-005 verified_by_extra: - mcdc_supplement_test.go - set_spec_test.go reviewed_by: human:buger obligation_hazards: - class: boundary worst_case: 'Set on an array-index path component [N] where N >= len(array) silently overwrites element 0 or another existing element the caller did not address, destroying data and returning a mutated document with no error (PR #286 regression class).' severity: high
Excerpt from the public requirement node: verbatim fields from the corpus. The reviewed_by: field names the person who validated this node: checkable data in the file, not marketing. The full node on GitHub ↗
05 · Hazards
Hazards are structured negative knowledge.
Most corpora only show failure after an incident. Here every shipped requirement is walked against a failure-mode catalog before anything breaks, and the result is recorded on the requirement itself, in three fields.
Class
A reusable failure type: panic-free input, path traversal, fail-open control, boundary, partition… The same catalog recurs across requirements, so the negatives are comparable across the corpus.
Worst case
The concrete consequence on this requirement, not a generic slogan. “Silently overwrites an element the caller did not address, destroying data with no error” is a training signal; “data loss” is not.
Severity
Low / medium / high / critical, as authored triage — not a CVSS score. The grading is a judgment we wrote down, and the file says so.
For a model, this is the missing layer between “code” and “incident”: graded, per-requirement, machine-readable. The silent data-loss record in the worked example above is one entry of exactly this kind.
06 · The sample
Download it. Check the hash. Re-run the verdicts.
One unit of the product, free to evaluate, built from the public audit of jsonparser, a mature zero-allocation Go JSON library long in production. The package is the proof that the product exists.
- serialization/requirements.jsonl (123 lines) · findings.jsonl (12) · episodes.jsonl (8) · traces_and_hazards.jsonl · one JSON object per line
- PROVENANCE.jsonsubject commit, licence, producer, content root + per-file SHA-256
- re-run/verify.shdeterministic
go testpins, green on the fixed tree;--pin FINDING_IDreruns one finding - corpus/123 requirement files · 8 defect records · 4 known-issue records · evidence, source, tests
- hierarchy/the SYS-REQ-110 spotlight from section 04 · README.md is the entry point
123 requirements · 7 stakeholder + 116 system 116 of 123 carry a FRETish formula · count them in specs/ ↗ 8 defect records on master · 2 credited to outside reporters 2 misses published
The same corpus, elsewhere: the specs on GitHub ↗ · the register in the portal ↗ seeded showcase branch; read the labels first · the full accounting on public proof
07 · Deliverables
Two products. One graph.
Everything above ships in two forms. Both are the same graph; they differ in what you do with it.
Correctness label packages
The requirement graph over a codebase you license: hierarchy, formulas, hazards, annotations, evidence, findings with reproducers. Versioned files, re-checkable after delivery. Priced per package; exclusivity changes the box — never silently.
Verifiable-reward environments
The same graph turned into a training harness: task in, toolchain verdict out. Scoped after a label pilot proves the graph is worth scaling. The sample’s rl/ENVIRONMENT.md states honestly what the demo episodes are and are not.
Why the reward signal is different. Agents game graders: they read future commits, special-case test inputs, and search out a judge’s blind spots. A machine verdict cannot be gamed that way. High reward means the property held — re-runnable on delivery, and any day after.
Formal checks run through Kind2 / Z3 where that path is live; condition-level coverage and reproducers carry the rest. What “verified” means here →
FRETish · Kind2 · Z3 · hazard analysis · MC/DC
08 · Ownership & pilot
You own the code. We license the labels.
The compliance answer first: input provenance stays on your side, and the verdict layer has no model dependency.
Your code
You supply a codebase you already licensed. Input provenance stays on your side. We do not resell your source.
Our labels
We license the derived layer only: annotations, hazards, evidence. Versioned files, re-checkable after delivery.
Deterministic verdicts
The verdict layer is deterministic tooling (toolchain exit codes, coverage, formal checks) with no model dependency. If your policy restricts which models may touch the drafting pipeline, drafting runs on the stack you allow.
The engineering mirror of this custody story →
The first engagement, boxed.
One component of a buyer-licensed codebase, or a clearly licensable open-source slice. History dig → structured requirements → code and test links → coverage and hazard analysis → findings with reproducers → a machine check on every shipped item, a person’s validation on every finding.
- Duration
- 2–3 weeks of calendar time. A tight pilot box, not a monorepo firehose.
- Commercial
- Fixed fee, quoted in the first reply. Complexity or exclusivity changes the quote — never silently after work starts.
- Success
- Your qualitative review of label quality, plus cost per verified pair against market rates.
- Out of scope
- Entire monorepo dumps; third-party finding dumps as “samples”; the sale of Proof’s own product history. Environments are the second product, scoped after a label pilot.
The same engine installs Proof for product teams: a different engagement, roughly four weeks, described on the audit page. The pilot above is the data-team shape, shorter, priced per package, judged on label quality.
Start
Email is enough to start.
[email protected] is the whole ask. Every request gets a reply, and the first reply includes a quoted fixed fee for the pilot box.