The Proof Loop

Understand → Prove → Decide

A lightweight framework for taking a vague ask to a clear build decision: understand the problem, prove the idea, and decide what earns a real build.

·17 min read

Illustration by VectorElements on Unsplash

This post details The Proof Loop framework itself. If you’re looking for more details on the reasoning behind this, read my post on Running Experiments in the Age of AI Software Dev.

Overview

The Proof Loop is a framework for taking a vague ask from a stakeholder to a clear build decision without building the wrong thing. Every idea goes through clear stages: Stage 1: Understand the problem, Stage 2: Prove the concept is thought through and that we can build it, and Stage 3: Decide whether to build, extend, pivot, or shelve.

Throughout the loop, the team keeps one Experiment Card per idea: a short, living doc that records the problem, how you’ll know if it worked, and every decision made along the way.

The framework exists because when AI makes coding “cheap”, it’s too easy to offload the thinking as well, and a few things tend to go wrong:

  • We build before we truly understand the problem.
    • Solution: In Stage 1: Understand, the stakeholder confirms a What We Heard summary before anyone writes a plan.
  • Agents make decisions for us, and then those decisions stay in a narrow context window and end up lost.
    • Solution: In the Stage 2a: Proof of Thought, humans do the thinking (investigating the problem, possible solutions, and blockers) and log decisions in the Experiment Card so they outlive the session.
  • We get fewer chances for feedback. A prototype built in a week gets one demo instead of several.
    • Solution: Every gate is a check-in, so feedback comes at each stage instead of only at the end.
  • A polished demo gets mistaken for deployable software.
    • Solution: In Stage 2b: Proof of Concept and Stage 3: Decide, we clearly label a demo a throwaway prototype or a tracer and state its limitations and tradeoffs up front.

Each stage needs to be earned, especially the final build. You’ll treat your stakeholder as an investor who needs to explicitly fund the next stage of the process, and you earn that next stage through proving the experiment is still viable.

If you’re familiar with Hypothesis-Driven Development, this may feel familiar. However, this approach adds explicit stakeholder confirmation of the problem up front and decision gates after each stage that give clear indications of when each stage is complete.

The Loop At a Glance

Cycle diagram of the Proof Loop. Understand leads through Gate 1 to Proof of Thought, then through Gate 2 to Proof of Concept, then through Gate 3 to Decide. Learnings from Decide feed the next idea, a pivot returns to Understand, and an idea can be shelved at any gate.(open full-size image)
The Proof Loop at a glance
Stage The question it answers Timeframe We move on when…
1 · Understand What is the stakeholder actually asking for? What problem are we solving? Do we have examples? Hours to days Gate 1: The stakeholder confirms our “What We Heard” summary.
2 · Prove Can this work? Two checks, cheapest first: 2a, then 2b. Days to weeks Gate 2, then Gate 3 (below)
   ↳ 2a · Proof of Thought What issues do we foresee after thinking through this? Are those problems potentially solvable? Have we thought through the problem and surfaced new questions that need answers? Days Gate 2: No hard blockers are visible.
   ↳ 2b · Proof of Concept Do our riskiest assumptions hold when investigated further? Days to weeks Gate 3: We’ve proved the toughest parts can or cannot be built. Demo given. Stakeholder agrees with our findings.
3 · Decide Build, extend, pivot, or shelve? Days You always move on here - the question is where do you go next?
We either buy more time, revisit our hypothesis, shelve the experiment, or decide to build it out.

1. Understand

Timeframe: Hours → days

Purpose: Turn a vague ask into a clear problem statement and ensure alignment

Stage 1 is a listening exercise. You first need to ensure the problem is being communicated clearly and that everyone involved understands it in the same way.

If you can’t accurately and confidently explain the problem back to the stakeholder, you can’t explain it to your team or an agent.

Flow diagram of Stage 1. A raw ask is listened to, reflected back, and sent to the stakeholder to confirm. If they confirm, you agree on the problem and start the Experiment Card, then reach Gate 1 and move to Proof of Thought. If not, go back and ask more. With no sponsor or no appetite, the idea is shelved and the reason logged.(open full-size image)
Stage 1: from raw ask to an agreed problem

Listen

Ask about the problem, not the solution. Ask for info about what triggered this ask, examples of the problem surfacing itself, and whether anyone has attempted to solve this previously. Be an active listener.

