What a name buys

Your team ships a dinner-planning feature. Three model calls sit inside one function: interpret the week, score each candidate meal, compose the plan. Each call has a prompt string. None has a name. When Tuesday's plan fails review, someone reads all three templates and guesses where the mistake lives. Cost is a lump on the monthly bill. Nobody can swap just the practicality check without copying the whole function. The retrospective asks whether the model changed. Nobody asks whether the judgment was ever defined.

Now give each call a name: InterpretWeek, AssessMealPracticality, ComposeWeek. The templates have not changed. The cost is identical. The output may be the same. And yet a great deal has changed, because each name is a promise about what decision is being delegated, and promises are what architecture is built from.

Helpful context: Why the words we have fail explains why mechanism vocabulary hides judgment. What is a cognitive unit is the contract those names eventually carry. This page is the motivational step: why bother naming at all.

Why naming matters

Functions did not add computational power to programming. They added the ability to read a system. You can point at calculateTax and know what changed when tax law updates. You can test it without running the entire payroll pipeline. You can hand it to another team because the boundary is explicit. Naming cognition has the same justification, even before evaluation, sharing, or libraries exist.

A team that refuses to name judgments keeps cognition invisible so nobody can be held accountable for it. The resistance usually sounds practical: "We will rename things once the prompts stabilise." Prompts do not stabilise when the judgment is unnamed, because every tweak is a global tweak. Naming is the settlement that makes stabilisation possible.

Three properties arrive together. Identity means there is a thing called AssessMealPracticality that persists across template rewrites, model swaps, and caches, so callers refer to the name and not to a string at a line number. Atomicity means each name covers exactly one callable judgment, so five named cognitive units means five edges and a price you can work out before you run anything. A stated boundary means a sentence saying what the cognitive unit decides, whether this meal fits this evening, that fixes what is inside and what is not. A suggestive filename is not yet a specification.

Those three properties unlock operations that were impossible while the work lived inside anonymous prompts. A product owner can say "AssessMealPracticality is too conservative on busy evenings" instead of quoting paragraph four of a shared template, and that pointing is the prerequisite for ownership. An evaluation suite binds to a name, so when the model vendor updates weights, the team remeasures one edge instead of every feature that touched a prompt. Another team can own the practicality judgment while the original team owns composition, because the artifact has an address. Five named cognitive units in a loop means five line items on a costing table, while anonymous cognition means guessing from the invoice. And substitution becomes real: swap AssessMealPracticality v2 into the domain library without rewriting agent strategy, because callers depend on the contract, not on today's wording.

Capability	Without a name	With a name
Point	Quote a template fragment	Refer to the decision
Measure	Score a region of a file	Attach an evaluation suite
Hand off	Copy the prompt	Own the cognitive unit without owning the feature
Price	Guess from the bill	Count calls and wrappers
Substitute	Edit every call site	Replace behind the interface

The system becomes legible. Review can ask whether the shape of the reasoning is right. Work can be divided. A cognitive unit can be reused instead of copied into three services that diverge quietly. Everything behind the name is free to change: wording, model, cache, or eventual promotion to a rule.

What this looks like in practice

In the Weekly Meal Companion, the household request never mentions models or agents: "Plan dinners for four people this week. Tuesday and Thursday are busy. Use the spinach before Wednesday and avoid meals we ate last week."

Before naming, "the meal checker" is a prompt inside generatePlan(). Nobody can evaluate busy-Tuesday behaviour without running the whole pipeline. Nobody can hand the practicality judgment to another team. Nobody can tell whether a regression came from interpretation or from fit assessment. When the household asks why Thursday's stir-fry was chosen over a roast, the system has no stable object to attach reasons to.

After naming, AssessMealPracticality owns one wrong-answerable question: does this candidate meal fit this evening's constraints? Callers pass structured inputs: candidate meal, evening context, endorsed knowledge about effort limits. Reviewers attach a suite to that name alone. When the model changes, the team remeasures one edge, not the entire feature. Contestability has something to contest against, not "the model thought so" but claims tied to a named judgment. The same shift applies outside meal planning. An invoice team that names AssessExplanationCredibility separately from CompareTotals can diagnose a failure in credibility assessment without reopening arithmetic checks. Naming is domain-independent, but the payoffs compound wherever decisions carry consequence.

What naming does not buy by itself

A name without a stated decision is a label on a string. "MealChecker_v3" is not architecture, it is a filename with aspirations. A name without evaluation is an address with no evidence, because owners can be swapped but nobody knows whether the new owner ships better judgment. A name without purity and authority discipline can still hide side effects and stolen responsibility, as when a cognitive unit writes to the database while assessing practicality. Naming is the settlement that makes contracts, suites, and grants legible, not a substitute for them.

Naming also does not replace decision locality. A perfectly named cognitive units in the wrong layer of the stack still creates integration pain. The sequence matters: name first, place second, evaluate third. Naming does not automatically produce good judgment. It produces addressable judgment, which is the prerequisite for improvement. Teams sometimes fear naming because it makes ownership visible. That visibility is the point.

You cannot state a principle about something that has no name.

The cognitive unit · Ch. 1

From name to library

The refactor path rarely starts greenfield. A team inherits a generatePlan() with embedded prompts. The extraction sequence begins with reading the function and listing every verb that implies judgment, then writing one decision sentence per verb. Sentences that describe the same judgment merge. Sentences that contain "and" split. Each surviving sentence gets a name before anyone touches templates. Moving closed checks to deterministic helpers first delivers quick wins that shrink the open core. A named cognitive units in one repo with a markdown contract and ten evaluation cases beats anonymous cognition in three services, even without perfect library infrastructure.

The journey from named edge to shared asset follows a predictable path. Day one brings a markdown contract beside an async function. Week two brings ten evaluation cases for the happy path and three abstention cases. Month one means publishing to a domain library with semantic versioning and substitution rules. By quarter one, a second product consumes the same name without copying prompts. Skipping steps is possible. Skipping naming is not. Anonymous cognition never enters a library. It enters every repo slightly differently.

Finance asks what AI spend bought. Anonymous prompts answer with a single line item and a shrug. Named cognitive units answer with a table: interpretation cost, candidate generation cost, practicality assessment cost, composition cost, critique cost, judge calibration cost. That table drives rational substitution, cheaper screening models on low-consequence edges, consensus wrappers on payment holds. Cost per decision economics depends on names the way cloud economics depends on service labels.

What to do next

When anonymous model calls appear in production code, the first step is writing one sentence naming the judgment each call owns, something competent reviewers could disagree about, and giving each sentence a stable name before debating prompts or models. Compounds split until each name owns one open decision, following the rule in one cognitive unit, one open decision. Evaluation attaches before the name earns trust as architecture. Unnamed cognition stays invisible. Theory has no subject. Cost has nowhere to land. Failure has nowhere useful to look.

The next page defines what those names carry: the contract that turns a label into an architectural artifact.

Read next: What is a cognitive unit.