Most AI tools forget where a value came from the moment someone clicks Accept. After that, a description the model inferred about a part of your business it couldn’t see sits in your data catalog. It looks exactly like one your steward wrote. What’s thrown away is the value’s data provenance, the record of what produced it.

This is more than a cosmetic gap. It’s how a guess turns into a fact without anyone ever deciding that it should.

Some corners AI can only guess at

John Giles, who has spent a career building conceptual data models, wrote about the corners of an organization that AI might not see. His conclusion is plain: where AI cannot see, it is at best guessing. In Context for AI, context by AI we took his argument one step further. We proposed that a guess should say how good a guess it is. That’s why Map & Match suggestions and proposed table relationships in DeltaVault arrive with a confidence score and a written rationale. So what happens to the score after you accept the suggestion?

What happens to the score after you accept the suggestion?

Our honest answer used to be that it disappeared. When you accepted an AI proposal for an entity, an attribute, or a table relationship, the value was written and its origin was dropped. An accepted AI relationship looked exactly like one a person had drawn by hand.

New attributes had a worse problem. When Map & Match drafted an attribute for a column that matched nothing, the draft carried a confidence of 100%, a score no model had actually given it. With Auto-accept turned on, every one of those drafts cleared the confidence floor no matter where you set it. Each one landed in the catalog without anyone reading it.

Nothing looked wrong on the day the drafts went in. The cost showed up later. The next person to open that entity couldn’t tell which definitions came out of a workshop and which came from a model reading column names. That distinction matters, because your database is not your business.

Accepting is a decision, not authorship

Clicking Accept means “good enough for now.” It doesn’t mean “I know this to be true,” and it certainly doesn’t mean that the person who accepted two hundred column mappings in bulk vouched for each one.

That distinction matters more to the next reader than it did to the person who clicked Accept. And who is the next reader? Often it’s another AI run. A skill reads your catalog as context, treats yesterday’s accepted guess as today’s foundation, and builds a new guess on top of it. Over time, AI-generated metadata quietly becomes the context for more of the same.

The corners Giles describes are exactly where that compounding hurts, because they’re the places where a model had the least to go on in the first place.

How DeltaVault keeps AI-generated metadata marked after you accept

So we made the record outlive the review.

Names, descriptions, Map & Match mappings, and table relationships that you accept from an AI proposal keep an AI badge. Five rules govern how that badge behaves.

  • The badge travels with the value. Hover over it to read the confidence score and rationale you saw at the moment you accepted.
  • An edit is where ownership changes. Changing a field clears the badge from that field alone. Rename an entity and the description keeps its badge. Save without a change and both badges stay.
  • Auto-accept keeps the mark too. A value applied automatically stays visibly the AI’s. Drafted attributes carry the model’s own confidence, so only those that meet or exceed your floor go through.
  • No score means no number. A definition the model drafts without a score gets a badge with no percentage, never an invented one. Under Auto-accept, that draft waits for a person.

The fifth rule settles how confidence scores combine when suggestions merge. What happens when several accepted candidates merge into one relationship? That relationship keeps the lowest of their confidences. It doesn’t keep the highest, and it doesn’t keep an average. A weak guess never hides behind a strong one, and the badge on the merged relationship shows the least certain evidence it rests on.

If you pick a different target before you accept, the mapping is yours outright and carries no badge. That distinction is the point: the mark records whose judgment a value rests on, not who pressed the button.

The World Wide Web Consortium’s provenance model defines data provenance the same way. In that model, data provenance is a record of what produced a piece of data, kept so that people can judge how far to trust it.

Why not just review harder?

The fair objection is that a careful enough review makes the badge unnecessary. It doesn’t. Review happens once, under a deadline, with whatever evidence exists that day. The badge keeps working for every reader who comes after, and it tells your stewards where attention is still owed.

The badge also turns Giles’s argument into something your data governance can act on. Stewards can direct their review to the accepted values that still rest on the model’s judgment instead of rechecking the whole catalog.

The corners that only people can see are exactly where a person’s edit adds knowledge the model never had, and that edit is the moment the value becomes theirs. Your catalog can then show, field by field, which parts are still a guess and which parts someone has made their own.

Start with one source

  1. Run Map & Match on one source, then accept the suggestions you’re comfortable with.
  2. A week later, come back to the same source and hover over the AI badges to read the rationale behind each suggestion you accepted.
  3. Finally, correct one value you know better than the model did, and watch the badge disappear from that field while every other field keeps its badge.