Ontolith
← Research

Method

Not smarter, informed: ontology-conditioned inference

July 2026 · 8 min read

Ask a general-purpose model to run your claims-approval workflow and it will produce something that looks right: a sequence of steps, a few tool calls, a confident summary. Look closely and it has invented the process. It approves at a threshold your policy doesn’t use, routes to a queue that doesn’t exist, and calls an authority level no one at your company holds. It was not wrong because it is small or because it is large. It was wrong because it had never seen your company.

This is the observation Ontolith is built on. For enterprise execution, the binding constraint is almost never raw capability. It is information: does the model know your org chart, your entitlements, your schemas, and the policy that governs the exact decision in front of it?

The parameter reflex is the wrong instinct

The industry’s answer to "the model got the process wrong" is reflexively "use a bigger model." Sometimes that helps, because a larger model has absorbed more generic patterns and one of them happens to resemble your workflow. But it is resemblance, not knowledge. The 400B model still doesn’t know that in your organization a refund over a threshold requires a second approver, or that this particular queue was deprecated last quarter. It hallucinates a plausible enterprise, more fluently.

Scaling parameters buys you general competence. It does not buy you the one thing enterprise execution actually requires, which is fidelity to a specific, private, structured reality. That reality is not in any pretraining corpus. It lives in your systems.

Two mechanisms, not a bigger model

An Ontolith model beats a much larger one on your workflows because it is handed that reality, in two forms, on every single request.

1. The grounding compiler: your world as structured context

Every enterprise has an ontology whether or not it is written down: the entities that matter (people, roles, systems, policies, workflows), and the relationships between them (who holds which role, who approves what, which system governs which action). Ontolith makes it explicit and typed. Connectors ingest it from what you already have, identities, HR, a CMDB, policy documents, your API and tool schemas, validated on the way in.

At inference time, the grounding compiler does not dump the whole graph into the prompt. For each request it selects the subgraph in scope, the specific entities, policies, and constraints that bear on this decision, and injects them as structured context. The model reads your actual approval chain instead of guessing at a generic one. The size of the model is almost beside the point once the answer is present in front of it.

2. Constrained decoding: rules it cannot break

Grounding tells the model what is true. Constraints enforce what is allowed. Hard rules from the ontology, the tools that exist, the schemas that are valid, the permission boundaries that apply, are compiled into the decoder itself. The model does not "try" to stay in schema and occasionally slip. At the token level it cannot emit a malformed action, an out-of-schema field, or a call to a tool that isn’t there.

This is the difference between a benchmark number and a contract. "99.5% valid on our test set" is a hope about the next input. Validity enforced at the decoder is a property of every output, including the inputs you never tested. That is what makes reliability something you can put in an SLA rather than a slide.

What "informed" actually buys

Once the model is small and informed rather than large and guessing, the rest of the value proposition stops being a trade-off and starts being a consequence:

  • It runs in your perimeter. A 3-7B model deploys on-prem, in a VPC, air-gapped, or on an edge NPU. Your data, and the workflow it grounds on, never leave.
  • The unit economics invert. You are no longer paying frontier-API rates to rent a 400B model for a task a 5B model does more reliably, because it is the one that actually knows your process.
  • It is auditable by construction. Every decision is grounded on a specific, versioned ontology, and each model passport pins the exact version behind it. "Why did it approve this?" has an answer that predates the output.

Where this does not help

Informed-beats-bigger is a claim about execution on your workflows, not a claim that small models are better at everything. Open-ended reasoning over novel problems, long creative generation, frontier-level general knowledge: those still favor scale, which is exactly why the router keeps your frontier accounts and escalates to them when confidence drops. Ontolith is the front door for the 90%+ of traffic that is structured execution, not a replacement for a general model on the long tail.

And the mechanism is only as good as the ontology behind it. Ground a model on a wrong approval chain and it will faithfully execute the wrong one. The work of getting the ontology right, and keeping it current as your systems change, is real. It is also work you control, inside your perimeter, rather than a black box you hope has guessed correctly.

Not smarter, informed

The headline number everyone reaches for is parameter count. It is the wrong number for enterprise agents. The model that wins on your approval chain is not the one that has read the most of the internet. It is the one that has read your approval chain, and cannot act outside it.

A quantitative companion to this piece, the Execution-Reliability Benchmark with methodology and measured results, is in preparation.

Evaluation sandbox

See it on your own workflow.

The evaluation sandbox runs your traces against an Ontolith model and a frontier baseline, reliability and cost measured side by side.