Just-in-Time Ontologies: Data Intelligence Built on Demand

Just-in-time ontologies are transformations built at the moment a decision is made, not stored in advance as one universal schema. The approach replaces the dream of a single enterprise ontology with context that travels with each pipeline, and it explains why cheap intelligence changes data work from a one-time design problem into a repeatable, evidence-backed process.

What Are Just-in-Time Ontologies?

Just-in-time ontologies are data transformations built at the moment a decision is known, with context and evidence preserved for reuse. The idea rejects a single universal enterprise schema because four different schemas described in a 2026 AI Engineer talk by Hrishi Olickel of Southbridge AI cannot all be known at once except when the decision is made.

Olickel defines the four schemas this way. The source schema is whatever the recording system actually captured. The storage schema is the limit imposed by what can be written down. The decision schema is what the question requires. The fourth is the model's prior, the beliefs a language model brings to a task. A customer means whoever pays to billing, whoever calls to support, and whoever the company is on the hook for to compliance. Only the decision reveals which definition matters.

The practical consequence is that transformation becomes a merge of the recording context with the decision context. Doing that merge when the question is known, instead of ahead of time, is what the talk calls a just-in-time ontology. Ontologies then exist as intermediates between intelligence and a result, which makes them easier to reuse on the next job.

Why Does a Single Universal Ontology Always Fail?

A single universal ontology always fails because no schema can hold the source, storage, decision and model-prior schemas at the same time. Buyer resistance is real, but it is not the primary reason. Even an instant migration into one super schema would run into the absence of a schema that fits every question.

Olickel admits he argued for a universal schema when he founded Southbridge two years before the talk. The correction is precise. There is no concept of a customer divorced from the question you want to answer. Should we refund this order, or can we extend more credit, makes the needed definition and degree of certainty suddenly clear.

In most enterprises and homes, recorded data has little idea what it will be used for. That is not a governance failure that better tooling fixes. It is a property of recording information before the decision exists. Just-in-time transformation accepts the gap instead of trying to close it with one schema.

The Three Roles Models Play in Data Pipelines

Models play three separate roles in data pipelines, and coding agents tend to mash them into one context window. Olickel separates pipeline designers, pipeline workers and hill climbers, and he argues the first two pull in opposite directions. The designer wants slow, thick-token models that can walk around a problem; the worker wants cheap, fast, specialized instruction-followers with few defects.

• Designers break down the problem, write early specifications and predict how a pipeline will perform before it starts.
• Workers do the work inside the pipeline, reading documents, writing to databases and checking results.
• Hill climbers take a first run and self-optimize it, varying budgets and taking notes to find the best option.

The leaf-cutter ant colony is the analogy the talk uses: a colony runs on four different worker sizes, and every system has slots where a specific size of model belongs. Placing a decision model in the worker layer was easy precisely because decision models are workers built for quick contact with information and deployed at the bottom of large workloads.

The Ohio Campaign Finance Entity Resolution Case

The Ohio campaign finance entity resolution project showed how a decision model can be inserted into a working pipeline, with a projected $10,000 job finishing for $7.95 on an $800 budget. The pipeline decided whether Ohio campaign finance records belong to the same person, company or committee. The speaker reports that final ground truth for every donor case in Ohio was reached under $800, ten days after an initial call introducing the new model.

Three architectures were tested on a small development set. A cheap reasoning model alone matched a more capable alternative at about 2% of the cost. A heavier model went first and got the core answers right but missed nine household links because it confidently answered no to every household question. The fix was to rewrite the questions without touching models or thresholds. The household question became what counts as enough evidence, and the model moved from no on all thirteen development questions to yes.

The team ran more than a dozen rounds of that kind of qualification while scaling statewide. Each round fixed a definition: what a committee is, what a filer means, what it means when two people live at one address. All 23,317 Ohio cases ended with a label recording what the answer rests on and how far it was checked.

How Cross-Model Disagreement Concentrates Review

