Skip to content

You can't test for the talent. You can verify the work.

You can't test in advance for the talent that names the case a concept can't represent — confident performers fake the tells, and real definers sometimes present as pedants. So stop certifying the person and verify the work instead: a one-page concept decision record — the term, the competing definitions, the decision, what it rejected, and a dated, owned prediction of how it will break — turns an unverifiable claim into a credential a non-expert can read after the fact.

Part 2 left you better off and not finished. The convergence count survived the meeting — several independent kinds of trouble around one concept, hard to explain innocently — and the concept has an owner. But an owner is a person accountable for what a concept means, not necessarily a person who can say what it means. Two problems remain, and they are the two halves of the promise this series has been making: find the talent that can perform the rare act — naming the case the concept can't represent — and reward that act even though, on the day it's performed, you have no way to verify it. Source, then reward.

Sourcing: the tell of the definer

Fred Brooks argued in The Mythical Man-Month that conceptual integrity is the most important consideration in system design, and that it requires the design to live whole in one mind — or in a very few minds that agree. Part 2 showed why that is exactly what a modern organization prevents: the concept fragments along the communication structure, and no role comes with the whole view. Someone has to assemble it against the grain. Brooks's answer was structural — appoint the mind, call it an architect. Mine has to be behavioral, because the title doesn't reliably mark the talent and the talent doesn't reliably hold the title. You find the definer by watching for the behavior, and the behavior looks like this.

They interrogate terms past their storage. Ask most people what active customer means and you get the column that stores it — "it's the flag on the accounts table." The definer treats that answer as the question restated.

Their questions narrow. Confronted with an ambiguous concept, most of us pattern-match — "this is like what the platform team did with entitlements" — which widens the space with analogies. The definer's questions shrink it: is a paused subscriber active? active for billing, or active for the health metric? can she be one and not the other? Each answer eliminates meanings.

They restate the other side until its owner says yes, that's what I mean. This is the act Part 2 said the structure prevents — assembling the shards across the seams. In a meeting it looks like slowness. It is the only route to holding the whole.

And, decisive above the rest: they produce the case. Not "this feels fragile," not "this won't scale" — a case: when a customer pauses and resumes inside one month, these two systems disagree about whether she was ever active. The general worry is common and cheap. The specific breaking case is the rare act itself, performed in front of you — and unlike the worry, anyone in the room can check it.

Now the concession, because these tells are directional, not a test. Confident performers mimic the surface — interrogating terms theatrically, producing cases that dissolve on inspection. Some real definers present badly and get read as pedants. If you could reliably pre-vet this talent, Part 2's problem — authority's rational discount of an unverifiable claim — wouldn't exist. You can't. So the weight has to move off the vetting and onto the work: don't certify the person; make the act verifiable after the fact. That takes an artifact.

Rewarding: the concept decision record

When the definer resolves the concept — or decides, consciously, to leave it open, which is also a decision — the resolution gets written down. Not in a glossary. In a concept decision record: one page, dated, five fields.

  • The term. The one that wouldn't hold still.
  • The competing definitions. What the different owners said, in their words.
  • The decision. The single definition committed to, now — or the explicit choice to stay undecided until a named date.
  • The rejected alternatives. What was not chosen, and why — so the next person can't silently re-litigate it.
  • The expected failure mode. The case that, if it shows up, means this decision was wrong — with a date horizon and a named owner watching for it.

That's the whole of it. It's a bet scoped to one concept, not a framework; it claims nothing beyond its page; and nothing about writing one requires anybody's methodology, including mine.

The record has two neighbors, both worth naming. The first is the architecture decision record — Nygard's ADR — and the resemblance is no accident: four of the five fields are standard decision-log furniture. The fifth field is the difference — a falsifiable, dated, owned failure prediction — so call this an ADR specialized to concepts, carrying the one field ADRs don't. The second neighbor is Evans's domain-driven design, which is a modeling practice that generates breaking cases of its own, not merely the glossary I'm about to contrast; the narrow point concerns only what shared language can certify. A glossary records agreement. A record forces a choice, names what it rejected, predicts how it will break, and puts a name against the prediction. The difference matters most for Part 1's second origin: a misconceived concept — shared, consistent, wrong — sails through a glossary, because agreement is not correctness. The record is the one artifact in this series that can catch it, and it catches it in the fifth field: even a confidently wrong decision now fails on a named case, visibly, early. How does a concept nobody disputes earn a record in the first place? Through the screen's two reality-facing families — the numbers reality keeps contradicting, the confidence that doesn't fit the difficulty. Consensus can suppress the argument; it can't suppress the smoke reality makes. The record doesn't make you right. It makes being wrong cheap to detect.

