Microsoft demonstrates PDD Kit’s Rust login proofs
Microsoft Research’s November 5 PDD Kit walkthrough demonstrates formal verification of login logic in a Rust storefront.
PDD Kit means Proof Driven Development Kit. It remains a research prototype. GitHub Next described it as a limited research preview in its October 29 Universe presentation, so the November 5 example should not be mistaken for a generally available product launch.
What the Pet Store demonstration actually verifies
Five Pet Store login functions meet specified contracts under accepted assumptions. The demonstration does not establish that the entire storefront is secure.
Database lookups, bcrypt password checking, token signing, the clock and surrounding request handling remain outside that proof. Tests exercise those boundaries. The specification also does not promise that login finishes, responds quickly, limits attempts or that other endpoints handle roles correctly. Requirements left out of the specification remain left out of the result.
ByteForward reviewed the public documentation. We did not run PDD Kit, reproduce the Pet Store proof or independently assess the application’s security.
Why checking the plan comes before checking the code
The GitHub Next presentation describes a workflow with three distinct checks. Verus checks the formal proof, tests exercise trusted components, and an LLM reviews the plan and results for gaps. Contradictory requirements return to the developer for a decision. A pull request carries the specification and proofs.
That separation lets a reviewer ask which requirement each piece of evidence supports, rather than relying on an agent’s confidence. The model’s critique is a review aid. The formal check is performed by Verus. Those outcomes should be recorded separately.
A similar distinction appears in Axiom’s Stacks Lean library and its human review process. A proof checker can establish a formal statement while people still need to decide whether that statement faithfully captures the intended meaning. The mathematical and software projects have different tools and goals, but both make translation quality important.
PDD Kit, Chopin and Verus have different availability
The public Chopin repository is a collaborative planning environment, released under MIT. Its README calls it experimental research software and warns of incomplete workflows and breaking changes. It provides no public instance for general use. Readers can investigate local or self hosted deployment. Access to Chopin’s source should not be read as confirmation that every PDD Kit capability is publicly packaged.
The walkthrough offers no PDD Kit installation instructions or Pet Store repository link.
Search results also surface an unrelated pdd-kit project by Itai Gendler. That project means Product Driven Development and centers on a shared product model for coding agents. Its package instructions do not install Microsoft’s proof verification prototype.
What developers can explore now
Verus itself is public and supplies installation guidance, examples and a browser playground. It supports a subset of Rust and remains under active development, with missing features and incomplete documentation. An existing Rust codebase is a starting point for exploration, not a promise that every feature or dependency can be verified.
The Verus tutorial explains that verification is static rather than an added runtime check. Developers express specifications and proofs using extended Rust syntax. More complex arguments may still need explicit proof work. Its stated scope excludes verifying the verifier itself or the Rust and LLVM compilers.
For a small evaluation, start with a function whose expected behavior you already understand. Write down the allowed inputs, required output and failure cases before asking an agent to implement it. Review the specification as carefully as the result: a permissive condition can be satisfied while leaving the behavior you care about unconstrained.
A practical review checklist
Our recommendation is to keep three separate records during an experiment. First, list the exact properties checked by the verifier and the code revision involved. Second, list assumed dependency behavior and the tests that exercise it. Third, list operational requirements that need other evidence, such as latency under load and recovery from a stalled dependency.
For example, deliberately remove a required rejection branch in a disposable experiment and check whether verification fails. If it still passes, investigate whether the specification actually requires that rejection. This is a proposed evaluation, not a test we performed. Keep normal review and deployment checks for anything the formal model does not cover.
For teams evaluating coding agents, PDD Kit’s strongest contribution is a concrete way to discuss what has been established and what remains assumed. The decision to adopt a workflow should turn on that boundary, the effort required to maintain it and whether the specifications represent the product’s real requirements.
AI generated editorial illustration by ByteForward. Microsoft logo: Microsoft. Conceptual image, not a PDD Kit interface. Microsoft is a trademark of the Microsoft group of companies. No affiliation or endorsement is implied.
