Ship and prove a change
The loop that separates a change you can prove from a change you can only claim: approve it in the ledger, ship it, let it be observed, then let it be confirmed.
The difference between a change you can prove and a change you can only claim is one step, and it happens before you ship. This is that loop.
What you'll learn
- Why approval has to happen before the change goes live
- The four steps from proposal to Confirmed moved
- The mistakes that leave a change permanently unmeasurable
Step 1: Approve it before you ship it
Open This week or ask "Where should I focus first, and what is it worth?", pick the row, read what it involves, and approve it.
Approval is not a status change. It captures the control the outcome will later be scored against, on the metric the change is meant to move. Without a control there is nothing to compare a later measurement to, and the change ends up marked Not measurable no matter how well it worked.
This is the single most common mistake. A change shipped outside the ledger can never reach Confirmed moved, because the moment to capture its baseline has passed.
Step 2: Ship it
Make the change on the page. The change carries assertions: the specific things that should be true on the page afterwards. Read them before you ship, because they are what the platform will check.
If you changed something different from what the change describes, say so on the change rather than letting the assertions fail silently.
Step 3: Let it be observed
The platform fetches the page itself and checks the assertions. When they hold, the change moves to Observed live.
Until then it sits at Attested, which means a person said it shipped. Your word is recorded as your word and is never treated as a measurement.
If it stays at Attested, the usual causes are: the change went to a different URL from the one recorded, the page is behind a login or a bot wall, or the assertions describe something the page does not actually do.
Step 4: Let it be confirmed
Once enough evidence accumulates, the affected prompts are re-measured against the control and the change moves to Confirmed moved.
The bar is at least eight checks since shipping, across at least two surfaces. Below that the sample cannot carry the conclusion, and the change reports Not measurable with the reason "sample too small" rather than a result.
What can go wrong, and what it means
| State | What happened | What to do |
|---|---|---|
| Attested for weeks | No fetch has confirmed it live | Check the URL on the change and whether the page is reachable |
| Not measurable: no control | It was approved after shipping, or outside the ledger | Nothing to recover. Run the next one through the ledger |
| Not measurable: metric mismatch | The control and the outcome measure different things | Re-state the change against the metric you actually want to move |
| Drifted | It was live, and the page has stopped satisfying it | Somebody edited or redeployed. Restore it, then re-observe |
Why bother
Because without it every conversation about AI visibility is anecdote. A ledger of changes with observed and confirmed states is the only thing that lets you say "we did this, the answers moved, here is the control" to a client or a board.
Try this in Outercite
Open the ledger, filter to Not measurable, and read the reasons. Then ship your next change through the approval flow and watch it climb.
Related
Changes
The ledger, the tiers and the Review.
This week
Choosing which change to ship first.
The six-level stack
Which level a change is addressing, and why that matters.
Last updated on