The fifth field also earns its keep in the build, and since this is the only engineering advice in the series, I'll keep it short. A named failure that would be dear to absorb late — a change threaded through every stage, a migration forced on every consumer — earns exactly one seam: a place where the correction can later arrive as an addition instead of surgery. Not the solution built early; a door left where the record says the wrongness will land. A named failure that's cheap to fix late earns nothing. Build plainly and move on.

One record, start to finish

The build was a partner-program email system. Members became eligible for a send roughly every two weeks; the brief was to make the most of the channel; and the evidence at the time was clear that, inside the frequency caps, more email meant more revenue. The term that wouldn't hold still was send. The competing definitions: send whenever eligible versus send when it's the right moment for this member. The decision: send as eligible — the data supported it, and nothing yet overrode it. The rejected alternative: building timing optimization immediately, with the reason recorded — the data didn't justify the spend. The expected failure mode, written in plain sight: the more-is-more regime flips, and we need the ability to choose not to send. Owner named. And because that failure would have been dear to retrofit — "should we send at all?" threads through every stage of a pipeline built to assume yes — it earned the one seam: the pipeline was staged so that a send/no-send decision could later drop in as one more stage.

Months later the recorded failure arrived, wearing a mask. Most partners had launched on a Monday; the two-week cadence collapsed the whole audience onto a Monday rhythm; and don't send right now became the correct answer for a large slice of members. The fix was an addition — one new stage, two new inputs, under a week — landing exactly where the record said the wrongness would. And the aftermath is the part I'd point a leader at: there was no blame cycle, because there was nothing left to litigate. The record said who decided, what they expected, and where it would break. It broke there.

One example, and a suspiciously clean one — chosen because it ran the mechanism end to end, not because records usually pay off this legibly. Most vindications are quiet, and most failures arrive partial. And by this series' own logic I can't hand you a base rate for the failure itself; the only base rate available is the one your own records start writing the day you keep them.

What the record does to the ledger

Part 1 made a claim I left uncomfortable on purpose: you cannot know how much of your logged failure is conceptual debt wearing other labels, because the label was wrong at filing time. The record ends that — prospectively. A dated prediction with a named owner is a postmortem written in advance. When the recorded failure arrives, there is no filing decision left to get wrong; the cause was written down before the effect. And if it never arrives, that's information too — the decision held, and the page says who called it.

Which is what "reward the naming" means in practice. The definer's claim — unverifiable the day it was made, rationally discounted by every room in Part 2 — has become a verified prediction anyone can read. That is the credential the room was missing, and it's one a non-expert can evaluate: no judgment of talent required, just a page, a date, and what happened next. It is also, finally, something your calibration and promotion process can cite. You couldn't test for the talent in advance. You can verify its work after — and pay it when the prediction proves out.

When not to bother

This costs more than nothing, so skip it — on purpose — in three cases. When the system is throwaway or short-lived: being wrong is already cheap, and the record is overhead. When the stakeholders are adversarial and there are no honest definitions to collect: you'll record performances, and a record built on performances is worse than none, because it launders a live fight into a signed-looking artifact everyone can point at while the disagreement stays open. And when no single owner can exist for the concept: then you don't have a decision, you have a note.

And the honest ceiling, stated once: none of this — the screen, the tells, the record — finds the fatal case nobody in the room can yet name. That case exists. Sometimes the record will be signed, the screen will be clean, and the concept will still be wrong in a way no one could say. The claim of this series was never immunity. It was: stop wasting the signal you already get, and make the wrongness you can't prevent cheap to see.

Who owns the undefined

Which returns the series to the room it opened in — everyone saying yes to the same sentence, each holding a different concept, nobody's job to notice. Nearly every company lists ownership among its values, and nearly every incentive system rewards it as boundary-defense: own your box, keep your box green. Conceptual debt is what no box contains — that was Part 2's first mechanism in one line — so under boundary-ownership it is ownerless by construction. A value that never costs anything is a slogan. Owning the undefined has a cost: being accountable for an outcome that won't score this quarter, in an organization that prices what scores this afternoon. The record is what makes that cost small enough to ask of someone, and the act visible enough to reward. A page, a date, a name.

So start tomorrow with one. Take the term your teams can't agree on — the active user, the qualified lead, the completed order — put the person who shows the tells in a room with the people who own the shards, and write the record: the definitions you're hearing, the one you'll commit to, the failure you expect if it's wrong. You won't have predicted the future. You'll have been explicit about what you don't yet know, in a form your organization can see, verify, and pay. The loan nobody signed will finally carry a signature — and none of it needs a consultant.

Sources

  1. The Mythical Man-Month: Essays on Software EngineeringFred Brooks · Addison-Wesley, 1975
  2. Domain-Driven Design: Tackling Complexity in the Heart of SoftwareEric Evans · Addison-Wesley, 2003
  3. Documenting Architecture Decisions (opens in new tab)Michael Nygard · Cognitect, 2011