Methodology
How Continuous Correctness Audit turns review into evidence.
Proof scopes one critical path, compares intended behavior against implementation and tests, produces reproducible evidence, and verifies fixes as the codebase changes.
MC/DC, formal verification, reproducers, traceability, coverage, cadence.
The proprietary audit engine, orchestration, scoring, and private corpora.
Workflow
The public methodology.
Scope the path
Pick the parser, router, policy, SDK, agent loop, feature, or release window where failure would matter.
Recover intent
Map what the system is supposed to do from requirements, docs, tickets, tests, code, and product claims.
Find drift
Identify where implementation, tests, documentation, and expected behavior no longer agree.
Produce evidence
Confirm findings with reproducers, regression tests, expanded coverage, MC/DC, or formal artifacts where applicable.
Verify fixes
Retest patches and rerun the evidence corpus on the agreed cadence.
API and infrastructure lenses
Proof looks at the failure modes ordinary review misses.
Protocol, schema, validation, normalization, and version-compatibility behavior.
Malformed input, ambiguous syntax, size bounds, error handling, and fail-closed behavior.
Query planning, federation, subgraph behavior, policy routing, retries, and fallback paths.
Streaming, subscriptions, cancellation, timeouts, shared state, and resource cleanup.
Inputs or request shapes that can amplify CPU, memory, recursion, fan-out, or downstream work.
Cross-version behavior changes that break users even when internal tests still pass.
Validation gates
What makes a finding deliverable.
| Gate | What Proof checks |
|---|---|
| Reproducibility | There is a runnable reproducer, test, fixture, replay, trace, or a clearly bounded explanation for why full reproduction is not possible. |
| Severity | Impact, exploitability, preconditions, required privilege, blast radius, data/security boundary, DoS potential, regression likelihood, confidence, and detection difficulty are considered. |
| Noise control | Findings are manually reviewed, duplicates are removed, affected surfaces are confirmed, and unvalidated leads are not presented as confirmed issues. |
| Patch verification | Fixes are retested against the original reproducer and adjacent regression cases where feasible. |
| Disclosure | Customer findings remain private unless publication, advisory language, or field-note reuse is approved. |
MC/DC and formal artifacts
Used where they raise confidence.
MC/DC and formal artifacts are used when the reviewed path has decision logic, state transitions, or invariants where ordinary tests do not give enough evidence. They are not claimed for every component by default.
Evidence handoff
The buyer should not depend on Proof to believe the report.
- Delivered findings include affected surface, severity rationale, reproduction notes, and retest status.
- Regression tests and reproducers should be inspectable and portable where practical.
- Proof's internal orchestration remains proprietary; the delivered evidence must still stand on its own.
What this proves
Scoped evidence, not total correctness theater.
- A finding is reproducible or explicitly bounded by the available evidence.
- The affected surface, severity, and remediation path are clear.
- Regression risk is reduced because the evidence can run again.
What it does not prove
No blanket claim that all software is correct.
- Proof does not claim full-system total correctness.
- Unreviewed components stay out of scope.
- Customer-specific findings stay private unless approved for publication.