Definition Ruling Record

A company funds stewardship properly: 18 people at a fifth of their time, written into objectives. Two years later 11 of them have changed role. The glossary is current and accurate.

An analyst asks why "completed order" excludes partially refunded orders. Nobody can say. The question is re-argued every quarter by whoever is in the room, and twice it has been answered differently. The glossary stored the decision's output and discarded the decision, and the output is the part that could have been rederived.

A ruling record is the missing artefact: not meeting minutes, which are organised by date that nobody searches by, and not a change log of the definition text. It is the reason, attached to the thing it explains, written while somebody still knows it.

Why it matters

Steward turnover is the normal case. At a 20% annual internal move rate, half a steward group has changed inside three years, and designs that assume continuity of people degrade into governance by whoever is newest. The cost shows up as repetition - the same question reaching stewardship twice from different teams - which is also the cheapest signal that the record is missing.

The second reason is defensibility. "Completed order excludes partial refunds" is a position an auditor or a new CFO will question. A dated ruling with its rationale answers in a minute; a current glossary entry answers nothing, because it cannot distinguish a decision from an accident.

Implementation patterns

• Six fields, under 150 words. The question in the asker's words · the ruling and the expression it changed · the rejected option and why it lost · effective-from and whether history was restated · who decided, by role as well as name · affected datasets, from lineage rather than typed.
• Store it beside the code that implements the definition - a dated block in the model file, or rows in a small table the catalogue renders - so it travels with what it explains.
• Surface it where the argument happens: the glossary entry, the column description the BI tool shows on hover, the transformation model's header.
• Require the rejected option. It prevents re-litigation and is the only field that feels like extra work, because the author has just finished convincing themselves.
• Keep it append-only. A superseding ruling links to the one it replaces and nothing is edited, because the old reasoning explains last year's numbers.

Industry example

The shape is borrowed from architecture decision records, which teams keep in the repository next to the code in production for this reason: a design visible only as code gets re-debated whenever its authors leave, and the field that earns its place is "alternatives considered". Semantic decisions have the same half-life and worse discoverability, because the definition lives in a glossary tool and the argument in a chat history that expires. Governance programmes copy the committee from software engineering and leave behind the one artefact that worked.

Failure scenarios

• A write-only log. Measure it: how many rulings were opened from a glossary page last quarter? Zero means you built an archive.
• Rulings with no effective date, so a report rerun for a prior period uses today's meaning and nobody can tell whether a restatement happened.
• Rulings written by the platform team on the steward's behalf, which moves accountability with the authorship.
• Records kept per meeting rather than per term, so finding a ruling means knowing its date.

Trade-offs

The direct cost is small: roughly one ruling per contested term per 18 months, about 17 a year across 25 terms, under two hours of writing. The real cost is the discipline to refuse a ruling nobody will record, which makes stewardship feel slower than answering in chat - and the slowness is what people complain about, not the writing.

When not to use it

Below roughly 25 contested terms, or with one data team and a single transformation repository, a dated comment block in the code is the whole mechanism and a separate register competes with the work. The threshold is recurrence rather than headcount: one repeat of a definition question is noise, two from different teams means the reasoning is unreachable.

Nor is it a replacement for an escalation route. A record captures decisions that were made and does nothing for a question nobody is entitled to settle, which needs a named decider and a time limit instead.

Interview question

Q: Your stewards are funded and the glossary is accurate, yet the same three definition arguments return every quarter and half the stewards are new. What would you put in place, and how would you know within two quarters whether it worked?

What a strong answer covers: current state against decision · the six fields and why the rejected option is load-bearing · placement next to the implementation rather than in minutes · the open-rate measure that detects a write-only log · the flip where a code comment suffices.

Quick check

Quiz: Which field stops the question being re-argued? - The rejected option and the reason it lost; everything else is already visible in the glossary.

Flashcard: What is the cheapest signal that your semantic decisions are not being recorded? - The same definition question reaching stewardship twice from different teams.