In this chapter
- Design time and run time. Why the AI drafts, a person decides and templates build.
- Approvals compound. Every approval becomes the next suggestion’s demonstration.
- The approval boundary. Nine kinds of decision a person approves, whatever the AI recommendation workflow.
Answering a question about your data is run time. So is the load that feeds it. Deciding what that data means is design time, and it matters more if you build it. AIMS (AI-ready, Meaning-first Silver) splits the work three ways. The AI drafts, a person decides, and templates build from approved metadata alone.
Why does the split fall where it does?
A model is reliable at drafting: descriptions, types, candidate mappings and classifications. It’s unreliable at what a business key really identifies, at the rules your business never wrote down, and at whether two identifiers in two systems are the same customer. Those decisions change meaning or values. That’s where being confidently wrong costs you most.
So the AI does most of the hours: the discovery, the profiling, the drafting, the first version of every mapping. A person does most of the risk: identity, equivalence, history, anything that changes a value. That’s controlled acceleration, and it’s how AIMS does AI governance. The repetitive modeling work gets cheaper while you keep control of meaning, standards and approval.
A suggestion reads what an analyst would read
Give a model the inputs you’d give an analyst. That means a source table’s profile (statistics on each column’s values) and its declared keys. The inputs also include the meanings a person has already approved for sibling tables, the other tables from the same source.
How well can a model map a database to an ontology? In September 2026, Thombre, Patwardhan and Sarawagi measured large language models on a standard benchmark for the task. In one pass, a model scored 0.10 on the benchmark’s measure, a harmonic mean of precision and recall where 1.0 is a complete and correct mapping.
Their staged pipeline first rules out impossible candidates with fixed rules (symbolic constraints), before the model ranks the rest. Then it shows the model worked examples, called demonstrations, grounded in mapping patterns. It reached 0.56, more than half of the mapping, with a person checking the rest.
Here AIMS makes an inference the paper doesn’t. The paper’s demonstrations are generated automatically. In AIMS, they’re your prior approvals. So in the worked example, the suggestion for the sales system’s AccountName reads the approved mapping of the order system’s Name to Customer Account Name. That’s our reading, not the authors’ claim. It’s also why the ontology compounds. Every approval is a fact for the agent and a demonstration for the model that proposes.
A finished hub taught the next hub nothing.
Every suggestion shows its evidence
A suggestion is a claim with its reasons attached. A suggestion with neither evidence nor a stated assumption isn’t shown. That’s because a guess that can’t say why should never reach your attention.
In AIMS, the model never faces the whole search space. As in the study, fixed rules prune the candidates a column’s type or profile rules out. So the model chooses among plausible answers. A fixed self-check then catches a confident answer the profile disproves, before anything reaches the queue.
The approval boundary, decision by decision
AIMS draws a line where models read badly. Above it, a person approves each of these nine kinds of decision, however confident the model. That line is the approval boundary.
- Creating or redefining a business entity, a business thing your data is about.
- A business key, what identifies one thing in its record source.
- An equivalence, the decision that records in two systems are the same thing, stated in match rules and manual matches between business keys.
- A relationship’s cardinality or role, how many rows on each side can match and the part each side plays.
- A history policy or a delete policy, how much history a table keeps and what a source’s delete does to it.
- Any conformance that changes a value, bringing a source’s values in line, such as a code mapping, a unit conversion or a cleanup beyond trimming spaces and fixing case.
- Signing off a classification, such as how sensitive the data is.
- A survivorship rule, which source’s value wins when two disagree.
- Adding a critical class to a project, or removing an added one. A project is the unit of work a set of tables is organized and generated in.
The four built-in critical classes are the columns that identify, relate, hold a code or hold sensitive data. Below the boundary, a suggestion may be accepted in bulk and reviewed later. That covers descriptions, business names inside your naming convention, high-confidence mappings on columns outside the critical classes, and rules that only warn. A wrong answer there changes no value. Fixing it later is cheap.
How much of that lower queue must a person click through? That’s the AI recommendation workflow. A person can review each suggestion, accept suggestions in bulk while still confirming them, or let suggestions at or above a set confidence go through automatically.
The AI recommendation workflow is a throughput setting. The boundary is a trust setting. A throughput setting must never be able to spend trust.
So no option, automatic acceptance included, can accept a decision on the list above.
Figure 9.1: suggestions with evidence, and a boundary the AI recommendation workflow cannot cross.An accepted guess is still a guess
Accepting a suggestion means “good enough for now”. It never means whoever accepted two hundred mappings in bulk vouched for each one. Our post “Keep AI-generated metadata marked after you accept it” put the principle in a heading: “Accepting is a decision, not authorship.”
So in AIMS, a value the AI proposed keeps the record of what proposed it, with its confidence score and rationale, until a person changes the value. That record is its provenance. It survives acceptance. The audit trail adds who accepted it and when. Both are kept because the next reader of a mapping is often another AI run.
Templates generate, and nothing guesses at run time
Once a person approves, the model leaves the room. In AIMS, approved metadata renders through templates into the tables, loads and tests. No model call happens in the load, and no template reads anything a person hasn’t approved.
That’s what makes the boundary worth drawing. If a model ran inside the load, every approval would be advice to a process that could reinterpret it at three in the morning.
A 2026 study measured the difference. Given exact metric and dimension definitions as text but no enforced policy, an agent still leaked data across tenants on 35 percent of a hundred reporting questions. That’s because a rule it can only read is advice. With the same definitions governed and the join paths and access policy enforced, it leaked on none.
The loop closes with numbers a machine computes the same way on every run, from quarantine rates to counts of references that point at no record. Where’s the number that says all of this is faster? We don’t have one. And we won’t borrow the time-to-value figures in circulation, which are vendors’ marketing.
| The structural answer | A vault team wrote its mapping sheet by hand, so the judgment that a column was a business key lived in a modeler’s head, with no evidence beside it. |
| What the agent reads | The evidence on each suggestion and the provenance on each accepted value, so it can say which mappings a person decided and which are still guesses. |
| Yours to decide | How much of the AI’s work below the boundary a person reviews one by one, knowing no setting reaches above it. |
In DeltaVault today
DeltaVault, our metadata catalog, already keeps provenance this way, in the catalog itself, whichever platform you generate for. When you accept a value its AI proposed, the value keeps an AI badge, with the model’s confidence and rationale where it gave one. The badge stays until a person edits that field.
The AI recommendation workflow is there too, as a setting. Review each suggestion has a person approve AI matches one at a time. Allow bulk review is the default, and a person still confirms every match. Auto-accept high-confidence matches applies matches and drafted attributes at or above the confidence floor, with no person reviewing them first, and the product marks it as not recommended. An automatic accept is recorded under the same audit trail as a manual one.
The silver templates AIMS describes aren’t shipped in DeltaVault yet.
