Microsoft’s PDD Kit moves code review toward proof contracts Microsoft’s PDD Kit moves code review toward proof contracts

The requirement comes first

Microsoft demonstrated the workflow on a Rust storefront called Pet Store, concentrating on authentication. A developer supplied two broad requirements about passwords and administrator tokens. The planning stage asked for decisions before implementation, then converted the agreed behavior into formal contracts. The example exposes a useful distinction: rejecting every login satisfies a rule that forbids tokens for incorrect passwords. It does not provide a working sign-in service. Requiring successful authentication for valid credentials closes that gap. The formal target therefore depends on what the human approves, not merely on whether the generated program passes its own tests.

A receipt for the proof

GitHub Next describes a separate implementation loop that generates code and proofs against the approved specification. Its mutation check deliberately changes code to violate individual contract clauses; the verifier must reject those changes. A surviving mutation sends the clause back for investigation. Completed pull requests record which requirements have proofs, which have empirical checks, and which components remain trusted. That record makes the meaning of a successful check visible at merge time. Later changes face the same contracts in continuous integration. This is a proposed review workflow around formal tools, with people still responsible for deciding what the software promises.

What the verifier actually does

Verus checks Rust programs statically with automated solvers. Its documentation describes specifications that must hold across all possible executions of the supported code. The checks run before deployment, instead of inserting another set of runtime conditions into the application. That changes the role of examples: a test executes selected cases, while a verified contract describes a property across the modeled input space. The distinction matters when branches interact in ways an example suite misses. The Verus project also provides small programs, reference material and a browser playground, letting developers inspect the verification mechanism separately from any coding agent.

Planning and proof solve different jobs

GitHub’s existing Spec Kit provides a useful comparison. Its documented processes carry specifications through planning, implementation and convergence, with separate routes for bug fixes and assessing ideas. Teams can adapt templates, add quality gates or connect another coding agent. Those mechanisms organize how work proceeds and how outcomes are recorded. PDD Kit adds a particular mathematical obligation to that planning approach: generated Rust must satisfy the accepted formal contract. A documented process and a proof can therefore sit in the same delivery pipeline. Neither replaces the initial product decision about which behavior matters or who may approve a changed requirement.

The review moves upstream

Consider a simple transfer rule in a hypothetical application: the amount removed from one balance must equal the amount added to another. Proving that relation would establish a useful property. It would not settle who may request the transfer, which account belongs to whom, or whether a duplicate request should run again. Those are separate requirements. This is why moving review to a contract changes the work instead of eliminating it. The person approving the specification must recognize missing promises, while the delivery system preserves the evidence for the promises actually checked. More generated code makes that distinction harder to ignore.