Requirement Verification Checkpoint (CQ)¶
Owner: Vi | Updated: 2026-02-05
Purpose¶
Before building, devs must prove they understand what they're building—in their own words. This catches misunderstandings BEFORE code is written, not after.
The problem: Devs interpret requirements through their own lens, not the intended lens. They build what they understood, not what was meant.
Why This Matters¶
| Without Verification | With Verification |
|---|---|
| Dev assumes they understand | Dev proves they understand |
| Misunderstanding found at review | Misunderstanding found before coding |
| Rework after building | Get it right first time |
| "That's not what I meant" | "Yes, that's exactly right" |
The lens problem: Devs see requirements through their own experience and assumptions. Verification forces them to articulate through the RIGHT lens.
The Verification Process¶
Step 1: Read the Task Completely¶
Before doing anything: - Read the full task description - Read acceptance criteria - Look at reference links - Check related tasks
Don't skim. Actually read.
Step 2: Write a Summary in Your Own Words¶
In the task comments, write:
## My Understanding
**What I'm building:**
[Explain in your own words—not copy-pasting the task]
**The user problem this solves:**
[Why does the user need this? What are they trying to do?]
**What "done" looks like:**
[How will I know it's complete? What can the user do?]
**What I'm NOT building:**
[Scope boundaries—what's out of scope]
**Questions I have:**
[Anything unclear]
This is not optional. Writing forces clarity.
Step 3: Get Verification¶
Share your summary and get confirmation:
| What to Verify | Who Verifies |
|---|---|
| Product understanding (what and why) | Ryan or Erik |
| Technical approach | Senior dev or Vi |
| Scope and deadline | Vi |
Why Ryan or Erik for product? Vi sometimes doesn't have full product understanding. Ryan and Erik know what needs to be done. Go to the source.
Step 4: Adjust If Needed¶
If your understanding was wrong: - Update your summary - Clarify what changed - Get re-verified
Only then: Start building.
Verification Checklist¶
Before starting Alpha:
- Read task completely (not just title)
- Wrote summary in own words
- Got product understanding verified (Ryan/Erik)
- Got scope confirmed (Vi)
- All questions answered
- Pre-build research complete (see Pre-Build Research SOP)
If any box is unchecked: Don't start coding.
What Good Verification Looks Like¶
Good Summary¶
## My Understanding
**What I'm building:**
An email sequence builder where users can create a series of
automated follow-up emails with delays between them.
**The user problem this solves:**
Sales reps want to send follow-up emails without manually
remembering to do it. They set it up once, and it runs automatically.
**What "done" looks like:**
User can: create a sequence, add 3+ emails with delays (1 day, 3 days, etc.),
preview each email, and start the sequence. Emails send automatically.
**What I'm NOT building:**
- Branching logic (if user replies, do X) — that's a future feature
- Email templates library — using plain text for now
- Analytics/tracking — separate task
**Questions:**
1. Should delays be in days only, or also hours?
2. Can user edit a sequence after it starts?
Bad Summary¶
I'll build the email feature as described.
This proves nothing. Rewrite it.
The Lens Problem¶
Wrong lens (dev's own perspective): - "I would want to set exact times, not just delays" - "In my experience, branching is essential" - "I think 3 emails is enough"
Right lens (user's perspective, verified): - "Ryan said users just need simple delays for now" - "Erik confirmed branching is phase 2" - "Users in the interview said they typically send 5-7 emails"
How to fix: Always trace your understanding back to a source (Ryan, Erik, user feedback, research). Not your opinion.
When Understanding Doesn't Match¶
If your summary reveals a mismatch:
| Mismatch Type | What to Do |
|---|---|
| Scope larger than deadline allows | Discuss with Vi, adjust scope or deadline |
| Requirements are unclear | Ask Ryan/Erik to clarify |
| You disagree with approach | Raise it, propose alternative, but defer to decision |
| Task seems wrong | Speak up, but verify you're not missing context |
Speaking up is good. But do it BEFORE building, not after.
Who Verifies What¶
| Type of Verification | Go To |
|---|---|
| "Is this what we want to build?" | Ryan or Erik |
| "Is this how it should work for users?" | Ryan or Erik |
| "Is this the right technical approach?" | Senior dev |
| "Is this scope realistic for deadline?" | Vi |
| "Am I understanding the task correctly?" | Whoever wrote the task + Ryan/Erik |
Note: Vi is the gatekeeper for process, but for product understanding, Ryan and Erik are the authority.
Consequences for Skipping¶
If a dev skips verification and builds the wrong thing:
| Situation | Consequence |
|---|---|
| First time | Rework. Conversation about why verification matters. |
| Second time | Escalate to Ryan. Formal discussion. |
| Pattern | Performance issue. |
This wastes everyone's time. Verification takes 30 minutes. Rework takes days.
Integration with Other SOPs¶
| SOP | Connection |
|---|---|
| Pre-Build Research | Research informs understanding |
| User Context Briefing | User context helps verify "why" |
| Task Creation Standards | Good tasks make verification easier |
| Alpha-Beta-Final | Verification happens before Alpha |
FAQ¶
Q: What if Vi says it's fine but Ryan disagrees? A: Ryan's understanding of the product takes precedence. Update your approach.
Q: What if no one is available to verify? A: Wait. Don't start building with unverified understanding. Flag it as a blocker.
Q: What if the task is really simple? A: Still write a brief summary. "I'm adding a button that does X. Clicking it will Y." Takes 2 minutes.
Q: What if requirements change after verification? A: That's a scope change. See Scope Change Process. Re-verify if significant.
Q: What if I disagree with the requirements? A: Raise it during verification. Propose alternatives. But once decided, build what was agreed.
Summary¶
| Principle | Why |
|---|---|
| Write summary in own words | Forces clarity |
| Get verified by Ryan/Erik | They know what's needed |
| Prove understanding before building | Catch errors early |
| Use right lens, not own lens | Build what's intended |
| No verification = no coding | This is not optional |
Prove you understand before you build. Don't assume.