Cross-model disagreement concentrates human review on the families where two models differ, because agreement between different model families carried no errors on the held-out set. On roughly 200 held-out families, a decision model and a second model agreed on 194 cases and none of those shared answers was wrong. Every error sat in the six families where they disagreed.

The mechanism is model priors. Models from different families and different pedigrees tend to disagree more than models from the same group, including models distilled outside the same company. Intersecting those priors shrinks the review surface to a smaller, persistent class of problems that applies to language models as a species.

That class does not vanish. In one benchmark, four different model families produced the same total down to the cent because they shared a sign convention that the answer key did not. When models share an assumption, agreement stops being evidence. The only way forward, the talk argues, is to list those shared assumptions, watch for them and write specific fixes.

Model Priors and Sign Errors That Corrupt Data

Model priors cause a recurring class of data errors that survives validation by multiple models because every model shares the same wrong assumption. Olickel lists three failures with exact numbers. One pipeline searched for an in-kind field spelled with an underscore; the file used a capital I and a hyphen, so 15,658 in-kind contributions were counted as ordinary money and loan repayment amounts disappeared the same way. A second pipeline tried four date formats when the file used a fifth, leaving 99.4% of transaction dates empty even though every row count and dollar sum matched. A third run noticed negative loan amounts, decided the sign was redundant, stored absolute values, and turned a net $784,000 into $5.3 million of debt, validated by multiple models.

The first failure is the one a human would catch. Anyone who knew campaign finance would notice missing in-kind contributions or think to check. That is what intersecting your priors with a model's priors means in practice. Humans are also expensive, slow, disruptive and more nondeterministic than models, which is why the talk treats human review as a targeted instrument rather than a default gate.

These examples are the speaker's first-hand deployment experience, not a controlled study. They describe how sign conventions, field spellings and date formats become silent corruption when an agent verifies against its own assumptions rather than the source.

The Four Missing Pieces for Self-Optimizing Pipelines

Self-optimizing pipelines need four things that current models do not supply natively: a stable deployment surface, bounded experiments, methodology knowledge and a failure surface. The speaker reports that the current best models are only barely good at building those conditions for themselves.

• Stable deployment surface. The talk cites Hank as an example of a harness that wraps fast-moving agent runtimes, which it lists as Claude Code and PI, and exposes a tested log and API interface with checkpointing, rollback and budget enforcement.
• Bounded experiments. Cost, time and access must be controllable before any architecture test is meaningful.
• Methodology. Two years of deployment experience, agentic patterns, debugging techniques and prompting can be expressed at a token-efficient abstraction layer that models can implement.
• Failure surface. Every stage needs a defined way to fail, whether that comes from a manually checked baseline, schema checks or measurable behaviour.

The failure surface is the piece Olickel calls hardest to put into words and tooling. His formulation borrows Archimedes: give me a place to stand, and a failure surface to iterate against, and the team has not met a constraint it could not iterate to a solution.

Six Stages of a Just-in-Time Transformation

A just-in-time transformation moves through six stages: specification, failure surface definition, bounded pilots, codon checks, deployment and staged optimization. The talk describes this as the process the team follows on each job, with the optimization happening in the middle stages.

1. Spec the job and split it. For the Ohio pipeline, roughly 800,000 rows became about 200,000 smaller specialized cases, and each case became typed questions about the kind of donor and the number of donors.
2. Decide the failure surface before starting, using good models on a manually checked slice to set a baseline, or automated schema and behaviour checks.
3. Run minimal bounded pilots to test architecture.
4. Move working checks into rigs, code that runs between bounded work segments called codons. Codons are reused, looped independently, validated and placed in sequence.
5. Deploy working pipelines to production.
6. Let them mature, swapping models for faster or cheaper options, comparing against known intermediates and tightening success requirements.

The optimization loop in stages five and six is what the talk calls burrito surfing. Each piece of a decomposed problem can move to its own best position, which keeps later revisions inspectable and reversible because every iteration is a version-controlled run.