If you’re unsure about what’s being asked or the problem presented, expose your ignorance. It’s better to have everyone know there’s a gap in communication than to say you understand and walk out of the meeting having no idea how to proceed.

See provided example questions below.

Questions

  • Trigger
    • What happened that made you ask for this?
    • Why now?
    • Has this been attempted previously?
  • Users
    • Who would use this?
    • Who communicates with them for feedback?
    • Who is our main stakeholder?
  • Outcome
    • What does success look like? (success signal)
    • What findings or metrics would cause us to shelve the project or pivot? (kill signal)
    • If this works, who owns this project long-term?
    • What happens if we do nothing?

Reflect Back

“Here’s what I’m hearing, is that right?”

This will happen a few times throughout the initial meeting, as well as in a follow-up you should send after the meeting so you get a clear yes/no. The follow-up doc should be as succinct as possible. See the What We Heard template for an example.

This stage can loop on its own. You may need to run through it a few times before feeling certain everyone is on the same page.

Agree on the Problem

Once the stakeholder confirms your understanding is correct, start the Experiment Card, the single record of this experiment that every gate adds to. In Stage 1, you’ll list out:

  • who has the problem
  • what it costs today / what the cost of doing nothing is
  • what success looks like (the success signal)
  • what result / finding would make us stop (the kill signal)
  • what’s out of scope

Gate 1: Is this worth exploring further?

  • The stakeholder has clearly confirmed What We Heard
  • A list of what is in and out of scope has been agreed on
  • A named sponsor (the stakeholder who owns this long-term) is identified, and there’s at least one success signal and one kill signal
  • The Gate 1 outcome is logged in the Experiment Card

Outcomes

  • Go to 2a. Proof of Thought, Extend (another time-boxed round of Stage 1, with the sponsor’s agreement), Pivot (update the Experiment Card with the revised problem and what you learned), or Shelve (log a reason and what we learned in the Experiment Card)
  • Docs created:
    • What We Heard, confirmed by the stakeholder
    • Experiment Card, with the Stage 1 sections filled in (problem, success signal, kill signal, out of scope)

2. Prove

Prove happens in two parts: a cheap Proof of Thought (2a), then a real Proof of Concept (2b).

2a. Proof of Thought

Timeframe: Days

Purpose: Before building anything substantial, show that we (the team, not agents) understand the problem well enough to think through it, name the hardest part, and design a way to test for it.

This is where the solution space begins and where you validate desirability and direction.

Start thinking through possible approaches. You’ll discover new questions and potential blockers along the way. Write these down. Go talk to other teams if necessary to figure out if your potential approaches are viable. Find the monkey (the hardest part of the problem) and investigate / think through the largest challenges. This may involve a quick, throwaway investigation (reading docs, hitting an API by hand), but you shouldn’t be building anything yet.

Lay out 2-3 possible ways to solve the problems with the tradeoffs of each. Use a form that people can react to: a sketch, a diagram, even a bulleted list. If you have a meeting to go through these, you’ll want something that people can look at, and ideally something you can update in front of everyone so you leave the meeting with an artifact everyone has agreed upon. Once it seems viable, add it to the Experiment Card.

The true output of this stage isn’t a document or a demo, it’s proof that the team (humans) have thought through the idea. The artifact you made (notes, sketch, diagram, etc) will likely be outdated the second you save it. That’s ok.

Human Only. The only rule here is that the Proof of Thought notes must be created by a human. Even if it’s not read by anyone else directly, it’s important that someone has thought through all of this. As you dive into the initial questions you had at the start, you’ll find more questions that need answers that you didn’t anticipate. You may not have found these if you had handed the original idea off to an AI agent.

Reviewing a document you had AI generate for you does not count. When you review an existing document, code, etc, the solution in front of you clouds your judgment and seems more solid than any potential alternatives you can think of. You’ll be able to more fairly balance competing ideas as you encounter them than when you have a proposed solution given to you.

The journey is the destination here. A teacher gives their students a book report - not because they want to read the book reports, but because the act of writing one gives students a way to think through the data in front of them and show they processed it.

See Proof of Thought by Erik Wiffin for more context.

Gate 2: Is this worth a Proof of Concept?

  • An approach has been chosen and its hypothesis has a clear pass/fail threshold
  • The stakeholder has engaged with the approach, confirmed the thought process, and agrees no hard blockers are visible
  • You have enough info to start a Proof of Concept, and the value justifies it
  • The PoC scope is limited to the 1–2 integrations that could kill the idea if not figured out
  • Everyone agrees on what the hardest part is
  • Gate 2 outcome is logged in the Experiment Card

