/

Data

Nobody tells you your metadata is wrong

Data

Mahesh Chandran

CEO

A dashboard's description reads: Sales Dashboard.

It doesn't say which metrics it carries, which source it pulls from, which of the four similarly named dashboards it is, or whether last quarter's numbers in it can be trusted. Someone will use it anyway.

That isn't a documentation gap. It's a trust failure, and it spreads. An analyst who gets burned once by a vague description stops believing the catalog. Then they stop opening it. Then they ask a colleague instead, and the colleague guesses. Adoption stalls, and the catalog you paid for becomes a directory nobody opens.

This is about to get more expensive. AI agents are becoming primary consumers of catalogs, and an agent doesn't hesitate over an ambiguous description. A human notices that something reads oddly and asks someone. An agent picks the most plausible reading and proceeds. The ambiguity never surfaces as a question. It surfaces as a confident answer that happens to be wrong.

Coverage is not usefulness

Most governance programs measure the thing that's easy to count: percentage of assets documented. You can reach 100% and have gained nothing.

A field described as "customer ID" is documented. If the real answer is "customer ID, but only for accounts migrated after 2023, and null for resellers," it's also misleading. The gap between documented and useful is where trust actually breaks.

The missing piece is a feedback loop

Metadata doesn't go stale because teams are careless. It goes stale because nothing tells them which entries are failing.

Governance teams write descriptions and then hear nothing back. Feedback arrives anecdotally, months late, usually in a meeting, usually about one asset someone is annoyed by that week. Nothing tells anyone which of four thousand descriptions are actively costing people time. So the work gets prioritized by whoever complains loudest, or it doesn't get prioritized at all.

What we built into DQHQ

The fix is unglamorous: put the feedback where the failure happens.

In DQHQ, every data asset carries a thumbs up and a thumbs down. A thumbs down asks one follow-up, answerable in a click:

  • The description is incomplete

  • The wording is unclear

  • It didn't answer what I came for

That's the whole interaction. No form, no ticket, no context switch.

The signal routes to the governance team as a ranked queue: asset name, current description, what the user said was wrong, and how many others said the same thing. A backlog of real problems, ordered by how often people hit them.

What changes

Two things, and the second matters more.

The obvious one is direction. Governance teams stop guessing and start working a list.

The less obvious one is trust. A user who watches their feedback turn into a corrected description starts believing the catalog again, and people who believe it contribute to it. The context layer stops decaying and starts compounding.

That second effect only happens if you close the loop out loud. Tell the person who flagged it that it's fixed. Skip that step and the feedback dries up within a month, because from where they sit, nothing happened.

The technical build is a weekend. Working the queue and telling people you worked it, that's the actual project.

Why this is now urgent

Every signal you capture today is shaping the context layer your agents will read tomorrow.

Human analysts route around bad metadata. They sense something is off, ask a colleague, check the source table themselves. That tolerance has quietly absorbed the cost of poor context for years.

Agents have no such instinct. They read what you wrote, believe it, and act on it.

The cost of a bad description used to be one analyst's afternoon. Now it's however many times an agent reads it before somebody notices.