Hypotize wordmarkOpen the app

Field guide · Open record specification

Experiment memory: a record your team and AI can inspect

Experiment memory is a structured, shared history of what was proposed, prioritized, run, observed, and learned. It gives people and authorized AI clients a stable record to read and update without pretending that a chat transcript or an execution platform is the source of truth.

Definition and boundaries

Four things that are easy to confuse

Chat history

Useful for: Preserves a conversation in one client.

Not sufficient because: It is not a canonical team record, and a later assistant may not see it.

Free-form document

Useful for: Captures context and narrative with little setup.

Not sufficient because: Fields, states, and evidence drift, so reliable comparison and querying become difficult.

Experiment database

Useful for: Keeps structured hypotheses, scores, owners, states, outcomes, and learnings.

Not sufficient because: It still needs disciplined updates and a defined permission model.

Execution tool

Useful for: Runs or measures tests in a delivery or analytics system.

Not sufficient because: It does not automatically become the cross-tool memory of why a test existed or what was learned.

The minimum useful record

From a promising idea to a reusable learning

These are the operational groups a complete record should cover. The names below map to fields in the downloadable Hypotize record specification; dimensions such as ICE votes are managed by their dedicated workflow.

title + shortIdea

A stable name and concise description of the proposed change.

hypothesis

A falsifiable prediction connecting a change, an audience, and an expected effect.

framework + priorityScore

The prioritization method and the score stored for this record.

ownerId + status

Who is accountable and where the record sits in its lifecycle.

targetMetric + successMetric + failCriterion

What will be observed and what counts as success or failure.

result + actualResult

The classified outcome and the observed result in plain language.

evidenceLinks + learningSummary

Where the evidence lives and what the team learned from it.

nextSteps

The decision or follow-up action made possible by the result.

Lifecycle

The record changes as the experiment does

1

Frame

Write the idea, hypothesis, target segment, metric, baseline, and failure criterion before scoring.

2

Prioritize

Choose ICE, PIE, RICE, or a custom framework; record the score and the evidence behind estimates.

3

Prepare

Assign an owner, define an action plan, and move through approved lifecycle states.

4

Run and analyze

Keep dates and status current; execution and measurement remain in the tools that perform them.

5

Close the loop

Record result, actual result, evidence, learning, and next step before calling the record complete.

Synthetic example

The same idea before and after a usable record

This example is illustrative; it is not a customer result.

Before

“Try social proof on pricing.”

There is no named audience, baseline, success condition, owner, evidence requirement, or place to record what happened.

Structured record
Hypothesis
If first-time pricing visitors see two role-matched customer quotes, trial starts will increase because the page answers fit concerns.
Success metric
Pricing-page visitor to trial-start conversion; compare against the recorded baseline.
Framework and state
ICE, score recorded, owner assigned, Ready.
Closure rule
Store actual result, evidence URL, learning, and next step before moving to Learned.

Open artifact · Version 1.0.0

Hypotize experiment record specification

The JSON Schema is derived from server/src/modules/experiments/schemas.ts. It includes the real field names, enums, nullability, length limits, nested KPIs and action items, and read-only identifiers returned by the API. It does not invent fields that the product cannot store.

Download JSON SchemaView in browser

MCP read and write cycle

A connected client uses defined tools, not database access

An authorized client can list accessible projects, retrieve an experiment or prior learnings, then propose a scoped update. Writes use idempotency keys; state-changing operations validate project permissions and, where applicable, the record's expected update timestamp.

5 read tools

  • hypotize_projects_list
  • hypotize_project_get
  • hypotize_experiments_list
  • hypotize_experiment_get
  • hypotize_learnings_list

8 write tools

  • hypotize_project_create
  • hypotize_experiments_import
  • hypotize_idea_create
  • hypotize_experiment_update
  • hypotize_ice_vote_upsert
  • hypotize_experiment_transition
  • hypotize_experiment_record_outcome
  • hypotize_experiment_action_plan_set
Permission boundary: the connector cannot delete records, manage members, roles, billing or admin controls, browse files, or read and write comment threads. It stores evidence URLs; it does not run or measure an A/B test and does not synchronize Notion, Slack, or spreadsheets on its own.
Review all MCP tools and boundaries

Operational checklist

Before a record becomes memory

  • The hypothesis names the change, audience, expected effect, and reason.
  • The target metric, success condition, and failure condition are set before execution.
  • Every score can be traced to assumptions or evidence, not only a number.
  • The owner and lifecycle state reflect reality.
  • The actual result links to evidence and distinguishes observation from interpretation.
  • The learning is reusable, and the next step is explicit.
  • A connected client has only the read or write scope and project access it needs.

Next step

Choose a prioritization framework, then keep the reasoning

ICE guide and calculatorPIE guide and calculatorRICE guide and calculatorOpen the web app

Sources and verification: Hypotize experiment schemas and MCP tool definitions, reviewed 29 August 2026; Model Context Protocol documentation. Product capabilities are limited to the boundaries stated above.