Outcomes

  • Go to PoC, Extend (another time-boxed round of Proof of Thought, with the sponsor’s agreement), Pivot (update the Experiment Card with a new hypothesis and why you’re pivoting / what your learnings were), or Shelve (log a reason and what we learned in the Experiment Card)
  • Docs created:
    • Proof of Thought notes: human-written ONLY, any format (notes, sketch, diagram) - they don’t need to be polished
    • Experiment Card, updated with the chosen approach, hypothesis, and riskiest assumptions laid out
    • Technical ADRs for any significant technical choices made so far (if any)

2b. Proof of Concept

Timeframe: Days → weeks

Purpose: Produce evidence that the solution is viable (or not). This is the stage where high-level stakeholders have something concrete to look at, use, and discuss tradeoffs.

Activities:

  • Tackle the Monkey First - test the riskiest parts and see if your hypothesis holds.
  • Decide prototype vs. tracer. Decide up front whether the code is throwaway (this is ok, but make this a clear part of the plan) or keepable. AI tools make it easy to blur the two.
    • Tracer: If you want to keep it, it’s probably best to use a tracer: a slim, end-to-end slice. Build it around the monkey, the feature that would kill the project if you couldn’t solve it.
    • Prototype:
      • Throwaway code that’s built to learn, not to keep
      • Try to get real users (2-5): measure whether they act on the output, not just whether they like it
      • Behavior beats opinion. Compliments and generic statements are not evidence. Do people actually use it? Does it solve their problems?
  • Team autonomy - Within the time budget, scope, and problem-space, teams can change stories, specs, tools, and approach without needing permission (DORA team experimentation). The hypothesis and problem stay fixed, but everything else can move. Developers should talk to potential users directly.

Gate 3: Demo

  • Demo the Proof of Concept for the stakeholder
  • Show the good and bad parts. Be honest with what it’s capable of, where it falls short, where things could be improved given more time, and where there are still questions or parts you’re unsure could be overcome.
  • We’ve proved the toughest parts can or cannot be built
  • Stakeholder agrees with our findings
  • Gate 3 outcome is logged in the Experiment Card

Outcomes

  • Move to Decide with the evidence you’ve created
  • Docs created:
    • The Proof of Concept itself, with the pros/cons, labeled honestly as a throwaway prototype or a tracer
    • Findings from the demo: what worked, what didn’t, what’s still unknown, results against success and kill signals
    • Technical ADRs for significant choices made while building the PoC.

3. Decide

Timeframe: Days

Purpose: Make a final call. Given what you’ve learned so far, does everyone think it should be built, extended, pivoted, or shelved?

Outcomes

  • Build - the experiment proved the hypothesis and you can move on to a larger build
  • Extend - buy more time for another short, clear stage. Make sure this is time-boxed
  • Pivot - revisit the hypothesis completely - did you solve the wrong problem? Did you find out the problem wasn’t as bad as initially thought? Could an off-the-shelf solution solve it more cheaply?
  • Shelve - the hypothesis didn’t hold, or the costs are too high, or the appetite just isn’t there at the moment. Document your learnings and this experiment gets put on the shelf. If things change, you’ll want everything documented so you can pick it back up.
  • Docs created:
    • A final entry in the Experiment Card’s decision log. Did your hypothesis hold? What did the team + stakeholder decide?

The loop ends when the project is shelved or gets the green light for a larger build. Extend and Pivot send you back through a stage.

The prior stages are all in what Kent Beck describes as an “Explore” phase. The Decide stage is where things can move to the “Expand” phase, where production work is started. It’s still cheap to kill projects in the Explore phase, but a larger investment is required to move to Expand. Expand requires removing bottlenecks, hardening systems, scaling, and more ownership.

