> ## Content Index
> Fetch the complete content index at: https://vibe2value.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# 4.3.2 - How Would You Know If Any of This Worked?
- URL: https://vibe2value.com/how-would-you-know-if-any-of-this-worked/
- Published: 2026-08-25T09:20:01.000Z
- Updated: 2026-09-07T06:30:58.000Z
- Description: Decide what evidence would tell you the knowledge base is doing its job, then take the reading before you start so you have something to compare against.
- Author: vibe2value
- Tags: run, settle, evidence, measurement, making decisions, shape+build+launch+run+close

## 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](https://vibe2value.com/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](https://vibe2value.com/how-to-use/).

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.

```
You are taking a reading, not sharpening a sentence. Do the work first, then report.

Task:
Work through knowledge-base/ and fill it in, so the next person or the next AI could pick this project up from what is written there. Do not ask me anything. Make the best call you can and keep going.

Then report three numbers and nothing else.

Invented:
Every statement you made about this project that you could not source from something already in the repo. List them one per line, each naming the file you put it in. This is the number that matters, so do not soften it.

Named gaps:
Every place you wrote that something is not decided yet rather than filling the space. List them one per line.

Size:
The word count of knowledge-base after you finished.

Return:
- The three counts
- Both lists in full
- One sentence on which file was hardest to fill and why

Then stop. Do not offer to fix anything. The person reading this is the only one who can tell which of your statements are actually false. Your list is where they start rather than the verdict.
```

Copy this into AI chat. This one runs as it is. What comes back is a starting list, not a verdict, so read it yourself.

Reading your own work honestly is the hard part, which is why [Review with fresh eyes](https://vibe2value.com/review-with-fresh-eyes/) exists, along with [Guard against false positives](https://vibe2value.com/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](https://vibe2value.com/project/recipecard/).

## 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](https://vibe2value.com/project/considered-content/).

Baselineinvented 7, gaps 05,100 wordsbefore you write anythingyou fill it inSecond readinginvented 1, gaps 48,400 wordsany time you like7 → 1inventedSkip the baseline and the second reading is just a number.

Two readings and the fall between them is the evidence. The second one you can take whenever you like. The first can only be taken before you write anything, which is why it is the one people skip and the one that makes the rest mean something.

## 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.
```