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 project authorized the change, whether the code satisfies its specifications, and whether the project still agrees with the product strategy above it.
Use a three-part verification record
Start with provenance. The pull request must identify the project or ticket that authorized the work. Then walk its parent chain to the persona, problem, goal, and strategy.
Next, convert specifications into observable checks. Tests prove runtime behavior, and static analysis can confirm required code contracts. Keep semantic judgment advisory.
Intent
Name the current project and the decisions above it. Do not accept a title or issue number as sufficient context.
Evidence
Map each specification to a test, static check, 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 context chain instead of a folder of documents. Its GitHub check reads the pull request, its linked execution artifacts, and the full chain of product context above them.
Helen reports a missing link and any decision on that chain that is not yet ratified. Open findings on the chain, such as a contradiction, are listed in Reconcile. The reviewer then decides whether the change still serves current intent.
The review decision
A pull request is ready when its source project is current, its chain is coherent, and its specifications have complete evidence. A green test suite alone cannot prove those three facts.