The neuro-symbolic runtime

Large language models changed how people interact with computers. They did not solve the central problem of enterprise systems.

Organisations do not work with text. They work with knowledge — structures, procedures, legal constraints, and accountability for outcomes. A language model has none of that. It predicts the next token, extremely well.

So enterprise AI needs another layer. We call it a neuro-symbolic runtime: an execution environment that combines two fundamentally different modes of reasoning and switches between them continuously while a task runs.

The two halves

The neural half handles what statistical models are good at: understanding language, reading messy documents, extracting entities, generating hypotheses, planning multi-step work, and holding a conversation with a person. It is fast, general, tolerant of ambiguity — and it will produce a fluent, well-structured, wrong answer without any change in tone.

The symbolic half holds the things that must be exactly right: the ontology of the domain, the rules and constraints, the classifiers and reference data, the policies, the typed relations between entities, and the chains of justification. It is narrow, brittle outside its scope, and — crucially — checkable. A symbolic assertion either holds or does not, and you can print the reason.

Neither is sufficient. A purely neural system is fluent and unaccountable. A purely symbolic system is accountable and cannot read an email. The interesting engineering is in the interleaving.

The loop

At execution time, a single task does not go "model, then check". It oscillates.

1. Intent. The neural layer turns a request — a message, a document, a queue item — into a structured intent: what is being asked, about which entities, on whose behalf.
2. Grounding. Relevant material is retrieved: documents, records, prior decisions, applicable rules. This is where retrieval belongs — as a step, not as the architecture.
3. Proposal. The model proposes a next action: a classification, a tool call, a draft answer, a plan.
4. Symbolic validation. The proposal is checked against the domain model. Do the referenced entities exist? Is the classification valid in the current version of the nomenclature? Do the constraints hold? Do the cited sources actually support the claim?
5. Policy evaluation. Independently of whether the proposal is correct, is it permitted? This agent, this tool, this data, this user, this threshold, this jurisdiction.
6. Execution or escalation. If it validates and is permitted, the tool runs. If it fails validation, the failure — with its reason — goes back to the model as input for a revised proposal. If it is valid but consequential, it stops and waits for a human.
7. Verification. After execution, the result is checked again: did the effect match the intent, is the output well-formed, does the record now satisfy the invariants it should.
8. Trace. Every step above is recorded as evidence, not as a log line — the proposal, the check that passed, the rule that applied, the person who approved.

The failure of step 4 is not an error condition. It is the mechanism. A rejected proposal carrying a machine-readable reason is better input to the model than the original prompt was, which is why the loop converges on cases where a single pass would have hallucinated.

What this buys

Explainability becomes structural rather than narrative. The system does not ask the model to explain itself — a model's self-explanation is another generation, with the same reliability characteristics as the answer. The explanation is the trace: the rules that fired, the sources that were checked, the constraints that held.

Reproducibility becomes possible because the decisive steps are deterministic. The model's sampling affects which proposals are considered; it does not affect which ones are accepted. Run the same case tomorrow against the same domain model and the same policies and you get the same decision — and when the decision changes, you can point at what changed.

Trust follows from the two above plus the ability to bound behaviour. An organisation can state, and demonstrate, that a class of action is not reachable — because the policy layer, not the prompt, decides.

What it does not buy

Being clear about this matters more than the marketing does.

This architecture does not make a system safe by construction, and it is not formal verification. The checks are only as good as the domain model behind them, and building that model is real work that no vendor performs for you in a demo. Coverage is partial: some claims are checkable against structure, others are not, and a runtime that pretends otherwise is worse than one that routes the unverifiable to a human.

It also does not eliminate hallucination. It changes what a hallucination costs. An unfounded proposal that fails a check and never becomes an action is an internal event. The same proposal in a retrieve-then-generate system is an answer someone acts on.

That is the honest claim: not certainty, but the difference between an unverified generation and a checked, bounded, attributable decision.

Why we think this is the next stage

Agent platforms today compete on how easily you can assemble an agent. That competition ends, because assembling an agent gets easier every quarter and eventually stops being a differentiator at all.

What remains hard is running agents in an organisation that has auditors, regulators, liability and staff. That is a runtime problem, and it is the layer we think the next generation of platforms will be judged on.

---

Last in this series: Why Open Cradle — what this means for a product, and why we think a new infrastructure layer is unavoidable.