Why a Catalog Should Not Decide What an Asset Is

The Spreadsheet Is Not the Problem

Most governance programmes start in a spreadsheet, and they are right to. A spreadsheet is the fastest way to find out whether anybody will maintain a glossary at all, and that question matters more than tooling. Programmes that cannot sustain a spreadsheet do not get rescued by a platform.

The spreadsheet fails later, and not for the reason people usually give. It is not that it lacks features. It is that it cannot answer three questions that eventually get asked by somebody who matters:

• Does this still point at anything? A definition written against a column that was dropped six months ago looks exactly like a definition written against a column that still exists.
• Who changed this, and when? Version history on a file tells you a cell changed. It does not tell you that somebody narrowed the definition of active customer and that three regulatory reports depend on it.
• Was that change allowed? In most organisations the honest answer is that anybody with edit access could have made it, including by accident.

A stale definition is more dangerous than a missing one, because a missing definition prompts somebody to ask. This is the real argument for a repository, and it has nothing to do with search or diagrams.

What a Fixed Model Actually Costs

Open any catalog and you find a model already decided: tables, columns, schemas, reports, dashboards, business terms, perhaps data products and policies. It is a reasonable list. It is also somebody else's list, drawn before anyone knew what business you were in.

The trouble starts when the unit your organisation actually governs is not on it — a reinsurance treaty, a consent record, a clinical protocol, a rate card, a model card, a tariff, a syndication right, a dbt model, a Snowflake stage. Then you have three options.

Option one: bend it into a custom attribute

You declare treaties to be a kind of business term and record the treaty-specific facts as free-text attributes. It works for about a quarter. Then somebody asks which treaties cover a given line of business, and the answer requires reading paragraphs rather than following a relation. The structure that would have made the question answerable was flattened into prose at the start.

Option two: keep it in a parallel spreadsheet

Now you have two systems of record, and the one outside the catalog is the one people actually use, because it fits. Lineage stops at the boundary. The catalog becomes a partial view that nobody fully trusts, which is the condition most second-attempt governance programmes are trying to escape.

Option three: wait for the vendor

You raise a feature request. It competes against every other customer's feature request. Meanwhile the programme is asked to show progress, so it proceeds with option one or two, and the eventual release arrives after the workaround has calcified into a process nobody wants to unpick.

The common thread is that the model lives somewhere you cannot reach. Where the model is code — classes, migrations, screens written against named types — changing it is a release, and a release is a negotiation with somebody whose priorities are not yours.

Four Questions a Repository Has to Answer

Set aside feature comparisons. A repository earns its place by answering four questions consistently, in whatever vocabulary your organisation uses.

1. Does every statement end at something real?

A definition should be attached to the harvested object it describes, not published beside it. The difference shows up when the object disappears: an attached definition becomes visibly orphaned, and somebody is prompted to act. A published one becomes invisibly wrong, and nobody finds out until a figure is disputed in a meeting.

This also means a reference that matches nothing should be reported by name rather than quietly dropped, and a reference that matches two objects should be refused rather than resolved by picking one. Two objects called SALES_DB.PUBLIC.ORDERS in one estate is the ordinary condition of a large company.

2. Who answers for this, and does the answer inherit?

Ownership recorded as a name in a text field is not ownership; it is a string that goes stale when somebody changes role. Responsibility has to be held by people and teams, and it has to inherit down the estate — because nobody is going to assign a steward to four hundred thousand columns individually.

Inheritance then needs its own rules: the nearest assignment wins, a domain can decline to pass responsibility downward, and some assignments must refuse to be overridden beneath them. A repository without those three is one where the answer to "who owns this" depends on which screen you asked.

3. What does this depend on, and at what grain?

Lineage is three different questions wearing one word. An engineer wants column to column. An architect wants object to object. An executive wants which business processes break if this pipeline fails, which is neither. Reading one graph at three grains is tractable. Maintaining three graphs is not, and organisations that try end up trusting none of them.

4. What changed, who changed it, and was it allowed?

The audit trail is not a compliance feature bolted on at the end. It is the reason anybody believes the rest. It should record the attribute, both values and the person — including who was made responsible for what, and by whom — and it should never be trimmed to save space. A history with gaps is a history nobody can lean on.

"Was it allowed" is the half that usually gets missed. Where a definition genuinely matters, the edit should become a proposal that somebody with authority over that asset decides, and the asset should not move until they do.

Declared, Never Inferred

One design decision deserves singling out, because it is where well-intentioned tools do the most damage: the temptation to infer meaning from names.

It is easy to write code that treats a relation called derives from as carrying data, and tempting to extend the trick — realised by, sourced from, defines. The phrases read alike and mean materially different things. Pattern matching on them produces links that are indistinguishable from correct links, and that is the whole problem: a wrong lineage edge does not announce itself. It sits in a diagram looking authoritative until an impact analysis misses something.

So which relations carry data should be declared once, deliberately, by somebody who knows — and everything else should be reported as unresolved rather than guessed at. SQL parsing belongs in this frame too: it should produce proposed lineage that a human accepts, not asserted fact. The cost is a few minutes of acceptance work. The benefit is that when the diagram says something, it is because a person said it.

A catalog people suspect is worse than no catalog, because they still have to maintain it.

When You Do Not Need This

We would rather say this plainly than have a client discover it after a purchase order.

If you have one warehouse, a few hundred objects, a single team that sits together, and no regulator asking you to evidence lineage — a well-kept spreadsheet and an enforced naming convention will beat a repository nobody updates. Tooling does not create the habit. It only scales a habit that already exists.

The trigger is not the size of the estate. It is the number of people who have to agree. One team can hold shared meaning in conversation. Four teams across three time zones cannot, and that is the point at which the meaning has to live somewhere other than in people's heads — along with a record of who changed it.

Equally, if you have already bought a platform and the programme is stalling on adoption rather than on tooling, replacing the platform will not fix it. The failure is almost always that governance was implemented for the business rather than with it, and no amount of configurability repairs that.

Five Questions to Ask a Vendor

Each of these is phrased so the answer can be demonstrated rather than asserted. Ask for the demonstration.

1. Add a new kind of asset while I watch. Not a custom attribute on an existing type — a genuinely new kind of thing, with its own fields and its own relations. How long does it take, and does it involve your engineering team or mine?
2. A harvested column with a definition attached disappears from the source overnight. What does the screen show tomorrow? "Nothing" is a bad answer. "Deleted" is a worse one.
3. Two objects in my estate have the same fully qualified name. What does your lineage do? If the answer is that it picks one, ask how you would ever find out which.
4. Can an upload from a file somebody downloaded last week silently revert what three people changed since? Two writable surfaces with no reconciliation is a common and quiet failure.
5. What does it deliberately not do? A vendor who cannot answer this has either not thought about scope or is not going to tell you. The answer is more informative than any feature list.

The last one is worth insisting on. Every product has boundaries; the question is whether they were chosen or discovered. A team that can name its boundaries has usually encountered them deliberately, and has reasons that will tell you more about the software than a demo will.

Published by KRISID · 23 October 2026. KRISID builds a metadata repository, so this paper argues a position we have a commercial interest in; the section on when a repository is unnecessary is included for that reason. It is general guidance, not legal advice — regulatory obligations vary by jurisdiction and by how a system is used.