Engineering leadership
How do I verify AI-generated PRs against product requirements?
Treat the pull request as a claim about product intent, not only as a code change. A reliable review proves which requirement authorized the change, whether the code satisfies its accepted clauses, and whether the requirement still agrees with the product strategy above it.
Use a three-part verification record
Start with provenance. The pull request must identify the requirement, story, or ticket that authorized the work. Then walk its parent chain to the persona, problem, goal, and strategy.
Next, convert acceptance criteria into observable checks. Tests prove runtime behavior, while exact static checks can prove required code contracts. Keep semantic judgment advisory unless a human has reviewed the rule and its evidence.
Intent
Name the current requirement and the decisions above it. Do not accept a title or issue number as sufficient context.
Evidence
Map each acceptance criterion to a test, exact checker, or explicit reviewer decision.
Freshness
Confirm that no ancestor was abandoned, replaced, or changed after the implementation began.
What Helen’s Foundry adds
Helen’s Foundry keeps product intent as a linked graph instead of a folder of documents. Its GitHub check reads the pull request, linked execution artifacts, their effective specification, and the full chain of product context.
Helen reports missing context and contradictions separately from exact specification violations. That separation lets a reviewer distinguish an uncertain product judgment from a deterministic contract failure.
The review decision
A pull request is ready when its source requirement is current, its chain is coherent, and its accepted blocking clauses have complete evidence. A green test suite alone cannot prove those three facts.