Microsoft Research Demonstrates PDD Kit

Microsoft Research presented PDD Kit, a toolkit that helps coding agents turn a developer’s intent into formal specifications, prove code against those specifications for every input, and use tests for requirements a proof cannot cover. The toolkit is designed to make formal methods usable by engineers without a formal methods background. Microsoft demonstrated it on the login logic of Pet Store, a full-stack Rust web app, where Verus proved the specified login properties and uncovered existing bugs. The developer reviewed the intent without reading the generated code line by line.

Microsoft says coding agents can now produce features spanning tens of thousands or hundreds of thousands of lines, making line-by-line review difficult to scale. A plan is meant to record what the developer wants, but an agent can drift from it and write tests that pass for its own implementation. Those tests cover only some possible inputs, so they may miss cases that contradict the original request. PDD Kit uses proofs to check specified properties for every input, while tests cover behavior outside the proof.

The toolkit works inside Chopin, GitHub Next’s shared planning environment. It asks developers questions about their intent, explains relevant code, and records agreed requirements in an intent artifact that connects those requirements to formal specifications and tests. PDD Kit generates Verus proofs for requirements that can be formalized and tests for the rest. For the Pet Store demonstration, the developer requested that a login token require the correct password and that only admin accounts receive admin tokens. PDD Kit asked whether the correct password must always produce a token; the developer confirmed both directions of the requirement. The developer also chose to include the login handler in the proof, so the proof covered the code connecting the request to the token or HTTP error.

Pet Store has about 5,000 lines of Rust. Its backend uses Axum and SQLite for inventory, promotions, orders, and checkout, while its Leptos storefront is compiled to WebAssembly. Microsoft focused on login as a sensitive part of the app and said the same process can be used to verify the app’s functional correctness more broadly. For login, the proof does not cover bcrypt hashing, database queries, token signing, the current database contents, the clock, whether a request finishes, user-facing messages, or requirements nobody specified. Those elements sit outside the proof and rely on explicit assumptions or tests.

PDD Kit makes the trusted boundary visible through the Trusted Computing Base, the code and assumptions a proof relies on. The developer approved six trusted pieces: customer and admin account lookups, password checking, token generation, an expiry function that sets tokens to expire exactly 24 hours—or 86,400 seconds—after the clock reading, database error handling, and the login handler shell. PDD Kit wraps trusted behavior in small functions with assumed contracts and plans tests for every assumed clause. Its plan marks each check as planned until it runs, then records the command’s result and the

Microsoft Research presented PDD Kit, a toolkit that helps coding agents turn a developer’s intent into formal specifications, prove code against those specifications for every input, and use tests for requirements a proof cannot cover. The toolkit is designed to make formal methods usable by engineers without a formal methods background. Microsoft demonstrated it on the login logic of Pet Store, a full-stack Rust web app, where Verus proved the specified login properties and uncovered existing bugs. The developer reviewed the intent without reading the generated code line by line.

Microsoft says coding agents can now produce features spanning tens of thousands or hundreds of thousands of lines, making line-by-line review difficult to scale. A plan is meant to record what the developer wants, but an agent can drift from it and write tests that pass for its own implementation. Those tests cover only some possible inputs, so they may miss cases that contradict the original request. PDD Kit uses proofs to check specified properties for every input, while tests cover behavior outside the proof.

The toolkit works inside Chopin, GitHub Next’s shared planning environment. It asks developers questions about their intent, explains relevant code, and records agreed requirements in an intent artifact that connects those requirements to formal specifications and tests. PDD Kit generates Verus proofs for requirements that can be formalized and tests for the rest. For the Pet Store demonstration, the developer requested that a login token require the correct password and that only admin accounts receive admin tokens. PDD Kit asked whether the correct password must always produce a token; the developer confirmed both directions of the requirement. The developer also chose to include the login handler in the proof, so the proof covered the code connecting the request to the token or HTTP error.

Pet Store has about 5,000 lines of Rust. Its backend uses Axum and SQLite for inventory, promotions, orders, and checkout, while its Leptos storefront is compiled to WebAssembly. Microsoft focused on login as a sensitive part of the app and said the same process can be used to verify the app’s functional correctness more broadly. For login, the proof does not cover bcrypt hashing, database queries, token signing, the current database contents, the clock, whether a request finishes, user-facing messages, or requirements nobody specified. Those elements sit outside the proof and rely on explicit assumptions or tests.

PDD Kit makes the trusted boundary visible through the Trusted Computing Base, the code and assumptions a proof relies on. The developer approved six trusted pieces: customer and admin account lookups, password checking, token generation, an expiry function that sets tokens to expire exactly 24 hours—or 86,400 seconds—after the clock reading, database error handling, and the login handler shell. PDD Kit wraps trusted behavior in small functions with assumed contracts and plans tests for every assumed clause. Its plan marks each check as planned until it runs, then records the command’s result and the