Referent Before Label

Text keeps flowing even when the thing it refers to has not been settled — a plausible-sounding word is enough to continue. So make the referent and the role explicit before the word is allowed to exist. The name comes last. ⚠ No primary source we checked asks for this ordering — where the two vendors talk about ambiguity, they are talking about prose written by people.

Problem

Suppose a report has a heading called "the compaction point." Read the body and the phrase moves between three things: the conversation history reaching a configured size, the threshold at which summarization starts, and the moment summarization actually begins. A start condition, a value, and an event.

Nothing about the text is broken. It is fluent, and it reads like a technical explanation. But the moment one word covers all three, what the section is about stops being determinable.

The difficult part is that the breakage is invisible. A wrong number gets caught by recomputation. Wrong code fails when it runs. A wrong word travels downstream as readable prose. The next section writes "advance the compaction point," and the one after writes "monitor the compaction point." What you advance is a threshold; what you monitor is an event — two separate things, now joined by a single word, and the design is built on top of that join.

Pointing it out rarely fixes it. Told that something is ambiguous, an agent first adds explanation. Then it revises the wording of the heading. Getting from there to "you have conflated a start condition with an event" is not a short trip. What is missing is not explanation. It is a decision about what the word refers to.

The root of it is a property of generation. Holding a blank open as a blank is not a natural move for a generator. Even where neither the object nor the purpose has been settled, placing one plausible word lets the sentence continue. The problem is that it can continue — not that the ability to continue is weak.

Context

Apply this when:

• Producing designs, investigations, root-cause narrowing, or remediation proposals — work where one word becomes the premise of every later step
• Naming things — state names, condition names, event names, type names for values and records. Naming presupposes that the referent has already been settled
• Asking for a procedure you supplied to be summarized into a short label — "run a test, narrow the cause from the result, then choose a remedy" compressed into "consolidate the observations" erases the ordering itself. And because the summary reads plausibly, nobody notices the erasure

Do not apply this when:

• Quoting source text directly. A quotation requires no decision about referents
• Making simple mechanical edits, reusing existing names, or producing boilerplate. If no new word is being introduced, the discipline spins in place
• Writing something short that established terminology already covers. Where no word is being coined, a discipline about words has nothing to act on

⚠ Scope this too widely and the discipline dilutes itself. What an instruction file can hold is finite; a rule that applies everywhere gets buried exactly where you wanted it to fire. That tension belongs to Instruction Layering and Scoping.

Boundaries with adjacent patterns:

• Reviewing the Plan Before the Work — both put something else ahead of the main text. That pattern puts what will be done first; this one puts what the words point to first. A correct plan written in doubled-up vocabulary is still a plan that can be read two ways
• Making the Output Contract Explicit — that pattern contracts the shape of the output (length, structure, register); this one fixes what the words designate. A settled shape does not settle the contents
• Failure as Institutional Memory — that pattern writes past failures down concretely. ⚠ The failure mode here resists that treatment — a wrong word is newly coined each time, so there is no fixed set to write down. This is the catalog's judgment, not something a primary source states (see below)
• Making the Verification Target Explicit — that pattern contracts what to verify. This one sits upstream of it: whether the thing to be verified resolves to one thing at all
• Recording by Provenance — that pattern separates observation, claim, inference, and judgment inside one record. This one separates the roles a single word is carrying. The unit differs; the move is the same

Solution

Invert the order of generation. Instead of placing a word and fitting an explanation to it, require the referent and the role to be filled in, and let the name be assigned afterwards.

Why it works, in three steps.

First, a blank that cannot be filled stays visible. If asked to write concretely what a word points to and nothing can be written, the referent has not been settled. Under the label-first order that fact never surfaces — placing a plausible word makes the blank look filled. Changing the order is what keeps a blank legible as a blank.

Second, asking for one role exposes the doubling. Asked "is this a condition, a state, an event, a value, a record, a purpose, or a means?", a word that fits two of them is covering two things. That fact surfaces ahead of the pull to settle for a single word. Once it has surfaced, the line can be split, and downstream steps can treat the two separately.

⚠ The catalog does not present that classification itself as normative. We hold no primary source that could adjudicate which set of roles is the right one (see below). What does the work is not the content of the classification but the shape of the question — can this be narrowed to one?

Third, putting the name last turns the ordering into a matter of layout. Put the name column first and a word can be written there, with a consistent-sounding explanation added afterwards — which merely reproduces, inside the table, the very order you were trying to prevent. Putting the name last makes the ordering structural rather than advisory. When it is done, hide the name column and check that the referent descriptions alone still read. If they do not, the names were carrying the meaning and the referents were never written.

