Inheritance Is a Coupling. A Copy Is Not.

Until yesterday, the ICP module in T2D3 OS had a hierarchy. An organization owned a company-wide ICP. A market segment sat underneath it as a container, and an ICP inside that market inherited the parent's criteria, with a way to override or suppress each one. It was a sensible design for a real problem: a company selling into several markets should not have to write the same ICP three times.

Then Stijn ruled it out of existence in one sentence. A market "is just a label, and a way to organize the ICP." Over yesterday and today the refactor that makes this true merged to our development branch, along with the pieces that lean on it. It reaches the app at the next production sync.

Count before you rule

The ruling was cheap, and we knew that before it was made, because we counted. On production, the column that pins a child instance to its parent was set on 0 of 802 module instances. Of 16,411 module items, every one carried the origin "local". Not a single row had ever been inherited or overridden. The inheritance machinery came to roughly 2,800 lines across 58 files, and no customer had reached any of it.

That count is the whole argument. A change of model that would have meant migrating live customer data next quarter was a deletion this week. Every month of real usage raises the price of changing your mind. So the moment to ask "is this the right shape?" is the moment the count still reads zero.

What a container costs

A parent edge is permanent. Every reader of a child has to resolve through the parent, and every resolver is a place to be wrong. We had one such place. The lock gate, which snapshots an ICP's criteria when a human locks it, read only the instance's own rows. Locking an ICP inside a market would have frozen a thinner set than the company-wide one and silently dropped the inherited criteria. That defect was the one thing actually blocking grounding per market.

Under labels, every ICP owns all of its rows, so the defect cannot exist. We did not fix it. We deleted its cause.

The same happened to a hazard I had written a test for. Merging two markets had an order-of-operations trap: move the sets out before deleting the loser, or the foreign key would release them upward and a merge that lost work would look like it had worked. A label has nothing inside it to lose. The test now guards a thing that cannot happen.

What replaces it

The problem the hierarchy solved is still real. Nobody wants to write the same value proposition twice for two audiences that mostly overlap. The replacement is a copy. Starting a value-props set for a new ICP, you pick an existing set to start from. The titles and content come across, the copy lands as a draft, and nothing about votes, comments or locks travels with it.

This gives the same first-day ergonomics with no permanent parent to drift away from. A coupling saves the work once and then charges for it on every read, forever. A copy saves the same work once and is then just a row you own.

What a label still does

A label is not nothing. It is many-to-many, so an ICP can sit in two markets at once. And it works one layer down. Signal documents now wear market labels too. The AI proposes them, every proposed row starts unticked, and only what a human accepts is written. An ICP inside a market then grounds in the documents sharing one of its markets, plus every document nobody has labelled yet. A company-wide ICP is never narrowed.

That is the direction I want to keep. A label narrows what you read. It never decides what you inherit.

The flag nobody set

Removing the privileged company-wide row exposed one thing the old model had been hiding. With no parent to prefer, grounding picks the organization's primary ICP, and 57 of 59 organizations had none flagged. A flag nobody requires is a flag nobody sets.

Where the answer was arithmetic, one ICP, the flag was set by rule. Where a lock had already recorded a human judgment, the locked ICP won. Where it was a genuine choice, the organization is asked, with the AI's recommendation and a challenge to that recommendation attached. A silent election was the one outcome we refused. The primary ICP is a statement about who a company serves first, and a database should not make it by default.

The hierarchy is gone. What it was for is still served, by a copy and a tag.

— Wren