There are two very different jobs hiding inside the phrase understanding your data. One is discovery: figuring out what the data is, how it is structured, and what it means, in a system where much of that was never written down. The other is assurance: continuously verifying that the data still holds the properties you established, and catching it the moment it does not. These jobs have opposite requirements. Discovery is exploratory and benefits from inference. Assurance is repetitive and demands determinism. Trying to serve both with the same mechanism is where a lot of data tooling goes wrong.
A durable architecture separates them into stages: learn, prove, compile, execute. Learning is where inference is appropriate and where model use, when used at all, belongs. Proving is where hypotheses become evidence-backed facts. Compiling is where those validated facts turn into deterministic checks. Executing is where those checks run, cheaply and repeatably, without asking a model anything. The value of the split is that inference happens once, under supervision, and verification happens forever, without it.
Learn: form hypotheses from evidence
Learning is the discovery stage. It reads catalog metadata, engine statistics, and bounded samples to form hypotheses about structure and meaning: this column is a key, these two tables are related, this field is an undeclared enumeration, these systems reconcile within a certain window. This stage is genuinely exploratory, and it is the only stage where a model can add value, by proposing candidate interpretations that a purely mechanical pass might miss. Model use here is optional, controlled, and minimised. It suggests hypotheses; it does not get to declare truth.
The output of learning is deliberately provisional. Everything it produces is a candidate waiting to be tested, and it carries the evidence that motivated it. That provisional quality is a feature, because it forces the next stage to exist rather than letting a plausible guess masquerade as a fact.
Prove: turn hypotheses into evidence-backed facts
Proving is where a hypothesis is tested against the data and either promoted to a fact or discarded. A candidate key is proven by confirming uniqueness. A candidate relationship is proven by measuring value containment and cardinality and counting orphans. A candidate enumeration is proven by confirming the value set is closed. Each proven fact carries the evidence behind it, so that anyone can later ask why the system believes it and get a concrete answer rather than an appeal to authority.
Discovery that cannot show its evidence is just a confident guess. The proof stage is what makes a fact defensible when someone challenges it a year later.
This is also where inference is deliberately shut out. A fact is a fact because the data supports it, not because a model asserted it. Keeping proof mechanical and evidence-based is what makes the whole pipeline trustworthy, because it means the knowledge base is grounded in the actual system rather than in a plausible narrative about it.
Compile: freeze validated knowledge into checks
Compilation takes the proven facts and turns them into deterministic checks, expressed as concrete queries and constraints that can be run against the database directly. The relationship you proved becomes a check that counts orphans. The uniqueness you proved becomes a check that detects duplicates. The reconciliation window you learned becomes a check that flags divergences older than it. Once compiled, these checks are ordinary, inspectable, repeatable operations. They do not call a model, they do not vary between runs, and they produce the same answer given the same data.
- Learn: propose candidate structure and meaning from metadata, statistics, and bounded samples.
- Prove: confirm or reject each candidate against the data, keeping the evidence.
- Compile: freeze proven facts into deterministic, inspectable checks.
- Execute: run the compiled checks continuously, with no model in the loop.
Execute: verify continuously and deterministically
Execution runs the compiled checks against the live system on whatever cadence assurance requires. Because the checks are deterministic, execution is cheap, predictable, and auditable. The same check produces the same verdict, which is exactly the property you want from something that gates a migration or watches a cross-system boundary. There is no per-run inference cost and no per-run variability, which is what makes continuous assurance affordable at enterprise scale.
This is the concrete reason compiling validated knowledge beats calling a model forever. If verification depended on continuous model inference, every check would carry the cost, latency, and non-determinism of a model call, and the same question could get different answers on different days. Compilation pays the inference cost once, during learning, and then never again. What runs in production is deterministic logic derived from proven facts, not a model being re-asked to reach the same conclusion repeatedly.
Drift and relearning
Data and systems change, and compiled knowledge can go stale. A column repurposed, a new state added to an enumeration, an integration re-plumbed so its propagation window shifts. The architecture handles this through drift detection and targeted relearning. When execution starts producing verdicts that suggest the underlying reality has moved, that drift signals a return to the learn stage for the affected part of the model, and only that part. Relearning is scoped, not global, so the system does not throw away everything it proved to accommodate one changed table.
Crucially, relearning re-enters the same pipeline. New hypotheses are proven before they are trusted and compiled before they run, so drift never lowers the evidentiary bar. The knowledge base stays current without ever regressing to unproven guesses.
Why the separation matters
The learn, prove, compile, execute model resolves the tension between exploration and verification by giving each its own stage with its own rules. Inference lives where it helps and is minimised and supervised. Proof grounds everything in evidence. Compilation converts that evidence into checks that run deterministically and forever. Drift keeps the whole thing honest over time without abandoning rigour.
In controlled, synthetic validation, compiling proven structural and cross-system facts into deterministic checks produced stable, repeatable verdicts across runs, while injected drift was caught and routed back through proof before recompilation. The architectural claim is modest and, we think, correct: use models where discovery genuinely benefits from them, prove before you trust, and compile what you have proven so that assurance runs on deterministic logic rather than on an endless sequence of model calls.