A self-scoring worksheet for the metadata estate underneath your reporting and your agents.
Every claim about grounding an AI system, defending a number, or passing an audit rests on the same foundation: whether the metadata describing your estate is complete, deep, derived, current, and governed.
This worksheet measures that, on five dimensions, using three of your own business metrics. It takes about three hours and it's meant to be done by hand. The manual work is the point, because the gaps surface during the tracing.
Nothing here is vendor-specific. Score any stack.
What this measures, and what it leaves alone
In scope: the quality of the metadata that describes your data estate. Coverage, resolution, derivation, freshness, and governance state.
Out of scope: the quality of the data itself. Bad values, null rates, how recently records landed, and pipeline reliability belong to data quality tooling and data engineering. A perfect score here says your estate is well described. It says nothing about whether last night's load was correct.
Keeping that line clean is what makes the score defensible when someone challenges it.
Before you start
You'll need read access to your catalog or metadata tooling, your BI semantic models, your transformation code, and whoever can answer "who owns this definition." Budget an hour per metric.
Pick three business metrics that meet all three tests:
- It appears in at least two consuming systems (two BI tools, or one BI tool and one AI application).
- Someone senior has asked about it in the last quarter.
- You believe you know its definition. This one matters, because the surprise is the finding.
Good candidates: net revenue, active customer, gross margin, churn rate, headcount.
Write them here:
#MetricConsuming systems123
Dimension 1: Coverage
The question: does harvested metadata exist for every system this metric passes through, from origin to consumption?
How to check: trace the metric backward. Consuming report, semantic model, warehouse table, transformation job, source system. At each hop, ask whether your tooling holds a metadata record for it.
ScoreWhat it looks like0Metadata exists for the BI layer only1Warehouse and BI covered; transformation and sources dark2Cloud-native systems covered; legacy, on-prem, or file-based sources dark3Full path covered with one or two known gaps you can name4Every hop from origin to consumption has a metadata record
Scores: Metric 1 ___ · Metric 2 ___ · Metric 3 ___
Common finding: the estate looks well covered until the trace reaches a scheduled extract, a spreadsheet, or a stored procedure that predates the current team.
Dimension 2: Resolution
The question: how deep does the record go, table or column?
How to check: for each hop above, ask your tooling which specific field feeds the metric, through which transformation. Table-level answers score low, regardless of how complete the coverage looked.
ScoreWhat it looks like0Asset-level only. You know the report touches a database1Table-level across the path2Column-level in the warehouse, table-level elsewhere3Column-level across most of the path4Column-level end to end, with transformation logic attached at each hop
Scores: Metric 1 ___ · Metric 2 ___ · Metric 3 ___
Common finding: table-level lineage answers demo questions and stalls on the real one, which is which of four similar columns the finance close actually uses.
Dimension 3: Derivation
The question: where did the lineage record come from, parsed code or observed execution?
How to check: ask your tooling vendor or your platform team directly. Observed lineage reports what ran during a window. Parsed lineage reports what the code defines.
ScoreWhat it looks like0Lineage is hand-documented and maintained by people1Lineage inferred from run logs or query history2Mixed: parsed in the warehouse, inferred elsewhere3Parsed across most of the path; a few inferred segments you can name4Parsed from code artifacts end to end, traceable to the defining statement
Scores: Metric 1 ___ · Metric 2 ___ · Metric 3 ___
Verify this one directly. Run the trace on a job that hasn't executed this quarter. Inferred lineage goes quiet; parsed lineage answers.
Dimension 4: Freshness
The question: does the record match the estate as it is today?
How to check: pick one recent schema or transformation change you know shipped. Look for it in the metadata record and note how long it took to appear.
ScoreWhat it looks like0The record is a documentation project someone updates when they can1Refreshed on a quarterly or ad hoc cadence2Refreshed monthly; recent changes are visibly missing3Refreshed on a schedule measured in days4Harvested continuously; the record tracks the estate
Scores: Metric 1 ___ · Metric 2 ___ · Metric 3 ___
Dimension 5: Governance state
The question: does this definition have an owner, a history, a policy, and a binding to a real asset?
How to check: four sub-questions. Score one point for each yes.
- A named human owns this definition, and they know it.
- You can retrieve what this definition said 12 months ago and what changed since.
- Access or sensitivity policy is enforced at the point of use, beyond being recorded in a document.
- The business concept is bound to specific physical assets, with the binding visible in the tooling.
Scores: Metric 1 ___ · Metric 2 ___ · Metric 3 ___
Common finding: ownership exists on paper for most definitions and survives contact with a direct question for very few.
Calculate
For each dimension, average the three metric scores. Then add the five dimension averages for a total out of 20.
DimensionM1M2M3AverageCoverageResolutionDerivationFreshnessGovernance stateIndex (sum of averages, out of 20)
Read the score
0 to 6. Described. Your metadata is documentation. It supports discovery conversations and human judgment. Grounding an agent against it produces confident answers with no way to check them, and an audit request becomes a reconstruction project.
7 to 12. Partial. The modern slice of the estate is in reasonable shape and the edges are dark. Agents will be right about the well-covered path and wrong in ways that are hard to predict. Audit answers exist for some systems and get assembled by hand for others.
13 to 16. Traceable. You can answer where a number came from across most of the estate, with named exceptions. This is the first band where AI grounding claims hold up under a technical challenge from someone motivated to break them.
17 to 20. Operated. The metadata estate is run as a system with coverage, depth, provenance, freshness, and ownership. Both audiences get the same answer: an agent grounds on a governed definition, and an auditor gets a query result on demand.
Read the sub-scores alongside the total. A 14 built on strong coverage and weak derivation is a different problem from a 14 built on the reverse, and they get fixed in different orders.
What to do with it
Fix in dependency order. Coverage first, since everything downstream inherits it. Resolution second. Derivation third, because it determines whether the first two can be trusted. Freshness and governance state can run in parallel once the first three hold.
Name the gaps out loud. The list of hops where your trace went dark is more useful than the number. Write it down with system names.
Take it upstairs. A scored estate with a named gap list turns "we should invest in this" into "here's the gap, here's the quarter it closes, here's who owns it." That's the version that gets funded.
Re-score in two quarters. The number matters far less than its direction.
Written by the team at MetaKarta and released under CC BY 4.0: free to use, adapt, and republish with attribution.