And a word whose definition cannot be written should not be introduced. Use the concrete description of the thing in the prose instead. It is longer, and still shorter than one word that can be read two ways.

Why a list of bad words does not substitute for this

One could record each word that went wrong and forbid it thereafter. That is precisely the shape of Failure as Institutional Memory.

But the thing to stop is not "reusing a word that was wrong before." It is placing a word ahead of a settled referent and then reasoning with it. The former can be enumerated; the latter cannot — the next word does not exist yet. So the thing to check against is not an external list carried between sessions but the correspondence the document itself declares.

⚠ This is the catalog's judgment, not Official. In fact the primary sources we checked point the other way — both vendors recommend showing what to avoid with concrete examples, and a publicly released vendor toolkit builds a list of avoided and deprecated terms into its own design (sources in the practice section). The catalog does not hide the disagreement. The claim is not that enumeration is useless; it is that enumeration alone cannot reach a word that has not been coined yet.

Stating up front what the primary sources do not say

The core of this pattern — imposing the discipline on what the agent generates, and withholding the name until last — has no counterpart in any primary source we checked.

Both vendors do say "avoid ambiguous terms." But the scope is prose written by people: the demonstratives a user types into chat, the tool descriptions a person writes, the procedure documents a person authors. Nothing says to interrupt generation and settle the vocabulary the model itself produced (Absence Confirmed; search terms and scope in the practice section).

So this page does not rest on "a primary source says so." It rests on two facts: that both vendors prescribe the same remedy for human prose, and that the place that remedy is aimed at is vacant on the generated side. What to put in the vacancy is the catalog's proposal, not an official recommendation.

Trade-offs

Benefits

• Blanks stay visible as blanks. A column that cannot be filled is a signal that the referent is unsettled. The label-first order destroys that signal
• Doubling surfaces early. One word carrying two roles appears as a line splitting in a table rather than as a contradiction several steps downstream
• Redoing is cheap. Redoing at the stage before a word is fixed is shorter than unpicking a design already built on it

Costs

• It is a detour. One more stage before the main text. On short work that established terminology already covers, that stage is pure loss
• Instructions get longer. Written into resident instructions, this rule pushes the other rules further toward being buried. Primary sources say plainly to keep instruction files short (practice section). It has to be operated together with a scoping decision
• Following the form is not the same as settling the referent. Every column can be filled while the referent description itself remains vague. Whether it is filled is visible in the form; whether it is settled requires reading — which is exactly the division that Separating Mechanical Gates from Semantic Gates describes

GitHub Copilot in Practice

No surface (VS Code / github.com / Copilot CLI / cloud agent) has a dedicated feature for this pattern. What the tools supply is a place to keep a rule resident and a place to store an extracted procedure; the content of the rule is left to practice. What follows compares what the two vendors' primary sources say about ambiguity — and, more importantly, what they aim it at.

Both vendors are talking about prose written by people

On the GitHub side the subject is the demonstratives a user types into chat (source: Prompt engineering for GitHub Copilot Chat, retrieved 2026-07-29; surfaces: VS Code / github.com) Official:

Avoid ambiguous terms. For example, don’t ask "what does this do" if "this" could be the current file, the last Copilot response, or a specific code block.

A demonstrative that fails to resolve among three candidates is structurally the same as "the compaction point" above. But the subject differs — the person is the one placing the ambiguous word, and the person is the one who fixes it. What the source goes on to recommend is asking about a named function specifically, not deferring the name.

On the Anthropic side the subject is a person writing tool descriptions (source: Writing tools for agents, retrieved 2026-07-29) Official:

Consider the context that you might implicitly bring—specialized query formats, definitions of niche terminology, relationships between underlying resources—and make it explicit. Avoid ambiguity by clearly describing (and enforcing with strict data models) expected inputs and outputs.

"Definitions of niche terminology ... make it explicit" is the closest phrase in either vendor's material. But the passage moves directly on to naming input parameters — prefer a name that shows what it designates over a vague one. That is "make the name more precise," not "assign the name later."

The same vendor's rules for authoring reusable procedures also address human-written prose (source: Agent Skills best practices, retrieved 2026-07-29) Official:

Choose one term and use it throughout the Skill:

⚠ What is being asked for is consistency, not explicit definition. And the text being checked is prose a person wrote. It is not a mechanism for checking model output against a declared definition. Adjacent vocabulary is not the same claim.

Settling terminology as a stage ahead of design

A spec-driven toolkit GitHub published on its own blog places terminology among the axes it scans for ambiguity (source: the clarification template in github/spec-kit, retrieved 2026-07-29; surfaces: VS Code / Copilot CLI) Official:

Terminology consistency: same canonical term used across all updated sections.

The same file requires that clarification stage to be completed before the planning stage is invoked (not quoted verbatim here: the sentence contains a template placeholder that is substituted at distribution time, so it does not match what a user has on disk). An official artifact does put terminology settlement in an independent, earlier stage — which makes this the closest primary source to this pattern.

⚠ Three differences of scope, though. First, this is a published toolkit template, not product documentation. Second, the independent artifact is the specification as a whole; terminology is one axis within it and is written back into the spec. Third, what the stage performs is canonicalization — collapsing synonyms onto one term — not deferral of the name. If anything the direction is the reverse: fix the name first.

The same file also includes an enumeration of avoided and deprecated terms among its scan axes. The claim in the Solution section that a list of bad words cannot substitute for this runs against that official design. It is stated here alongside it rather than omitted.

What could not be found

On 2026-07-29, two subagents distinct from the one that retrieved the source material fetched raw text for 30 primary sources on the GitHub/Microsoft side and 31 on the Anthropic side (GitHub side: 12 Copilot pages on docs.github.com, 6 on code.visualstudio.com, 2 on github.blog, 6 raw files from the published toolkit. Anthropic side: the consolidated prompt-engineering page, Agent Skills best practices and overview, tool use, Claude Code best practices / memory / skills / subagents / common workflows, and 5 engineering blog posts, among others).

Sought	Search terms	Result
Imposing the discipline on vocabulary the agent generated	terminolog / glossar / vocabular / nomenclature / synonym / ambigu / precise	0 hits (vocabular, nomenclature, and synonym are 0 across every Anthropic-side source)
Ordering control that assigns the name last	before writing / plan before / outline / structured output before	0 hits
A closed classification of roles (condition, state, event, value, record, purpose, means)	as above	0 hits
That a list of misused words does not work	forbidden / banned / blocklist / denylist / prohibited / word list	0 hits. ⚠ The opposite recommendation does exist (the toolkit above, and the VS Code guidance to show patterns to avoid with concrete examples)
Saving a terminology table as an artifact separate from the main text, or proving generation order	plan to a file / before coding / proof of order / generation order	0 hits. Both sides describe producing a whole specification as a separate file first, but that falls under Reviewing the Plan Before the Work

Absence Confirmed. "Not found" is not "denied" — except on the last row, where a source pointing the other way does exist.

Where the rule lives, and what that costs

Written into resident instructions, this rule lengthens the instruction file. A primary source pushes explicitly against that direction (source: Claude Code best practices, retrieved 2026-07-29) Official:

Keep it concise. For each line, ask: "Would removing this cause Claude to make mistakes?" If not, cut it. Bloated CLAUDE.md files cause Claude to ignore your actual instructions!

So "apply this always" is the wrong instruction to write. Deciding first where it does not apply is the condition under which the rule stays alive. How to cut that scope belongs to Instruction Layering and Scoping.

Also Known As

Name	Source
Referent Before Label	Descriptive — this catalog's descriptive name; no primary source uses it

The practice this came from carries a name its author gave it, but a method's name is not used as a pattern name here. A method name names an implementation, not a type. Measuring Revisions Before Adopting Them declined its source's method name for the same reason.

⚠ "Terminology consistency" is a nearby name, but not an equivalent one. Consistency asks that the same thing be called by the same word; this pattern asks that what the word points to be decided first. It is possible to be consistently ambiguous.

Related

• Reviewing the Plan Before the Work — both put something ahead of the main text. That one settles what will be done; this one settles what the words point to. If the plan's vocabulary is doubled, the plan itself reads two ways
• Making the Output Contract Explicit — one fixes shape, the other fixes reference. A settled shape does not settle the contents
• Failure as Institutional Memory — that treatment resists the failure mode here, because a wrong word is coined afresh each time and there is no fixed set to record. ⚠ This is the catalog's judgment; the primary sources hold the opposite recommendation (practice section)
• Making the Verification Target Explicit — this pattern sits upstream. Before what to verify becomes a contract, that "what" has to resolve to one thing
• Recording by Provenance — the unit differs, record versus word; the move is the same, taking apart what was collapsed together
• Separating Mechanical Gates from Semantic Gates — whether the columns are filled is machine-checkable; whether the referent is settled is not. The form of this pattern rides a mechanical gate, the substance does not
• Instruction Layering and Scoping — where to write this rule and where to let it fire. Trying to make it fire everywhere buries it
• Read next: Reviewing the Plan Before the Work — once the words are settled, the plan written in them is the human's turn to read