Skip to concept
Protopilot
PROTOPILOT Research proof / self-study Sheet 01 of 01

Follow the data Validate before build

What did people do, and what should change?

A fast build only proves that software can be made. Protopilot makes the costly problem, the claim that could fail, and the smallest testable experience part of one evidence chain.

Direct answer

Use what people do to decide what changes next.

Question
Will product leads create a tester flow before asking engineering to build?
Method
The costly problem, claim that could fail, and smallest testable experience in one evidence chain.
Expected signal
Returned evidence changes the assumption that requested it—or honestly keeps the claim open.

Simulated session

Record what happened, separately.

Was this tester in the target audience?
Was a test-ready action observed?
What happened when the tester tried the selected task?

What this session can change

Keep the evidence with its assumption.

The target-audience qualifier is still needed.

Local simulation · not recorded.

Next loop: explore possibilities

Build-first interruption

Output is not a decision.

Speed compresses the build, not the uncertainty. Without an explicit audience, costly situation, and falsifiable claim, polish is only harder to question.

Move the question ahead of the build.

One transforming artifact

How the decision is tested.

Each space changes the same research object. Nothing downstream floats free of the assumption it is meant to test.

  1. Problem space source material

    Make the expensive guess visible.

    Purpose
    Help product teams test the assumptions beneath an idea before they commit to building it.
    Audience
    Product teams using AI-assisted builders who need evidence before committing engineering time.
    Persona
    Product lead — Leads a small product team and worries that AI speed turns untested assumptions into commitments.
    Blocking problem
    Teams turn untested assumptions into polished software too early, making it expensive to learn whether a real problem exists.
  2. Hypothesis space risk turned into a claim

    Give the belief a way to lose.

    H-03 Solution claim · usage test
    “After framing a problem and hypotheses, product leads will create a tester flow before asking engineering to build.”
    Starting confidence
    0.55
    Can change by
    Observed usage
    Linked problem
    P-01

    If the action does not happen, do not add features. Revisit the claim or the problem framing.

  3. Solution space minimum test instrument

    Build only what the claim requires.

    01 screen

    Establish Context

    Capture the audience, persona, and costly situation before choosing a solution.

    02 screen

    Make assumptions falsifiable

    Turn beliefs into linked hypotheses with a confidence and test method.

    03 screen

    Compose a tester flow

    Connect a prototype journey and screener to the assumption it should test.

    Domain objects Project → Assumption → Test flow

    Design language Connected space switcher + evidence status

    Stop condition The tester can attempt the H-03 action

Separate tester flow

How evidence returns.

The prototype becomes a focused test: screen for relevant context, observe one action, then route the result back to the claim—not into a fourth workspace.

TESTER REPORT TR / H-03 / PRE-RUN

Protopilot · From problem to test plan

01 / Screened context

Does your team currently use AI-assisted tools to explore or build product ideas?

Yes → qualifiesNo → exits

02 / Observed action

Creates a tester flow before asking engineering to build.

No run recorded yet

Evidence travels back to the assumption that requested it.

Run the next proof

Start with the decision.

Frame the costly situation, write the claim that can lose, and compose only the test needed to learn.

Open Protopilot