01
The specification
Your engineers write the contract people review: what comes in, what must come out, and what must always hold. That surface is small enough to argue about.
Vericoding training
Proof in the pipeline.
Training for engineering teams in high-stakes environments. Formal verification runs in the CI/CD pipeline, and a failing proof does not merge.
Discuss trainingWhat the team can do
02
The pipeline
The prover runs on the pull request, in the CI you already have. It is a check in the pipeline, not a report someone files later.
03
The merge
A change that breaks the proof does not merge. The team sees the failed goal, fixes the specification or the code, and runs it again.
Why the pipeline
A person cannot read every line.
Models now write more code than a review can keep up with. The pipeline can refuse the change the prover does not accept.
Training is how that check becomes something your engineers run, on the repository they already ship from. The sectors where that matters are the ones where a single defect is the failure.
How the training runs
-
The stakes
We start from the system where a defect is money lost, a penalty, or a safety failure. That is the code the pipeline will guard.
-
The specification
Your engineers learn to write the contracts they will own, and to read a failed proof well enough to know what to change.
-
The pipeline
We wire the prover into CI on your repository, using the same toolchain the proofs are written in.
-
The next change
Your team makes it. The check is theirs. We stay until that change has been through the pipeline without us in the room.
The proofs use the vericoding toolchain. The method is vericoding: people review the specification, a model proposes the implementation, and a theorem prover checks the result. The sectors where a defect cannot be shrugged off are on the sectors page.
Discuss training
Tell us the team, the repository, and the failure the pipeline has to catch.