Most product beliefs are invisible: held confidently, never written down, never checked. The register makes them explicit and settleable. Each entry states a belief, the question that would falsify it, the signal that answers the question, and the threshold that decides — recorded before the answer is known.
Anatomy of an entry
- Belief — what you currently assume is true.
- Falsifiable question — the question whose answer could prove it wrong.
- Signal — the measurement that answers it, in the grammar below.
- Threshold — the number and direction that decide, set before you look.
- Verdict — untested, holds, refuted or verified, with append-only history.
Entries begin as drafts. The agent drafts them from your repository, your evidence and its own reasoning while it builds; committing one is always yours to do, and only committed entries can be ruled. Drafts carry a disposition — accept, amend, challenge or dismiss — so disagreement is recorded rather than lost.
The signal grammar
A signal is prose with a small runnable grammar embedded in it. Write it however reads best; Sightspool parses the parts it can run and ignores the rest.
checkout.started -> checkout.completed (a funnel, matched per person)
unique(report.exported) (unique users doing something)
count(support.ticket_created) (raw event volume)
rate($rageclick / $pageview) (how often something happens to people)
returned(signed_in, dormant 7d) (who lapsed, and came back)
scroll_depth(>= 75%) (how much of the page people reach)
window 30d how far back to look (default: 30 days)
min_n 50 the sample floor below which no verdict is allowed (default: 30)
on /checkout limit a rate or scroll depth to one part of your productFunnels are matched per person and in order: someone who did the second step without the first never counts, so a conversion rate can never exceed 100%. Below the sample floor the entry reports how far it has to go — "still gathering, n=7 of min_n 50" — and stays unruled. If the signal names an event your source has never emitted, that is reported as a measurement problem, never as a measured zero.
The last three shapes answer the questions teams usually reach for a recording tool to settle, using events your analytics already collects. A rate is the share of the people who did the second thing who also did the first, so rate($rageclick / $pageview) reads as the share of visitors who rage-clicked. Resurrection asks who had been gone: the base is the people who lapsed for the dormant period, not everyone, and someone with no earlier history is a new user rather than a returner. Scroll depth is measured per page view, and a view that carries no scroll data is left out of the base rather than counted as nobody scrolling.
Frustration, scroll and resurrection signals depend on your analytics capturing them — autocapture and scroll tracking in PostHog's case. If they are switched off, the entry says so instead of reporting that nothing happened.
Who may rule what
A measured read can rule an entry holds or refuted. Only a human can rule it verified, and only a human can reopen a settled entry. This is enforced in the system, not asked of the model: there is no path by which an agent asserts that something is verified.
Re-arming when you ship
An entry can declare the paths it depends on. When commits touch those paths, holds and refuted revert to untested and go back under watch — the belief was settled against code that has since changed. A verified entry is never silently reverted; it is flagged for a human to re-check. Changes to surfaces no entry covers run the other way: they draft new candidate entries for you to accept or dismiss.
Writing verdicts back to your coding agent
Settled verdicts are only useful if they reach the place decisions get made — which, increasingly, is a coding agent reading your repository's context file. Sightspool renders ruled verdicts as a conventions block you paste into CLAUDE.md, AGENTS.md or the equivalent.
<!-- sightspool:verdicts:start -->
- **Rely on this:** Users who start an assessment complete it unaided
(verified 2026-07-18, 74% of n=412).
- **Do NOT assume:** New accounts discover bulk export on their own
(refuted 2026-07-22, 6% of n=380).
<!-- sightspool:verdicts:end -->Verified and refuted entries state their conclusion firmly. Entries that merely hold are marked provisional and carry their observed value and sample size, so an agent can weigh them accordingly. Entries still gathering, untested entries and drafts are never exported — a block that included them would launder uncertainty into instruction.