4.3.2 - How Would You Know If Any of This Worked?

Evidence it worked

You have written it all down. What actually tells you it made any difference?

The call

Take three numbers before you write anything and again as you go. Decide now which one you would act on, because two of them are interesting and only one of them matters.

Sharpen evidence it worked with AI

This is a Run idea, so the AI move is Run it for real. This one is different from the rest: the prompt does not sharpen a sentence, it takes the reading and hands you the numbers.

New here? Let your AI do this with you. Paste your problem into Guide me and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt.

Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see how to use vibe2value.

There is nothing to replace in this one. Point an AI at your project, paste it as it is and read what comes back. Run it once before you write anything, then again whenever you want to know if it is still working.

Reading your own work honestly is the hard part, which is why Review with fresh eyes exists, along with Guard against false positives.

The same idea on a recipe card

You think the oven is at 180 because the dial says 180. Until you put a thermometer in, you are cooking on the dial's opinion of itself.

Cooks who never take the reading do not find out the oven is wrong. They find out that everything comes out slightly off, blame the recipe and adjust the wrong thing for years.

The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See the recipe card.

What it really means

Writing things down feels productive. That is the problem, because it goes on feeling productive long after it has stopped changing anything. There is no point at which it announces itself as busywork.

Every idea in this framework has its own pass and fail, so you can tell whether one answer is good. None of them tells you whether the whole thing is working. That gap sits exactly where a person is deciding whether the effort was worth repeating.

Three numbers close it. How much an AI invented about your project, how many gaps it named instead of filling, plus how big the base has got. Invented is the one that matters. The other two are context for it.

One honest limit. An AI reporting on what it invented is a starting list rather than a verdict, because it does not know which of its confident statements are false. You do. That is the whole reason this measure works and it is also why you cannot skip reading it yourself.

Make evidence it worked concrete

Compare the version that sounds encouraging with the version somebody could argue with.

• Too vague: It definitely helps. The AI seems to pick things up much faster now.
• Concrete enough to act on: Before I wrote anything down, the AI invented a dashboard and a draft-writing step that consideredContent does not have, and it named no gaps. After the Shape and Build files it invented nothing, and it named four gaps, including that Run and Close were not written yet.

The second version can be wrong, which is what makes it worth having. The first cannot be wrong about anything.

Both versions come from consideredContent, the one project carried through all 35 ideas. See the project.

Check evidence it worked

• Pass: You have a baseline taken before you wrote anything, a later reading to compare it against, with invented falling.
• Fail: You have never taken the number, so "it feels better" is the only evidence you have.

A number you have never taken cannot go down.

What you'll walk away with

This post is about the running decision: what has to be true once the thing is already live. You'll come out with your own knowledge-base/README.md carrying a baseline row with a date on it, at least one later reading beside it and a decision about which of the three numbers you would actually act on.

Write it down

The readings go in a table in your README.md, because a scoreboard belongs on the front of the thing it is scoring. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build.

knowledge-base/README.md is just a suggested place for this. Put it wherever suits your project. What matters is that the numbers have dates on them and that the first one was taken before you started.

Risk and mitigation

• Risk: You keep writing things down because it feels productive, long after it stopped changing what the AI does.
• Mitigation: Take the baseline before you write a word. It costs one run. It is the only reading you can never go back for.

Key takeaway

Take the baseline before you write anything. It is the only reading you cannot get later.

How to document your evidence it worked

Keep the readings together with a date on each one, so the trend is visible rather than remembered. Keep it in a file with your project like this.

# Evidence it worked

## Answer
| Date | Invented | Named gaps | Size | Note |
|---|---|---|---|---|
| | | | | baseline, before anything was filled in |

## Evidence
What you actually saw change in how the AI behaves, not what you hoped for.

## Decision
Which number you act on and what you do when it stops falling.

## Risk
What breaks if this is wrong.

## Standing instruction
What the AI should do every time it touches this. For example: when you state something about this project that is not written down anywhere in the repo, mark it rather than asserting it.