Sources you can inspect
Keep the relevant artifact and intent version visible. A summary should help you reach the evidence.
The review, with its context attached
Review the pull request.
See what remains unproven.
For the engineer approving another author’s AI-assisted change. Compare the agreed requirements with the exact change and its evidence. The example below is synthetic; real reviews begin through a founder-assisted pilot.
01 / Agreed intent
Start with what
“done” should mean.
Make the goal, constraints, and acceptance criteria explicit. Keep the version being reviewed in view, so the discussion has a clear reference point.
Prevent duplicate invitation emails
Goal: make retrying an invitation safe.
- One invitation, one email.
- Show a usable pending state.
- Allow retry after delivery failure.
Constraint: a timeout does not prove that delivery failed.
02 / Relevant context
Keep the why
close to the work.
Bring in the documents and decisions that explain the requirement. Open the source rather than trusting an isolated summary.
Invitation delivery constraints
Retries are allowed. Duplicate delivery is not.
Read the sample Vault note
When a provider request times out, delivery may already have been accepted. The retry policy needs to account for that uncertainty.
Open question: does the provider support an idempotency key? Verify this before accepting the recovery behavior.
03 / Inspect the evidence
A useful review
makes questions visible.
Select a requirement. Compare the author’s summary with the review questions, then inspect the source. This is a synthetic example of the workflow we are exploring through a founder-assisted pilot.
Intent v3 · PR #42 · commit 7c91e2a
Prevent duplicate invitation emails
Alex authored the change. Sam is reviewing. All people, code, and evidence in this example are fictional.
Agreed requirements
Sequential retry covered
One invitation, one email
The sequential retry test supports this case. It does not establish safety when two requests arrive together.
Inspect source · tests/invitations.test.ts · lines 41–48
await invite({ email, requestId });
await invite({ email, requestId });
expect(sendEmail).toHaveBeenCalledTimes(1);Synthetic excerpt for this demonstration; not a linked production artifact.
Can two concurrent requests both reach the delivery provider?
Add a concurrent-request check at the shared delivery boundary. A sequential test cannot answer this question.
Evidence can support a requirement without settling every question. The reviewer makes the decision.
The workspace around the review
Work, context,
and intent together.
Issues and projects organize the work. Vault holds useful context. Intent makes the agreement explicit. Start the pilot from your existing workflow.
Harbor / Reliability / In review
HBR-142 · Prevent duplicate invitation emails
Keep the change connected to its project and the people doing the work. The pilot can start with an existing task or PR; you do not need to maintain a second board.
Illustrative workspace content.
Designed for inspectable judgment
Confidence needs
something to stand on.
Unknowns stay visible
Missing checks and unresolved assumptions belong in the review, not behind a blanket “passed” badge.
People make the call
The pilot helps prepare a review. It does not automatically approve code or execute agents on your behalf.
Start with one real change
Bring a change.
Inspect what remains unproven.
We’re working with small software teams to explore a more grounded review workflow. Bring an existing task or PR. No board migration required.
Founder-assisted pilot. Scope and access agreed together.