Why this project
I started OpsProof to explore how engineers can present evidence of their work that others can inspect. Development and evaluation were AI-assisted, and the worked simulation was authored and run by Codex.
The problem
A project description can say what someone knows without showing how that claim was tested. Reviewers need a short path from a requirement to an artifact, a result, and enough context to judge what the result really shows.
The approach
OpsProof bundles a requirement, its supporting artifact and the recorded checks into a portable evidence pack. Its rollout example uses a simulation to show the difference between a claim, a recorded result, and a result another reviewer can reproduce.
Key decisions
Tie evidence to a version
An attachment stops supporting a claim when the underlying artifact changes. Version-bound evidence and stale-attachment checks surface that mismatch before anything is shared.
Separate integrity from credibility
Hashes help detect whether an artifact changed. They don’t prove who wrote it, whether the reviewer is independent, or whether the claim matters in a real job. The product keeps those limits explicit.
Make review portable
The handoff includes the artifacts and recorded checks, so a reviewer can inspect how the claim and evidence relate without relying on a dashboard score.
Evidence & limits
A broken rollout baseline
The worked example compares a broken and a corrected configuration under the same deterministic model.
Source files and recorded results are public. Reproducing them checks consistency, not production readiness.
The project has recorded automated checks, published routes, and browser tests of its evidence and pilot flows. The worked rollout has reproducible local checks and a downloadable evidence path. Evaluation used synthetic personas, not recruited human participants.
What this doesn’t prove
No effect on hiring, employer adoption or real-user benefit has been shown. Codex authored and ran the worked simulation after inspecting the supplied model and reference solution, so it doesn’t demonstrate unaided production operations or independently verified authorship.
Evidence last reviewed 7 October 2026. This is a high-level case study: results taken from project records are kept separate from checks rerun for this review, and Chisel's code and internal reports are not published.
Takeaway
An evidence pack is useful when it helps someone ask better questions. It should make the test and its limits easier to inspect, not hand out an unearned credibility score.