Cognition as material

Two teams ship dinner planning in the same quarter, both calling the same vendor model. One keeps prompt text in three services and a shared doc. The other publishes GenerateCandidates and AssessMealPracticality into a meal-planning domain library, each with a named decision, an owner, and a set of cases it is expected to pass.

Six months later the vendor updates the model underneath both of them without any commit landing in either repository. The first team's plans shift in ways nobody can trace, because a three-course suggestion returns to a busy Tuesday and the spinach drifts past Wednesday, and there is nothing to point at that was supposed to hold. The second team reruns two suites, sees which of the two judgments moved, and either ships with evidence or pins the previous engine while it investigates.

Nothing about the model was different between them. What differed is that one team had judgments with identities and the other had prose that happened to work last quarter. Cognition becomes a material at the point where a judgment has an identity that survives replacement of whatever produced it, and the practices teams reach for first all sit downstream of that identity.

Helpful context: The Intelligence Age argues the stance, that a material is chosen for some parts of a structure and refused for others. From computation to cognition takes the same shift inside the architecture. This page works out what an artifact of cognition is actually made of, which is the claim the model is not the system depends on.

What would make cognition a material

Supply chains for code work because an artifact's identity is separate from any particular copy of it. A dependency has a name, a version, an interface callers program against, and test evidence, so a maintainer can rewrite its internals while consumers carry on unchanged. That separation is what turns replacement into a routine event rather than a rebuild, and it is the only reason material language is worth borrowing at all.

Cognition strains the intuition, because the obvious candidate for identity is the prompt text, and prompt text is the one thing that cannot carry it. Two teams can write quite different templates that own the same decision and reach the same standard, and either of them can rewrite its own template overnight without the surrounding product noticing. Text that varies that freely while the responsibility stays fixed is implementation, whatever else it feels like.

Set implementation aside and what remains is a contract and the cases the contract was measured on. Sameness lives in those two things, so one judgment is the same judgment as another when both own the same decision under the same terms and answer to the same cases. A team that rewrites a template from scratch, beats the old numbers on the same cases, and deploys has not created a new artifact but a second implementation of one that already existed.

A prompt cannot carry an identity

Prompts get shared constantly and almost none of it results in one team depending on what another team built. The recipient looks at the prompt, nods, and writes their own because a template on its own carries nothing they would need in order to depend on it: not which decision it owns, not what one call costs, not which cases defeat it, and not whether the copy they were handed is the one somebody measured.

So the failure of the shared-prompts folder is structural rather than cultural. No amount of naming convention or directory discipline attaches what was never attached, which is why teams who reorganise their prompt collection twice still find themselves writing the third fork. What has to travel instead is worked out by packages, not prompts, and where those artifacts sit once they can travel is libraries of cognition.

The part that belongs here is narrower, because one of the artifacts that has to travel is the one teams reliably withhold. Cases contain real data and assembling them was expensive, so a team will happily share a template and quietly keep its evaluation set. Both reasons are honest and both are solvable. A judgment published without its cases is a function published with its type signature removed: the recipient can call it and has no way to know what will come back.

A folder of shared prompts does not compound. A set of published cognitive units with their evaluation suites does.

The cognitive unit · Ch. 11

Substitution is where the claim gets tested

A material claim earns nothing until somebody acts on it, and the act is substitution: changing what produces a decision while every caller stays exactly as it was. Two conditions decide whether a candidate qualifies. The contract has to be identical, because a replacement that alters the result shape is a different judgment wearing the same name. The results have to be better on the incumbent's cases rather than the challenger's, since a challenger that brings its own examination has chosen it.

Domination also has to be read per class of case rather than in aggregate. A candidate engine that gains four points on busy-evening fit and loses six on leftover reuse has an excellent headline number and is a regression for the household that eats leftovers on purpose. The honest discipline is to write down which classes of case you refuse to lose on before the challenger's results are visible. Substitution rules develops the rule and its relaxations.

The scarier substitution is the one nobody proposes. When a provider updates a model underneath a running product, the implementation of every judgment in it has changed with no commit, no review, and no notification anyone is likely to act on, so suites have to run on a clock rather than only when the team touches something. That is the whole difference between the two teams in the opening: whether an unexplained movement in the figures had anywhere to register as a finding.

Not every judgment becomes an artifact

The material question only arises where the decision is genuinely open, and half the work in any product is not. Portions for four people are arithmetic, and Leena's confirmed cashew allergy is exact once the household has endorsed it, so both are enforced in the deterministic shell where they cannot vary. Putting either into interpretive form adds variance nobody asked for, which is why capability is a bad reason to delegate a decision that belongs in code.

Material form is also not the same as shared form. Some judgments are shaped by one organisation's way of working, so they travel nowhere useful, which is no more a defect than the many functions in any codebase that would mean nothing elsewhere. InterpretWeek stays private to the Meal Planning Agent because how this run's request becomes a structured week is strategy the agent still owns. Identity is what the material claim requires, so publication remains a separate question about scope.

Three different homes in one week

Nothing in the household's request names an artifact:

Plan dinners for four people this week. Tuesday and Thursday are busy. Use the spinach before Wednesday and avoid meals we ate last week.

The same request gives three different answers to where work belongs.

Work	Home	Why
Cashew allergy enforcement	Deterministic code	The fact is endorsed and the rule is closed
AssessMealPracticality	Domain cognitive unit	Busy-evening fit recurs across meal-planning products
InterpretWeek	Agent-private judgment	Turning this household request into this run's state belongs to the goal owner

AssessMealPracticality is the clearest thing to materialise because the decision it owns can be stated in one line: whether a candidate meal fits one named evening. Its result shape is what the composition step programs against, and its cases are the ones that already caused arguments: active effort on a busy evening, leftover reuse, spinach timing, and the line between practical and merely possible. Once those exist, a cheaper engine can be proposed for that judgment as a substitution with evidence instead of as an impression formed in a sandbox chat. Libraries of cognition is where placement gets settled properly.

That split is what the vendor update lands on. The allergy check cannot have moved, so it is never a suspect. Each named judgment either still passes its cases or does not, and whichever one moved is the thing to look at first. Without the split, the same update produces a product that feels worse with no candidate to investigate.

What identity buys downstream

Teams usually want the downstream practices before they want the artifact, and the order cannot be reversed. Asking what a decision costs requires a decision that can be metered, which is why cost per decision is arithmetic on named judgments and guesswork on prose. Letting an agent compose work it was not explicitly wired for requires inventory it can select from without executing it, which is what the library unlocks autonomy traces to the end.

Evaluation is what keeps identity from becoming decoration. A contract with no cases behind it gives an incident a name and no way to establish whether the named thing still meets its spec. This is why evaluation is part of architecture rather than a phase appended to it, and why finding the weak decision is possible in one product and not in another that looks identical from the outside.

What to do next

The useful first move is to take one judgment the product rewrites in every feature, preferably one that already caused an argument in production, and give it a name, a result shape, an owner, and the cases it should pass.

Whether it worked shows up the next time the engine changes. If somebody can replace the model behind that judgment and tell you which cases moved, the judgment became material. If nobody can, what the product gained was a name.

Read next: Libraries of cognition for where these artifacts live once they travel. Intelligence beneath the surface takes the opposite view of the same structure, from the side of a household that never sees any of it.