Motherbrain | Nathan Allen

A test result is useful only if the next person can find it

My creative work already involved looking back through previous tests to identify patterns. Motherbrain turns that practice into a structured product: a place to connect what changed, what happened, and what might be worth trying next.

The intended users are the people planning and reviewing experiments. They need more than a folder of screenshots or a list of winning percentages. They need enough context to understand when an earlier result is relevant.

Blue hearing aid photographed on a dark stone pedestal — Supplied product creative, used here to illustrate the kind of visual material an experiment record could preserve.

Blue and red hearing aids hovering over a charging case on blue — Another supplied product direction. This pair is not presented as an actual Motherbrain experiment.

Start with the work people already have

The entry flow asks for a test name, a hypothesis, and screenshots of the control and variants. More detailed inputs sit behind an optional disclosure. In the prototype, the team can add variants without leaving the entry flow.

That choice reduces the amount of manual description needed to get started. AI can extract page attributes and compare the screenshots, while the person running the test supplies the intent. Those are different kinds of knowledge, and the system needs both.

Actual Motherbrain New Test Entry interface: the hypothesis and source images stay together.

Separate extraction, interpretation, and evidence

The implementation connects an HTML dashboard to n8n workflows, PostgreSQL, and Claude. Separate prompts handle screenshot extraction, visual comparison, deeper analysis, and pattern updates.

The data model keeps a structured test record and a separate pattern library. The workflow includes a review-and-confirm step before the extracted information is stored. AI-generated interpretation should be inspectable, rather than silently becoming the record of what happened.

01CaptureHypothesis, control, variants
02ReviewAI extraction + human confirmation
03LearnResults + a structured pattern library

Reconstructed process summary based on the project materials.

A useful system has to remember contradictions

The pattern-update prompt tells the model to keep single-test observations low-confidence and emerging. It also includes counter-evidence, weakening patterns, and the conditions under which an apparent rule stopped holding.

That is a consequential design choice. A growing collection of confident-sounding summaries could reinforce the wrong assumption. The structure makes room for uncertainty and for results that change the team’s mind.

The chat layer can query the accumulated information, but its usefulness depends on the quality of that record. Fluent answers are not evidence that a prediction is accurate.

01EmergingA single observation, low confidence
02ReinforcedAdditional supporting results
03ChallengedCounter-evidence changes the conclusion

Reconstructed process summary based on the project materials.

What is built, and what is not yet proven

The supplied implementation includes the dashboard, database schemas, orchestration flows, and prompts. The local preview makes the entry and navigation design inspectable. It uses a sample payload, and its external API actions are not connected in that preview.

I do not claim an improvement in test win rate or prediction accuracy. Those outcomes would require evaluation against held-out experiments and a clear comparison with the team’s existing planning process.

My next evaluation would look at extraction accuracy, review time, retrieval usefulness, and whether a suggested rationale actually cites the relevant prior tests. Those are concrete ways to tell whether the system helps people make better decisions.