Writing

Rules should be learnable, not hard-coded

Prompt injection and static rule systems both fail when regulations change. Differentiable deontic logic (obligations, permissions, and prohibitions as trainable operators) is the missing layer between LLMs and law.

Every LLM system I have seen in production eventually runs into the same wall: it needs to enforce rules (business rules, compliance requirements, safety constraints), and there are exactly two standard approaches to that, both wrong in the same fundamental way.

The first approach is to put the rules in the prompt. "Never recommend a product that isn't in stock. Always cite a source. Do not discuss competitor pricing." This works until the context window gets crowded and the model starts forgetting the rules. Or until a user phrases their question in a way the prompt didn't anticipate. The rules are instructions, and instructions can be ignored, overridden, or lost.

The second approach is to hard-code the rules in logic. An engineer reads the regulation, translates it into if-then code, and deploys it as a filter. This is auditable and reliable, until the regulation changes, or a new jurisdiction adds a conflicting requirement, or a court ruling shifts the interpretation of a key term. The rules are frozen at the moment someone transcribed them. The world keeps moving.

Both approaches fail in the same way: the rules cannot learn. They cannot update from evidence. They cannot reconcile conflicts. The thing they govern always changes eventually, and when it does, they become wrong without telling you.

What deontic logic gets right

Deontic logic is the formal study of normative reasoning: obligations, permissions, and prohibitions. It has existed as a branch of philosophy since the 1950s. In its classical form it is powerful and brittle: it can represent complex rule systems, but it cannot handle exceptions cleanly, and it cannot learn from data.

Defeasible deontic logic extends it in the right direction. Defeasible means "can be overridden." A defeasible rule says "this obligation holds, unless a higher-priority rule says otherwise." This maps directly onto how law actually works: a general prohibition can be overridden by a specific permission; a jurisdiction-level rule can be overridden by a national law; a regulation can be superseded by a court ruling.

The result is a rule system that can represent the structure of real-world compliance: hierarchical rules, explicit conflict resolution, and a reasoning trace that explains every decision. Unlike a neural model, a deontic logic system can tell you exactly which rules fired, in what order, and why one overrode another.

Making rules differentiable

The insight that unlocks the next step is this: if you implement deontic operators (obligation, permission, prohibition) as differentiable functions, you can train them from data.

In practice, this means representing each rule as a soft constraint with a weight. A weight near one means the rule almost always applies. A weight near zero means it almost never does. Weights are initialized from expert knowledge and updated by gradient descent as the system observes labeled cases: legal rulings, compliance decisions, historical outcomes.

The differentiable obligation operator for a rule r at input x becomes a function that computes how strongly x activates r, weighted by the learned importance of r. Conflicts between rules are resolved by a priority function, also learned. The whole system is trainable end-to-end.

Same 16 cases, two ways of drawing the boundary

Each point is a case with two rule-activation strengths. Color = ground truth (obligated or not). A red ring means the current boundary got it wrong.

consent-evidence strength →retention-period strength →
Misclassified: 5/16. The hard cutoff treats both rules as equally decisive with a fixed 50% threshold each — but consent evidence actually matters 3x more than retention period in this case law. A learned weight discovers that ratio from labeled outcomes instead of an engineer guessing it once and freezing it.
Compliance accuracy: three approachesDifferentiable DDL combines the adaptability of neural models with the auditability of symbolic rules. Tested on CUAD legal dataset.
Loading chart...

The architecture

The pipeline has three stages. First, a language model (Legal-BERT or a domain-adapted equivalent) embeds the incoming document or query and extracts entities and the facts that apply to them. Second, the differentiable deontic logic layer evaluates the applicable rules against those facts, resolves conflicts by learned priority, and produces a compliance verdict with a confidence score. Third, the reasoning engine generates an audit trail: a human-readable explanation of which rules applied, which conflicted, and how the conflict was resolved.

This produces something that a pure neural model fundamentally cannot: a complete trace from statistical signal to legal conclusion. The embedding layer handles the messy, ambiguous real world. The logic layer handles the structure of obligations and their interactions. Each component does the job it is suited for.

Three rule architectures comparedThe right architecture depends on how often the rules change and how strongly you need to explain your decisions.
ArchitectureUpdate costExplainabilityHandles conflictsAdapts to new regulations
Prompt injectionEdit the promptNone — model decidesNo — follows instructions inconsistentlyBrittle — depends on rephrasing
Static YAML / code rulesEngineer manually rewritesFull — rule trace is the codeManual — engineer resolves by prioritySlow — requires code deployment
Neural model onlyFull fine-tuningNone — weights are opaqueImplicit — model learns patternsRequires retraining on new cases
Differentiable DDLFine-tune on new casesFull — rule trace is explicitLearned priority functionAdapts from labeled decisions

Why this matters now

The EU AI Act requires that high-risk AI systems provide human-readable explanations of their decisions. For a classification model or a RAG answer, this is hard. The model cannot tell you why it decided what it decided; the answer is distributed across millions of weights.

The penalty structure makes this concrete rather than aspirational: under Article 99(4), violations specific to general-purpose AI model obligations carry fines up to €15,000,000 or 3% of global annual turnover. That's a separate, lower tier from the €35M/7% ceiling for prohibited practices, but still high enough that "the model can't tell you why" is not a viable answer to a regulator.

For a differentiable deontic logic system, the explanation is the rule trace. Rule R3 (GDPR Article 17 erasure right) applied because the subject is an EU data subject. Rule R7 (legitimate interest exception) was considered but overridden by R3 because R3 has higher jurisdictional priority. Erasure required. That is the kind of explanation regulators mean when they say "explainable AI." Not a saliency map. A reasoning chain.

Differentiable DDL in productionWhat the system produces for each decision, and what that satisfies in regulatory terms.

The output of the deontic logic layer — one of three states, with a confidence score and the rule that determined it.

The goal of AI systems in high-stakes domains is not just to make good decisions. It is to make defensible decisions: ones that can be explained to a regulator, reviewed by a human expert, and updated when the world changes. That combination of accuracy, auditability, and adaptability is not achievable with any single approach. It requires a system that is partly statistical and partly logical, with the statistical layer handling perception and the logical layer handling norms.

Rules that can learn are not a compromise between neural and symbolic AI. They are what you need when the rules are real and the consequences are serious.

That's the same line practitioners are drawing in production agent design:

jon allie on why you should ask an LLM to write the deterministic program, not put it in the hot loop.

References: DiffDDL — Differentiable Defeasible Deontic Logic, Garcez & Lamb, Neurosymbolic AI: The 3rd Wave (2020), EU AI Act, Article 99