Microsoft Research described PDD Kit as a research prototype in an article published November 5, 2026. Its Pet Store demonstration reports formal proofs for five login functions against approved contracts. The proof covers those specified properties within the model; database access and other external operations remain trusted and tested. Microsoft Research’s account of PDD Kit
What the Pet Store login proof covers
Formal verification uses a machine-checked proof to show that code satisfies a written specification under a defined model. In the Pet Store example, Microsoft Research reports that five functions meet their contracts for every input represented by that model: login_flow, login_core, lookup_target, decide_login, and `issue_token.
The example concerns login logic in a full-stack Rust storefront of about 5,000 lines, not a proof of the entire application. Its top-level login_flow contract has eight ensures clauses. They specify outcomes involving passwords, account and token identity, roles, and errors.
A test checks particular cases that someone runs. A formal proof covers the specified properties across the model’s inputs. That broader coverage applies to the specification as written, not to every behavior a developer might have intended.
A proof can cover every modeled input and still be limited by the requirements it was given.
How intent becomes a Verus contract
PDD Kit’s workflow turns a developer’s requirements into contracts that Verus can check against agent-written Rust code. A contract states what a function must do, including conditions that should hold after it runs. The team reviews decisions about ambiguous requirements before those decisions become part of the specification.
The login example makes one ambiguity concrete. “Never issue a token for the wrong password” does not require a successful login when the password is correct: a program that rejects everyone would satisfy that one-way rule. The stronger contract also says that the right password should produce a token, subject to specified lookup or signing failures.
That extra requirement rules out the “reject everyone” behavior in the model. It also shows why reviewing the contract matters as much as checking whether code satisfies it.
What remains trusted and tested
Several operations sit outside the formal proof of their external implementations. The Pet Store example treats database lookups, bcrypt password checking, token signing, clock access, database-error handling, and request unpacking as trusted operations with accepted contracts and tests. Microsoft Research groups these sign-offs into six categories, with two database lookups in one category.
For example, the login contract specifies token expiry 86,400 seconds after the clock reading. The clock itself is trusted, so the proof does not establish how that clock behaves. The example also specifies login outcomes for particular password and lookup conditions, while making no guarantee that an asynchronous login will finish or how long it will take.
Those boundaries are useful when judging what the result means: the proof covers the modeled login functions and their contracts; tests address trusted components. Neither turns the demonstration into a proof of the whole storefront.
Why a proof cannot validate intent by itself
A proof establishes that code meets its specification. It does not independently establish that the specification captures everything the developer meant. PDD Kit’s review and decision steps help surface ambiguity, but they cannot make intent validation infallible.
Shuvendu K. Lahiri’s broader research on intent formalization places tests and executable contracts toward the lighter end of a spectrum, logical contracts such as Verus specifications further along, and domain-specific-language-based verified synthesis at the stronger end. The paper identifies specification validation as a central challenge because user intent has no independent oracle. Lahiri’s paper on intent formalization
Why the demonstration is Rust-specific
Microsoft Research says the PDD Kit prototype described in its account verifies Rust only. Verus is an SMT-based tool for formally verifying Rust programs. Its official project description explains that proofs use Rust syntax and draw on Rust’s linear types and borrow checking to express ownership-related reasoning. Microsoft Research’s Verus project description
That is the basis for the demo’s language scope, not evidence of built-in support for other languages. The result is a concrete, Rust-focused example of checking agent-written code against reviewed contracts, with trusted operations and the quality of those contracts still central to what the proof can establish.
