PDD Kit: what founders should ask before calling an AI-built feature verified

A feature can refuse every customer and still satisfy a requirement that it must never admit the wrong person. That is an uncomfortable possibility for founders who ask an AI builder to make something “secure” and then accept a green check as the finished product.

On November 5, Microsoft Research described PDD Kit, which connects developer intent to formal specifications and checked proofs, with tests for what the proof does not cover. Its example concerns login logic in a Rust storefront. The useful development for nontechnical founders is that reviewing the intended behavior becomes a concrete part of the work, rather than a sentence above an implementation nobody can explain.

This guide is for small teams deciding whether an AI-built customer feature is ready to use. It proposes a customer-promise worksheet, an acceptance meeting, and release boundaries. The central judgment: ask both who must be excluded and what an eligible customer must receive, then state the conditions and recovery path for each promise.

We have not run PDD Kit, reproduced the demonstration, or measured development savings. The release account is the authors' evidence. The product scenarios and review process below are our proposals, not reported customer results. Nothing here establishes that a particular application is secure.

1. Treat the news as a change in review, not a replacement for expertise

The GitHub Next project page identifies PDD Kit as a research prototype that currently verifies Rust. That is a substantial adoption boundary for a founder whose application uses another stack. A useful idea can influence your requirements today without being an available upgrade for your builder tomorrow.

Before arranging a pilot, ask your technical lead what can actually be evaluated in your environment. Separate access to the prototype, language compatibility, the effort to express a property, and maintenance of the proof. An answer about one does not settle the others. Do not commission a rewrite just because a demonstration makes the verification step look short.

There is also a change in responsibility. A founder does not need to inspect every proof step to decide whether customers should lose access when their subscription changes. They do need to understand that policy before someone encodes it. The person who understands billing exceptions may be a support lead; the person who understands access enforcement may be an engineer. Neither should silently decide the other's part.

Chopin is described by GitHub Next as a collaborative planning environment and a research prototype. Shared planning helps make disagreements visible; it does not itself establish that a business decision is correct. Put customer support, product ownership, and implementation review into the same discussion where the feature warrants it.

The immediate opportunity is narrower than “stop reviewing code.” It is to make the team explain the behavior it wants before implementation creates momentum. A disagreement about what cancellation means is cheaper to resolve in a short policy note than in a support queue after launch. That remains true even if your team adopts none of the prototype.

2. Learn the terms well enough to challenge the right claim

A specification states the behavior that will be checked. A formal proof establishes a mathematical claim relative to that specification and its assumptions. A test runs selected situations and observes results. These forms of evidence answer different questions; a test passing does not make it a proof, and a proof does not choose your product requirements.

The Verus guide describes static verification of Rust against user-provided specifications. It also explicitly excludes verifying the verifier and Rust/LLVM compilers from its present goals. That context prevents a loose phrase such as “all possible inputs” from expanding into a claim about every layer of a deployed service.

A trusted computing base, or TCB, is the set of components and assumptions relied upon outside the proof's own checks. For a founder, the practical question is: which customer promise would become unreliable if an assumed component behaved differently? You need an intelligible answer, not merely a list of library names.

A safety property rules out an unwanted result. A progress or availability requirement concerns useful work happening, often with conditions about time and dependencies. These categories are helpful prompts, not interchangeable formal guarantees. A rule about the result returned after a function finishes does not necessarily establish that it will finish.

The Verus repository provides the tool's source and project documentation. It is a way to inspect the implementation and its status, not an independent replication of PDD Kit's application demonstration. Likewise, Microsoft and GitHub Next describe related work; two pages do not represent two separate confirmations of performance. Our recommendation concerns the review questions justified by those boundaries, without claiming a measured reliability improvement.

3. Write the positive entitlement beside the prohibition

Start with a sentence from your actual product brief: “Only paid members can download the report.” It states a restriction. A product that never allows downloads obeys that restriction while delivering no membership value. The missing question is what a paid member should receive and under which conditions.

Consider a fictional research service, Harbor Notes. Its founder, Maya, wants an AI builder to add paid report access. Harbor is an invented scenario, not a YBuild customer. It has three relevant objects: a member, a workspace, and a report. A report may be ready, still processing, or unavailable. Payment status and workspace membership can change independently.

Maya rewrites the requirement: a current workspace member with the required entitlement can retrieve that workspace's ready report; other users cannot retrieve it. If report generation has not finished, the page explains the state without pretending the file exists. If billing status cannot be established, the product follows a documented temporary policy and gives the user a recovery route.

That wording is still a product brief rather than a formal specification. Its value is that someone can now object to it. Does an owner retain access after leaving the workspace? Does cancelling renewal remove access immediately or at the paid period's end? Can a member retrieve an old report after its creator leaves? These are product decisions, and none follows automatically from the word “paid.”

