Silos: how experiments are kept apart

An architecture and a flow: what an experiment may use, what happens when a change breaks that, and how code is reused by copying.
The brief and requirements every method got

This repository holds many experiments (prototypes and features) that often contradict each other on purpose. Document how they are kept apart: what an experiment may use from elsewhere, what happens when a change breaks that, and how code is reused by copying. Give everyone (developers, designers, product) a short overview of what this means and why; then the technical detail for developers.

  • Show, don’t tell: live pages, diagrams, tables, links, code
  • First screen: the thing itself and one line
  • Only the words needed
  • One fact per paragraph
  • Link every page mentioned
  • Diagrams wherever there is structure or a sequence

Silos

Each experiment is sealed off: it uses only its own code and the shared platform, never another experiment.

Who may use whatExperiments each use only themselves and the platform; the reference is read only by the docs; arrows from one experiment to another are not allowed.

Why

Experiments test ideas that often contradict each other, and im-web, on purpose.

If one experiment used another's code, a change made for one idea would silently change the other. Sealing them keeps each test honest.

What this means

You areWhat it means for you
Designer, product ownerAn experiment behaves only as decided for it. Changing Baseline never changes Receipt, even where they look the same.
Designer, product ownerTwo experiments may disagree on a rule. That is allowed, and nothing forces them to match.
DeveloperImport only from your own experiment folder and src/platform. Everything else, copy.
DeveloperA forbidden import is caught after each edit Claude makes and before every commit.

What lives where

FolderWhat's in itWho may use it
src/routes/prototypes/<id>/, src/routes/features/<id>/One experiment: its docs, app and codeOnly itself
src/platform/Neutral building blocks: UI components, formatters, media fixtures, the docs shell, the statechart engine, design tokensEvery experiment
src/reference/im-web today, team proposals, and the working modelOnly the docs pages
src/routes/docs/, root routesThe docs and the lists of prototypes and featuresNobody

Reuse means copying

Baseline shows receipts. It does not use the Receipt feature's code; it has its own copy.

The Receipt feature The original. Baseline and Product admin each render receipts from their own copy of this code.Open

The copy belongs to Baseline from then on. Receipt can change without Baseline noticing, and the other way round.

To bring an improvement across, someone copies it again on purpose.

More

About silos

Why every experiment is sealed off from the others, and what that costs.

What an experiment may importTwo experiments each import only their own folder and the platform; imports between experiments or from the reference are refused.

Each prototype and feature is a silo: it may use its own folder and the shared platform, nothing else.

Experiments disagree on purpose

The repository tests competing ideas side by side: business rules, terminology, whole concepts. Two experiments may answer the same question in opposite ways, and both answers should be testable.

The prototypes Each prototype on this list is its own silo.Open
The features Features are silos too.Open

If one experiment imported another, a change in one could quietly change what the other shows in a user test. Sealing them means nothing has to stay compatible across experiments.

What is shared, and why it stays neutral

The platform (src/platform/) is the only shared code: UI components, formatters, media fixtures, the docs shell, the chart engine, design tokens. It holds mechanisms, never product decisions, because a change there reaches every silo at once.

The reference (src/reference/) describes im-web today, team proposals and the working model. Experiments start from it but never import it; they take a copy and own it.

Reuse means copying

To use another experiment's code, you copy it into your own experiment. The copy lands in a folder named after its source, such as -lib/from-receipt/ in Baseline.

The same receipt, owned twiceThe receipt feature's code is copied into Baseline, which renders its own receipts from the copy.

From then on the two versions may drift apart. Baseline can change its receipt without asking the receipt feature, and the reverse.

The working model is copied the same way: Baseline holds its own copy of the rules in -lib/rules/. Improving the shared model means changing the reference, then copying it again.

The cost

Copies mean duplicated code. That is accepted: the duplication check ignores from-* folders and only reports, never blocks.

Each copy records the commit and a fingerprint of every file it came from (copied-from.json). That makes drift between source and copy visible later; no tool shows it yet.

The alternative, a shared library every experiment imports, would make the experiments agree by force. That is the one thing this repository is built to avoid.

Mistakes are caught before they land

A cross-import is refused twice: right after Claude edits a file, and again before every commit, for everyone.

Where a cross-import is stoppedAn edit by Claude is checked at once; every commit is checked by the pre-commit hook; neither lets a cross-import through.

The rules live in one file, .fallowrc.json, read by Fallow. Every folder under src/routes/prototypes and src/routes/features becomes a silo automatically, so a new experiment is sealed from its first file.

Where this ends

Silos govern code and imports. Claude sessions can also be sealed to one experiment, so an agent never reads another experiment's decisions; see How to keep a Claude session inside one experiment.

More on how experiments are laid out: How routing works here.

For developers: