Hypotheses

What makes a good hypothesis

A good hypothesis has three properties. Getting all three right is what separates a belief that can teach you something from one that just sounds reasonable:

1. Falsifiable — there must be a world where it turns out to be wrong. "Users would benefit from better onboarding" is not falsifiable. "Adding a progress indicator to the onboarding flow will increase completion rate by 15% within 30 days" is. If you can't imagine evidence that would prove it false, it's not a hypothesis — it's a preference.
2. Specific — it names a metric, a direction, and a timeframe. Vague hypotheses produce vague outcomes. Vague outcomes teach you nothing and leave you in the same place you started.
3. Linked to evidence — it should trace back to at least one signal. A hypothesis with no signals is a guess. It's still valid to write down and test, but treat it as lower confidence and prioritize evidence-backed alternatives first.

“You're not asking "what should we build?" You're asking "what do we believe, and how wrong could we be?"”

Anatomy of a hypothesis

Each hypothesis has six structured fields. Together they form the contract that Findry uses to measure outcomes after you ship:

• Belief statement — the core claim in the format: "We believe that [doing X] will result in [outcome Y] for [user segment Z]." Writing it this way forces specificity and surfaces assumptions you might otherwise leave implicit.
• Metric — the specific metric you expect to move. Links to your project's metric library so you're measuring the same number as your analytics stack.
• Direction — increase or decrease. Explicit. No ambiguity about what "moved" means.
• Magnitude — expected size of the change (+15%, −20 seconds, +200 users). The number you're committing to before you ship. It will be compared to the actual number when you close the outcome.
• Timeframe — how long after shipping before you expect to see the movement. Keeps outcomes from being measured too early and declared falsely positive or negative.
• Confidence — how confident you are before testing (Low / Medium / High). This is pre-test confidence, separate from the evidence strength score computed from your linked signals.

The metric + direction + magnitude + timeframe fields become the prediction contract with Outcomes. When you ship the bet built from this hypothesis, Findry uses this structure to compute variance between what you predicted and what actually happened.

Creating a hypothesis

There are two paths:

1. From a signal — open a signal and click Create hypothesis. The signal is pre-linked. Fill in the belief statement and metric fields. This is the recommended path — it keeps the evidence chain intact from the first moment.
2. From scratch — click + Hypothesis in the sidebar. You can link signals after creation by searching your signal library from the hypothesis detail view.

The state machine

A hypothesis moves through up to six states over its lifetime. Each transition is intentional:

• Open — newly created, not yet validated. Ready to be linked to tests. This is the starting state for all hypotheses.
• Testing — one or more active tests are running against it. Findry sets this automatically when you create a test linked to this hypothesis.
• Supported — tests concluded with evidence in favor. The hypothesis is ready to be promoted to a Bet.
• Refuted — tests concluded against it. The evidence suggests the belief was wrong. Refuted hypotheses are archived automatically after 30 days unless you reopen them with new evidence.
• Promoted — the hypothesis became a Bet. This is a terminal state — the Bet carries the work forward from here. You cannot demote a Promoted hypothesis.
• Archived — manually or automatically closed. Can be reopened if new signals make it worth revisiting.

Transitions are enforced by the system. You can't promote a hypothesis that isn't Supported, and you can't move from Promoted back to any earlier state. This is intentional: it prevents the evidence chain from being retrofitted after the fact. The reasoning behind a decision needs to have been built before the decision was made — not reconstructed afterward to justify it.

Evidence strength

Each hypothesis has an evidence strength score from 0 to 100, computed from its linked signals and test conclusions. The score is visible on the hypothesis card and updates live as you add or remove evidence.

The calculation weighs three things:

• Number of signals — more linked signals raises the score. Diversity of source type matters too; five signals from five different sources outweigh five from the same interview.
• Signal confidence — High-confidence signals contribute more than Low-confidence ones. A verbatim customer quote counts more than a team hunch.
• Test conclusions — a Supported test conclusion adds significant weight to the score; a Refuted conclusion subtracts. This is where the score moves the most, because test conclusions are the strongest form of evidence in the system.

A score below 30 means thin evidence — consider adding more signals before running a test. A score of 60 or above means you have a solid evidence base and the hypothesis is ready to be taken seriously. The threshold for promotion is configurable per workspace; the default is 60.

AI suggestions

Findry can suggest hypotheses from your signal backlog. Click Suggest hypotheses on the Hypotheses page. The AI clusters your unlinked signals by theme and proposes belief statements you haven't written yet — belief statements that have supporting evidence already sitting in your signal library.

These are suggestions, not decisions. Review each one, edit the belief statement to match your actual thinking, and confirm the supporting signals before saving. The AI is surfacing patterns; you're the one deciding whether those patterns are worth turning into a belief worth testing.