Burrito Surfing: Tuning Cost, Speed and Accuracy Together

Burrito surfing is the optimization loop that tunes a workload for cost, speed and accuracy at once by treating a solid first architecture as a baseline and improving parts of it. Olickel reports that the agent building the Ohio system found most of these approaches incrementally on its own, by building, running, debugging and trying new things.

The reported run lasted ten days and tried more than a dozen architectures. Its runs executed more than 4,000 times alongside 90,000 calls to a decision model, and the models inside those runs consumed roughly 6 billion tokens. Those figures come from the speaker's own deployment, so they describe that pipeline rather than a general benchmark.

Cost data from the same job splits the budget between doing and checking. The statewide job cost $7.95 against an $800 budget set in advance. Checking cost about four times as much as doing: $545 for second opinions, settling disagreements and the audit, against $128 for first answers. The audit budget for the next state is expected to approach zero now that the pipeline is built and verified.

What Just-in-Time Ontologies Mean for Data Teams

For data teams, just-in-time ontologies turn transformation from an expensive upfront project into a bounded pipeline that can be tested and reused. The talk opens with a reference to Hannes Mühleisen's 2023 DuckDB post asking whether the industry lost a decade chasing distributed architectures that assumed compute and storage were slow and expensive. Capability defines architecture, and tooling lags behind it.

The implication is that every ontology and schema becomes valid as long as its context can be labelled and preserved. That is a different standard from correctness against one canonical model. It requires definitions, held-out cases, disagreement checks and evidence to travel with the pipeline.

The four things Olickel says not to do are also the four things he says not to skip: don't force one schema on all questions, don't let one model play all three roles, don't equate model agreement with correctness, and don't build without a failure surface. If you want to go deeper into modern data and full-stack engineering, Crazystack Typescript and the Bootcamp do Dev Doido cover the implementation side, and Gustavo Dev Doido teaches that stack in Portuguese.

FAQ

• What is a just-in-time ontology? A just-in-time ontology is a data transformation built when a decision is known, with its context and evidence kept for reuse. It replaces the attempt to design one universal schema before anyone knows what questions the data must answer.

• Why do single universal ontologies fail? They fail because the source, storage, decision and model-prior schemas cannot all be known at once. The definition of something like a customer changes with the question, so a schema fixed in advance captures only one of several valid meanings.

• What are the three roles models play in data pipelines? Designers break down problems and write specifications, workers execute tasks inside the pipeline, and hill climbers optimize a working system. The talk argues that designers and workers need opposite model characteristics, so assigning both to one model causes problems.

• What is burrito surfing in this context? Burrito surfing is the optimization loop that starts from a solid architecture and improves parts of it for cost, speed and accuracy. It relies on a stable execution surface, bounded budgets and a defined failure surface so that each change can be measured.

• How did the Ohio campaign finance pipeline perform? The speaker reports the statewide entity-resolution job cost $7.95 against an $800 budget, with checking costing about four times as much as first answers. The work was expected to cost about $10,000 before the new model was introduced.

• What are the four schemas described in the talk? The source schema, the storage schema, the decision schema and the model-prior schema. Only at the moment of a decision can all four be known well enough to merge them into a useful transformation.

• What is a failure surface in a data pipeline? A failure surface is the defined way a pipeline fails, set before work begins. It can come from a manually checked baseline, schema checks or measurable behaviour, and it is what makes bounded pilots and later optimization meaningful.

• Does model agreement prove a data pipeline is correct? No. Agreement across several model families can still hide a shared wrong assumption, such as a sign convention that turns a net gain into debt. The talk treats disagreement between model families as the more useful review signal.

• What is a codon in this pipeline design? A codon is a check that runs between bounded work segments. Codons are reused, looped independently, validated and placed in sequence, which keeps revisions inspectable and easy to revert.

Source video