Running projects that cannot read each other

Why are the walls there?

Because most of what a project produces should never leave it. A client’s name, a record about a person, a pricing decision, a credential, the shape of a codebase: nearly everything a project generates is specific to that project, and some of it concerns people who never agreed to be discussed anywhere else.

So our projects are walled off from each other. The agents that build in one project cannot read another, and that is a boundary held by how each working session is set up, not a convention we hope everyone remembers.

The wall creates a problem worth naming plainly. Every project pays full price to learn what a sibling project already knows, because nothing lets the second project get the lesson for free. In a single week in July 2026 we watched three lessons each get learned twice, in two different projects, days apart, by different sessions. That count comes from a record we keep of our own work, and the record is not public, so you are taking it on our word rather than being able to check it. That is the cost this practice exists to cut.

What is the difference between a fact and a lesson?

A fact belongs to one project, and a lesson belongs to nobody. That distinction is the whole method, so it is worth being exact about.

Facts are what the wall exists to contain. A customer’s name. A record. A price. A credential. A defect in one particular file. Almost all of a project’s output is facts, and facts stay put.

Lessons are about how work goes wrong, anywhere. A check that runs but cannot block a change is decoration. A comment saying something was fixed is not evidence that it was fixed. Measure a live system rather than reasoning about what it probably does. None of those belong to the project that happened to teach them. They were merely discovered there.

How does a lesson earn the right to move?

By passing two tests, both of them, every time. First: can it be stated without naming the project it came from? If naming the project is the only way the sentence makes sense, it is a fact wearing a lesson’s clothes, and it stays where it is. Second: would we be comfortable seeing that exact line inside a different project’s own repository? Not whether it would be useful there. Whether it would be safe there.

The second test catches entries that pass the first on a technicality while still carrying a customer, a legal matter or a commercial position. Together the tests take about ten seconds, and they are the whole control.

When an entry fails, the right move is usually to rewrite it rather than drop it. Stripping the specifics forces you to state the general rule you actually learned, and the general form is usually the more useful one. “The check on that one change was never marked as required” is a fact. “A check that is not required to pass before merging cannot stop anything, and marking it required is always a separate, forgettable step” is a lesson, and a better one.

Who carries a lesson across?

One role, and exactly one. Somebody has to see more than one project or no lesson ever moves, so a single advisory role is allowed to cross the walls, and moving lessons is the reason it is allowed to. Every building role stays walled in.

The mechanism is one question, asked at the end of every working session: did this session learn something a different project would want? If yes, the lesson is written into a shared layer, in the form that passes both tests. If no, that is said out loud too. “Nothing transferable this session” is the usual answer, and accepting it is what stops the shared layer becoming a dumping ground nobody reads.

Which lessons are worth writing down?

Four kinds keep earning their place. A control that failed silently is the most valuable, because silence is what makes a failure expensive: a test that could not fail, a check that examined nothing, a gate that ran but could not stop anything. A tool that behaves differently from how everyone assumes it behaves is next, because that costs an hour in every project, forever, until it is written down. A reasoning failure with a name is third, because naming the shape is what lets the next session catch itself repeating it. And a negative result, the thing that was tried and did not work, is the most neglected kind, because an unrecorded dead end looks exactly like an unexplored idea.

What is not worth writing: anything true of only one codebase, anything that is really a status update, and anything that cannot be stated as a rule. If there is no instruction in it, it is a story, not a lesson.

What does this cost, and where does it fail?

Three real costs, stated with the same confidence as the rest of this page.

The crossing role is a bottleneck. Lessons move only when that one role sits down at the end of a session and asks the question, so a lesson can be paid for a second time in a sibling project before it has moved anywhere. The walls are the cause. The speed of learning is capped by the one channel allowed through them, and widening the channel would defeat the walls.

Nothing mechanical enforces any of it. The two tests are judgement, applied in seconds, by the same role that carries the entries across, with no independent check on that judgement. The question at the end of each session is a discipline, not a gate, and if it quietly stops being asked, nothing fails visibly. We wrote that weakness down in the same document that defines the practice, so at least its absence would be a broken promise rather than an invisible one.

And the return is occasional by design. Most sessions produce nothing worth moving, so most of the time the practice is pure overhead: a question asked, answered no, recorded. The value arrives in lumps, on the day a project skips a failure a sibling already paid for, and there is no way to see the lumps coming.

What would change this?

Volume. The practice assumes lessons arrive slowly enough for one crossing role to carry. If the number of projects grew, or the rate of transferable lessons did, the bottleneck above would stop being a cost and become a failure, and the honest fix would be machinery that enforces the two tests rather than a discipline that applies them.

The other thing that would change it is measurement. Running several projects the same way slowly generates base rates: how often an independent check finds a real problem in work its author called finished, how many repair rounds a risky change actually takes. Those numbers only mean anything across projects, because one project is one sample. We have started publishing the first of them on this site, and every number that firms up will be a better argument than this page.