Practical Notes

  1. Understand before you plan. No plans, estimates, or architecture until the stakeholder confirms “Yes, that’s what I’m asking for.”
  2. Treat the stakeholder as an investor. You need to get funding from them to pay for the next stage. Hours and tokens still have a cost, and so does building the wrong thing.
  3. Get problem-shaped asks. “Build us an agent that does X” is a vague ask. We need to translate that into a problem statement and only then can we start to investigate what the solution is.
  4. Define your kill signal and success signal up front to reduce bias. This defines whether you “pivot or persevere” as Hypothesis-Driven Development puts it. Don’t let sunk cost and demo excitement push you to persevere when you should pivot.
  5. A cheap kill is a win. Every idea you stop early is time, money, and tokens you didn’t spend on the wrong build.
  6. Always leave a record. Every gate gets a dated entry in the Experiment Card’s decision log, no matter the outcome. “Failed” experiments and dead ideas still teach us something.
  7. Every stage is time-boxed.
    1. You choose the timing within the given range (e.g. Stage 1 is hours-days, Stage 2a is days, etc.)
    2. You can extend, but more time must be earned
  8. Building with AI Tools is fine/encouraged, but:
    1. a human must be able to explain every gate artifact and the code paths that matter without notes (the same bar as the Proof of Thought)
    2. the success signal is written from real scenarios before any code is written, not by an agent based on the solution
    3. the PoC is labeled honestly as a throwaway or a tracer
  9. WIP limits. AI tooling encourages teams to build many PoCs at once. Limit this. Stop starting, start finishing (making decisions)

Tools & Templates

Docs, especially technical ADRs, should live in source control co-located with the code itself. Experiment docs can also live in the repo, but keep them separate from technical ADRs. Here’s an example structure:

docs/
├── EXPERIMENT.md     # problem, signals, approach, hypothesis, decision log
├── notes/            # What We Heard, proof of thought, findings: any format
└── adr/              # technical ADRs, only when needed

Store the Experiment Card wherever your team already looks for work: an existing team repo, a wiki space, or the ticket that started the ask. Link it from that original ask, so anyone who revisits the idea can find the record even if the experiment never reaches a build stage. If the experiment does reach a build stage, move the docs into the codebase.

What We Heard

This can be an email or a message. If you keep it in the repo, put it in docs/notes/.

Show the template
# What We Heard: [Ask, in the stakeholder's words]

To: [Stakeholder] From: [Team] Date: YYYY-MM-DD Round: 1

## What we're hearing

2–4 sentences in plain language, using their words where possible.
"Here's what we're hearing you're asking for: ... Is that right?"

## What we're inferring (please correct us)

- ...

## Not in scope

- ...

## Open questions

- Who owns what? Which data is involved, and who approves access? Who runs it afterwards?

---

Confirmed by [name] on [date]

Experiment Card

The hypothesis follows Barry O’Reilly’s hypothesis-driven development format from Thoughtworks, and the overall card is adapted from the Test Card in Testing Business Ideas (David Bland & Alex Osterwalder, creator of the Business Model Canvas). The decision log’s prompts are loosely based on the Learning Card from the same book. The kill signal’s “what result, by what date” follows Annie Duke’s kill criteria in Quit.

docs/EXPERIMENT.md

Show the template
# Experiment: [Name]

Sponsor: [Name]

## Problem (Stage 1)

Who has it, how often, what it costs today.

## Success signal (Stage 1)

[Metric + threshold]

## Kill signal (Stage 1)

[What result or finding, by what date, would make us stop]

## Out of scope (Stage 1)

- ...

## Chosen approach (Stage 2a)

[Approach], chosen over [alternatives] because [reason]

## Hypothesis (Stage 2a)

We believe [solution] will [outcome] for [user], measured by [metric].

## Riskiest assumptions, ranked (Stage 2a)

1. ...

## Decision log

Add a dated entry at every gate, whatever the outcome. A person writes it, and a few lines is enough:
the decision, why (compared with the success and kill signals), and what's next.
If it helps, think in terms of: what we believed, what we observed, what we learned, what we'll do next.

2026-10-05, Gate 1: Go. Sponsor confirmed What We Heard; success = <success signal>; kill = <kill signal>. Proof of Thought next, a few days.

2026-10-12, Gate 2: Go. 4 of 5 pilot devs chose option A and no auth blockers turned up.
Data access looks like the real risk, not hosting. PoC on option A, two weeks.

Technical ADR (as needed)

docs/adr/ADR-001-*.md

I like this MADR template from the architectural decision record github, but choose whichever ADR format you like as long as it captures the reasoning behind decisions.

Sources

// share this post
Share on BlueskyBlueskyShare on LinkedInLinkedIn
GrainCoin.exe

Congratulations! You found GrainCoin!

You have discovered the secret of the Arcane Grain. Your wallet now holds 0.0001 GrainCoin, redeemable for absolutely nothing. Please do not tell the webmaster.