Use paired examples during review. Show an ineligible person being refused, then an eligible person succeeding under healthy dependencies. Ask whether the same report, workspace, and identity remain linked throughout. A success for a different account is not the customer's success. The exercise exposes missing policy before an engineer decides how to model or test it.

4. Separate eligibility, dependency failure, and waiting

The hardest cases are often neither “yes” nor “no.” Harbor's billing service might be unreachable while an existing customer opens a report. A report may be ready in storage but absent from the application's index. An access check may pass while the eventual download fails. Treat these as separate states with owners.

For each dependency, decide what the user sees and what the system is allowed to do. A temporary billing outage should not silently become a permanent statement that the customer has not paid. Equally, uncertainty should not become a blanket entitlement for everyone. You may choose limited cached access for an established member, or temporarily pause sensitive downloads. The choice depends on the data and your policy; this article supplies no universal answer.

Waiting also needs a product decision. A page that spins forever may never return a forbidden result, yet it abandons the user. Define how the interface reports delay, what can safely be retried, who receives an unresolved case, and how the person learns the eventual outcome. Choose timing expectations from your service's actual capability rather than borrowing a number from a demonstration.

Stripe's webhook documentation gives a concrete reason not to assume the happy path: event delivery order is not guaranteed, and duplicate events can occur. If your entitlement depends on incoming billing events, ask how your product handles a newer state followed by an older notification. A proof about a local decision cannot repair an unexamined assumption about upstream state.

For Harbor, the acceptance meeting therefore has three separate questions: who is entitled, whether the evidence for entitlement is available, and whether delivery finished. Support should be able to distinguish them without revealing sensitive account details. A single “access denied” bucket makes operational diagnosis and customer recovery unnecessarily difficult.

5. Review the customer journey beyond the proved component

Login success is not the same as permission to read a particular report. Authentication establishes identity; authorization decides whether that identity may perform the requested action on the requested resource. Harbor needs both. A customer who signed in correctly can still request another workspace's report.

The OWASP authorization guidance recommends denying by default and validating permission on every request. Use that guidance to ask where enforcement happens along the journey. Hiding a download button is not sufficient evidence that the download endpoint checks the workspace relationship.

Draw the journey in plain language: sign in, select workspace, request report, receive file, open shared link. At each transition, identify who makes the access decision and which resource it concerns. Ask the engineer which parts are covered by a formal claim, which have empirical checks, and which remain unexamined. The founder owns whether that remaining uncertainty is acceptable for the proposed release.

Customer communication deserves its own review. The OWASP authentication guidance explains why generic authentication errors help avoid account enumeration, while also discussing the usability tradeoff. A helpful recovery experience must not casually disclose whether someone else's account exists. Support detail and public error text can be different without becoming contradictory.

At Harbor, Maya asks a colleague to walk through the experience as a legitimate member whose download failed. Can they tell whether to wait, retry, or contact support? Does the support reference identify the failed operation without exposing another workspace's data? These observations cannot be replaced by a proof about a narrower function. They are part of accepting the customer feature rather than only its decision logic.

6. Use a customer-promise worksheet that makes omissions visible

Copy the worksheet below into the feature brief. The rows are proposed review cases, not a benchmark or an exhaustive security checklist. Replace Harbor's policy choices with your own. For each row, record the exact requirement, current evidence, scope, outstanding question, owner, and release consequence.

Do not mark an entire row “proved” when only a fragment is covered. “The permission decision is proved under a fresh membership lookup assumption; delivery and UI are tested” conveys something useful. “Verified download” does not tell a release owner what they are accepting.

A blank cell is a decision to make, not a failure to hide. Some rows may be irrelevant: a static public report has no membership revocation rule. Write why a row does not apply. That makes future changes easier to review when a public feature later gains paid access.

A filled Harbor entry might read: “Requirement H-01, revision A: a current member can download a ready report in their workspace during the paid period. Assumptions: membership and entitlement reads are current, and file storage is available. Evidence: planned; no proof or test run yet. Owner: product lead for eligibility, engineer for enforcement. Release consequence: no paid launch until a healthy, eligible journey succeeds and an unrelated workspace is refused.” This is a proposed acceptance record, not a statement that Harbor passed. If the implementation returns a temporary error for every eligible request, the team must examine the success requirement and failure exceptions rather than accepting a reassuring refusal statistic.

Keep the worksheet close to the feature's acceptance record. A detached document will become stale when an agent changes implementation or a founder changes policy. Store a revision identifier for the requirements and a reference to the implementation reviewed. When you cannot connect the evidence to the current feature, treat its status as unknown until someone reconciles it.

