The Constrained Expert System

The gap I lived — Drools & jBPM

Years ago I built expert systems on JBoss Drools and jBPM — a production rules engine (real DRL rules, decision tables) and a BPM workflow layer, sold as the way to finally close the gap between business and IT.

The pitch was intoxicating: business analysts would author the rules, the engine would execute them, developers would step back. It did not happen. What I learned building those systems is that the gap didn't close — it just moved:

• DRL was "for business analysts," but in practice only developers could author and maintain it. So the expert still had to route their knowledge through a developer — the gap relocated, it didn't vanish.
• That routing was the knowledge-acquisition bottleneck: the expert explained, a developer translated to rules, slowly and lossily, and the expert couldn't verify the result.
• Rule bases exploded. Hundreds of interacting rules, Rete conflict-resolution surprises, and no regression net — change one rule and pray. They rotted.
• jBPM's "no-code" leaked at every edge: the process model still needed developers to wire service tasks, data mappings, and integrations.

The problem was never the engine or the DSL. It was the human bottleneck in authoring and maintaining the rules — and the expert's inability to self-serve.

Hold that thought. It is the entire argument, because it names the one thing an LLM is unusually good at — and it is not "writing your app."

The LLM-as-compiler trap

The fashionable dream is the LLM as a universal compiler: describe any problem in English, receive code, data pipelines, and deployment. No formalism, no constraints — natural language in, working system out.

It is seductive and, as a general target, wrong. An unbounded generator is ungrounded (it invents entities, APIs, and assumptions that don't exist), unreliable (ask twice, get two systems), and non-reproducible (there's no artifact a human can certify — only an output you re-roll). For anything that has to be trusted, that's disqualifying.

Constrain the AI more, not less

Here is the inversion. A good human developer isn't valuable because they can write anything — they're valuable because they work inside an architecture: the data model, the APIs, the domain's rules. The constraints are what make their output trustworthy.

So the move isn't to free the AI from those constraints. It's to bind it tighter — to make it play with configurations and building blocks, not raw code; to make it a rule generator bounded by an ontology, not a compiler bounded by nothing. Every prior attempt to close the business–IT gap — Drools/jBPM, classic expert systems, model-driven development, low-code, DSLs — reached for exactly this constrained shape. They all stalled on the same rock: someone still had to acquire the knowledge and maintain the rules, and that someone was a scarce human.

Keep the LLM out of the decision loop

This is the sentence the whole idea rests on. The current wave of "LLM + your data" systems keeps the model on the hot path: every decision is a fresh generation. That's why they're hard to trust — a per-query answer is non-reproducible and unaccountable.

Invert it. Put the LLM at authoring time — where it drafts and maintains the rules, with a human expert approving — and take it out of the loop at decision time, where the approved rules execute deterministically. Ask the system the same question twice and get the same answer, every time, from logic a human signed.

This one move buys reproducibility, an audit trail, and a defensible artifact — the three things a hot-path LLM cannot give you, and the three things a regulated domain demands.

Meta-DSL once, instances forever

The hardest part of every expert system was defining the DSL — the vocabulary and building blocks the rules are written in. Get it wrong and everything downstream is wrong; getting it right took standards committees years. That's the rock to get past, and the trick is to split the problem in two.

Step 1 is the one place you spend real expert time: co-design the meta-DSL with the LLM through a visual, reversible wizard — go forward, go back, watch the model take shape, ground every term in the ontology. Step 2 reuses that fixed meta-DSL to generate an instance per feature, at near-zero cost.

Where it gets real: clinical protocols

Pick a domain that is unforgiving and already semi-formal, and the whole argument stops being abstract. Clinical-protocol checking is that domain — and it comes with a graveyard that proves both the doability and the "why now."

The ruins tell you what to do

This has been attempted, formally, for thirty years: Arden Syntax (HL7 Medical Logic Modules — literally a clinical rule DSL), GLIF, PROforma, SAGE, and today's CDS Hooks / FHIR Clinical Reasoning. These are the constrained-expert-system idea, minus the LLM. Two lessons fall out of the wreckage:

• The solution shape is known and bounded — eligibility criteria, dosing rules, decision trees. A rule/constraint object, not arbitrary code. That's the doability proof: we're filling a known shape.
• They stalled on authoring, not execution. Arden's infamous "curly-braces problem" — mapping each rule to a site's actual data was manual agony — is the knowledge-acquisition bottleneck by another name. And FHIR + SNOMED/LOINC already give us the grounding ontology, so the LLM generates against real, bound terms — and anything unbound is flagged.

The one-line framing: Arden Syntax, but the LLM is the medical knowledge engineer — grounded in FHIR/SNOMED, and every rule gated by a clinician.

Trust, without a black box

Clinical is unforgiving: one hallucinated dosing rule and the system is radioactive. So a clinician can't rubber-stamp raw logic — they review the way guideline committees already do: behaviour and evidence. The lean bar needs no patient data and no solver:

The building blocks already exist

The reason I'm confident this isn't another beautiful stall: the component categories it needs already exist and are reusable. We built Context Graph as a decision-aware knowledge graph, and it happens to supply most of the generic machinery — the authoring, grounding, and governance plumbing — that a system like this leans on. Not the clinical system; its scaffolding.

The table is the generic plumbing. The clinical layer is net-new: a FHIR/SNOMED-bound ontology, the clinical rule language itself, the vignette format, and the visual, reversible meta-DSL studio (Step 1's UX) with a span-level citation review surface — plus, for the roadmap, the consistency-prover. Notably, none of that is AI magic; it's mostly bookkeeping and interface over machinery that runs on localhost right now.

The payoff: two tiers, one closed gap

Land this and you get a two-tier world. Experts — a clinician, an underwriter, a compliance officer — use the define-once studio to build a domain application by declaring its objects, rules, and building blocks, with the LLM doing the translation they could never do alone. Non-experts then use those applications without touching code or infrastructure, trusting them because every rule is grounded, cited, and signed.

That's the gap — the one Drools and jBPM and every expert system reached for and couldn't close — finally closing. Not because the AI got powerful enough to build anything, but because we got disciplined enough to let it build almost nothing: just the rules, for a machine that runs them, checked by the human who owns the risk.

Part II — the regulatory & business case — is Adoptable by Design. This essay is also a companion to The Fourth Element and the Context Graph architecture. The clinical design — meta-DSL primitives, the studio, the consistency-prover — is a further follow-up; this is the argument for why it's worth building.