Domain Authority

Overview

Two topics ago, code stopped being the scarce thing. Last topic, output stopped being reliable. Both point the same direction: the valuable thing is knowing what should happen.

The idea

Domain Authority is deep, specific understanding of how the business actually works — the kind that lets you look at a plausible answer and say “no, that’s wrong, and here’s why.”

It’s the complement to Code as Liability. As the cost of producing code falls, the value of knowing what’s worth producing rises. One depreciates; the other appreciates.

Why a model can’t supply it

A model trained on public text knows a great deal about your industry in general. It knows nothing about your company in particular.

It doesn’t know that a “resolved” ticket sometimes means the technician gave up and rebooked. It doesn’t know that your headline statistic came from an audit that classified by first message, so it probably overstates how many cases are genuinely simple. It doesn’t know which customer segment behaves differently from the others, or which hour of the week is busiest and why.

None of that is in the repository either, so reading the code won’t reveal it. It lives in the heads of the people doing the work, and in the data itself.

Available to a model — commodity, and getting cheaper:

graph LR
  PUB["General knowledge<br/>the industry,<br/>common patterns"] --- REPO["Your repository<br/>code, schemas,<br/>configs"] --- DOCS["Your documentation<br/><i>if it is any good</i>"]

  classDef avail fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  class PUB,REPO,DOCS avail

Domain Authority — mostly undocumented, and what makes you valuable:

graph LR
  WHY["Why decisions<br/>were made, and<br/>what was rejected"] --- REAL["What the data means<br/>vs. what the<br/>schema says"]
  REAL --- PEOPLE["How the work<br/>really happens vs.<br/>the documented process"] --- HIST["What was tried<br/>and failed"]

  classDef scarce fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  class WHY,REAL,PEOPLE,HIST scarce

What a model can reach, and what it can’t. The second set is the one you are accumulating — and the one nobody wrote down.

Where it bites

Say the design proposes embedding historical tickets so the system can answer from past resolutions.

Sounds obviously good. Domain Authority raises three objections a general-purpose reading wouldn’t:

• Many historical resolutions are wrong. Agents close tickets to hit response targets. Embedding them teaches the system to repeat bad answers confidently.
• The tickets contain personal data — names, site addresses, sometimes payment references. Once embedded, that’s much harder to remove than deleting a row, which matters directly to Lena Fischer’s obligations.
• The product changed in 2024. Resolutions from before then describe workflows that no longer exist, and nothing in the ticket text says so.

None of those are technical objections. All three are architectural, and all three would sink the feature after launch rather than before.

Note also what the 38% figure actually rests on: an audit that classified tickets by their first message. Grace Adeyemi’s agents could tell you which of those are genuinely simple — nobody has asked them.

This is what verification actually requires — the skill the previous topics said was becoming scarce. You can’t catch problems like these by reading the design carefully. You catch them by knowing the business.

How you build it

It’s unglamorous, and it’s most of what a good first month looks like:

• Read the actual data. Not the schema — a hundred real records. You will find things nobody mentions.
• Talk to the people doing the work. They know exactly which cases are genuinely easy. Nobody has asked them.
• Ask what was tried before. This is how you find the failure nobody documents, and nothing else will surface it.
• Learn what the numbers really count. Every headline statistic has a methodology behind it, and the methodology has assumptions.

The cost is real: this takes weeks, produces no visible output, and looks like slow starting to anyone watching. It’s still the highest-return time you will spend, and the stakeholder work in Section 1 is how you buy yourself the room to do it.

The career consequence

If Domain Authority is the appreciating asset, some career strategies age badly.

Moving between companies fast enough to never accumulate deep context, or specialising in a technology rather than a problem domain, both optimise for the thing getting cheaper. Module 10 develops this properly. For now: depth in a domain is worth more than breadth across tools, and the gap is widening.

Feeds the workbook

Your business-value brief should name at least one thing you’d need to find out from people or data before trusting your own design.

Check your understanding

1. Give one example of Domain Authority someone in your organisation has that a model reading the repository could not infer.
2. The three objections in the case block are all business, not technical. Which would you have caught, honestly?
3. What’s the equivalent undocumented knowledge in a system you work on — the thing a competent newcomer would get wrong?

---

→ Knowing the domain tells you where the boundaries should be. Next: how you enforce them, on a system that acts by itself. — Guardrails