7. Run an acceptance meeting that tests understanding

Invite the product owner and the person responsible for implementation. Add support or operations when they will handle the failure states. Pick one customer journey, not the whole application. Send the policy questions in advance so the meeting resolves decisions rather than rewarding whoever can improvise technical language fastest.

Begin with the eligible customer's expected outcome. Have the product owner explain why that person qualifies. Then change one fact: revoke membership, switch workspace, delay billing evidence, or leave the report unfinished. The implementer should explain which requirement now applies, not merely show that a test suite is green.

Next ask what a passing verification result actually establishes. Require a sentence naming the property, the assumptions, and the implementation revision. If the team cannot express that sentence clearly, the founder cannot responsibly turn it into a customer-facing claim. The solution may be better explanation, a narrower scope, or more work, depending on what is missing.

Challenge the retry path separately. Stripe's idempotent request documentation describes keys that help avoid repeating an API operation on retries. That mechanism is specific to the supported request and its documented behavior. It does not automatically make Harbor's downstream entitlement update, email, or report job idempotent. Ask what identifies the same business operation across those steps.

Close with actual decisions: which behaviors are required, which assumptions someone accepts, what evidence is still planned, and who can release. A proposed test remains planned until it runs. A demonstration of a different revision remains evidence about that revision. These distinctions keep the meeting from turning into ceremonial approval while leaving room for an honest, limited pilot.

8. Match the investment to the cost of a mistaken promise

Formal verification work makes the most sense where the property is precise, the consequence matters, and the team can maintain the relevant specification. Access decisions or bounded allocation rules may offer a manageable starting point. An entire evolving product with vague success criteria is a poor first scope.

Ask what you would stop doing, add, or delay to fund the work. A small team may get more immediate value from clarifying its entitlement policy and fixing missing server-side checks than from investigating a new proof tool. That is a sequencing decision, not evidence that proof has no value. Conversely, repeatedly patching the same critical decision may justify a stronger approach if the team has suitable expertise.

Use three adoption choices. Explore when you have a costly, expressible property and a technical owner who can assess fit. Borrow the review method when your stack or access does not fit but your requirements are ambiguous. Defer when the feature's dominant uncertainty is customer demand, subjective quality, or an operational dependency outside the proposed scope.

Do not mistake an AI feature's probabilistic output for the deterministic rule around it. Harbor might use a model to write a report, but the right to download it is a separate question. A proved access decision does not establish that the report is correct, current, useful, or worth buying. Evaluate those claims with evidence suited to the actual output.

A practical first deliverable is a narrowed statement, not a tooling mandate: “We will review the workspace entitlement decision for ready reports, with explicit treatment of unavailable billing evidence.” That gives an engineer a concrete proposal to assess. It also gives the founder something to decline if the investment would not address the product's largest unresolved risk.

9. Release with a bounded claim and a way to reopen the decision

A release decision should follow the worksheet's unresolved items. Block a sensitive customer rollout when a missing rule could expose another workspace's report, when the positive entitlement is unspecified, or when a dependency assumption has no owner. Consider a limited internal pilot when the remaining uncertainty is understood and the audience and data allow it. Those are proposed decision rules, not guarantees of safety.

If a feature ships, describe exactly what was checked. “We verified a specified access decision under documented assumptions and tested the delivery path” is more informative than “our AI-built app is mathematically bug-free.” Only use even the narrower wording if your team's evidence genuinely supports it. This article does not grant that status to a reader's application.

Name events that require renewed review: changed cancellation policy, new identity provider, different billing event handling, an additional sharing route, or edits to the specification itself. A proof may remain valid while the product starts promising something else. An unchanged green result cannot approve an unreviewed change in customer expectations.

Monitor useful success and harmful failure separately. Eligible customers completing the intended journey, ineligible requests being refused, unresolved cases, and recovery outcomes each illuminate a different part of the product. Define denominators and avoid treating a fall in successful access as a security win. These are suggested observations; we have not collected results for Harbor or PDD Kit.

PDD Kit's timely contribution is a reason to take requirements review seriously while AI produces more implementation. For a founder, the next action is concrete: choose one consequential feature, write the customer's positive entitlement beside the restriction, and ask the team to show where each claim stops. That makes the release conversation about the product customers receive, with evidence proportionate to the promise.

References

• Microsoft Research: PDD Kit demonstration, November 5, 2026.
• GitHub Next: PDD Kit project and current scope.
• Verus source repository.
• Verus tutorial: overview and exclusions.
• GitHub Next: Chopin research prototype.
• OWASP: authorization guidance.
• OWASP: authentication guidance.
• Stripe: webhook event delivery behavior.
• Stripe: idempotent requests.