Chapter 3 — Dissolved, Not Dead

Chapter 2 ended with a claim that deserves suspicion: that the paradigm’s revival is already in production. “In production” is the phrase every dying technology clings to — somewhere, surely, a COBOL program still runs. So this chapter holds itself to a stricter standard: not museum pieces, but systems you — a working engineer in 2026 — have plausibly touched this month, that are logic programming under the hood. The thesis is in the title. Logic programming didn’t die; it dissolved. It survived everywhere rules matter more than process — but it survived in fragments, under assumed names, each fragment re-solving a piece of the same problem in isolation. The dissolution is a triumph for the idea and an indictment of the languages, and both halves matter to this book.

You pushed code today

If your repository lives on GitHub with code scanning enabled, then on your last push a logic program ran over your code. CodeQL — the engine behind GitHub’s security scanning — is a Datalog dialect in the direct lineage chapter 2 traced: your program is decomposed into a database of facts (this function calls that one; this value flows there), a vulnerability is a set of rules over those facts, and a finding is a derived fact, complete with the derivation. The scale is planetary and the fit is exact — “tainted data reaches a SQL string” is transitive closure with extra conditions, the very shape you wrote in chapter 1. The security analyst writing a CodeQL query is doing what the sanctions officer of the prologue could not: stating the rule as a rule and letting an engine find every instance.

The pattern generalizes far beyond GitHub. The academic result that reopened this field — Whaley and Lam, 2004 — was exactly this workload, and the Soufflé engine (the one this book’s reference implementation is tested against) exists because Oracle Labs needed to analyze codebases far too large for hand-written analyzers. An entire corner of smart-contract security stands on the same footing: the Gigahorse decompiler and the MadMax gas-vulnerability analyzer — the toolchain behind Dedaub’s audit platform — are Soufflé Datalog programs deriving facts about Ethereum bytecode. Program analysis turned out to be the paradigm’s beachhead for a simple reason: the input is a huge graph of facts, the questions are recursive, and being wrong quietly is expensive. Remember those three properties; they will recur.

You deployed to Kubernetes

If your cluster gates deployments through an admission controller, odds are the gate is written in Rego, the policy language of Open Policy Agent — a CNCF-graduated project whose documentation says plainly that the language “was inspired by Datalog.” A Rego policy is a set of rules deriving judgments (“this pod is non-compliant”) from facts (the pod spec, the registry allowlist, the namespace labels). No loops, no mutation; conditions in, conclusions out. Amazon went further along the same road with Cedar, its authorization-policy language: not only declarative but formally modeled — the language’s semantics lives as a machine-checked model in a proof assistant, and the production engine is battered against that model with millions of differential tests. Hold that design next to this book’s chapter 9: a small declarative language, a mathematical semantics, and mechanical checking of an untrusted implementation against it. Authorization converged on that architecture for the same reason compliance will: when the question is “who may do what,” you need the rule you enforce to be provably the rule you wrote.

You queried one, painfully

The fragment nearest to you is hiding in your database. WITH RECURSIVE — in the SQL standard since 1999, supported by Postgres, MySQL, SQLite, and everything else you run — is a fixpoint over rules: precisely the fragment of Datalog where recursion stays linear. Every org-chart rollup, bill-of-materials explosion, and dependency walk you have expressed in it was a logic program wearing SQL’s clothes, and you have felt the clothes chafe: the syntax fights recursion so hard that most teams write the query once, wrap it in a view, comment it “here be dragons”, and never touch it again. The lesson of WITH RECURSIVE cuts both ways: demand for recursive rules over relations is so real that the most conservative language committee in software shipped it — and ergonomics matter so much that shipping it in hostile syntax produced a feature everyone needs and no one loves.

Datomic took the opposite path: instead of bolting a fixpoint onto SQL it put a Datalog query language at the center of the database. That design has run a real bank — Nubank, whose core systems sit on Datomic at hundred-million-customer scale, liked the technology enough to buy the company that made it. One honest nuance, because this book promised precision: the newest system in that family, XTDB, made SQL its primary language in version 2, keeping only a Datalog-inspired secondary interface. Datalog-as-query-language remains a minority taste. The fixpoint is what proved indispensable; the surface syntax is still contested ground — a distinction this book will lean on hard when Strata-K has to choose its own surface.

And the commercial story has a second act that reads almost like this book’s thesis filed as a business plan. LogicBlox — the Datalog platform whose retail-forecasting deployments chapter 2 mentioned — was absorbed through two acquisitions into a larger vendor’s suite, the usual quiet end for a fragment. Except its founder started again: RelationalAI, built by the same lineage of people, ships a Datalog-family language as a “knowledge coprocessor” that runs inside Snowflake — inside the data warehouse the enterprise already has, next to the data it already trusts, funded to nine figures. Whatever comes of the company, note the shape of the bet, because it is a working businessman’s restatement of chapter 2’s third bet: don’t ask the industry to adopt a logic platform; bring the rules engine to the infrastructure that’s already paid for.

Fragments that worked, and one that didn’t survive

The pattern repeats wherever rules outweigh process. Three more data points, chosen because each carries a lesson forward.

Networks. VMware built DDlog — an incremental Datalog, where changed inputs update conclusions without recomputation — and used it to reimplement the brain of the OVN virtual-network controller: six thousand lines of rules deriving flow tables from network intent, recomputing in milliseconds what full evaluation took minutes to do. It worked. And the project is nonetheless archived today, unmaintained — not because the approach failed, but because a lone language with one corporate sponsor and one flagship deployment has no ecosystem to catch it when the sponsor’s priorities move. Fragments are fragile. Remember DDlog when this book argues that the pieces need to live in one language with one community; incrementality itself returns in chapter 5 as a load-bearing requirement.

Scheduling. The stable-models branch — ASP, the theory born in the winter — earns industrial money solving allocation problems: the port of Gioia Tauro assembles its container-terminal work teams with an ASP system; Swiss Federal Railways has run train-scheduling research on clingo with real timetables; a decision system built on ASP advised Space Shuttle flight controllers on reaction-control-system failures. Niche deployments, honestly counted — but note which niche: combinatorial choice under hard constraints, exactly the ground chapter 8 builds @asp on, and exactly where imperative code is at its most miserable.

Your own toolchain. The compiler whose type inference you rely on is a logic program you invoke a hundred times a day. “The type of f(x) is whatever f returns, provided x’s type matches what f accepts” — that is a rule, with variables, and inferring your program’s types means deriving the consequences of thousands of such rules until nothing new follows: a fixpoint, with unification doing the matching. When your IDE red-underlines a line and names the mismatch, you are reading the output of derivation, not of execution — and the reason type errors can be trusted (“if it compiles, the types hold everywhere”) is exactly the theorem-not-observation property chapter 6 will make Strata-K’s foundation. The build system completes the pair: make and its descendants compute which targets follow from which changed files — a fixpoint over dependency rules, so literally that make-in-Datalog is a standard classroom exercise. You have trusted logic programming with your builds and your types for your entire career. You just never had to call it that.

The shape of the evidence

Line the fragments up and read what they agree on.

Every fragment lives where three properties coincide: the domain is rule-shaped (policies, vulnerabilities, schedules, dependencies — knowledge, not procedure); wrong answers are expensive (security, money, law, broken builds); and the data is relational and recursive (graphs of calls, flows, ownership, dependency). That is the paradigm’s natural habitat, confirmed independently by security teams, database designers, network engineers, and logisticians who mostly don’t know the others exist. Note what the habitat is not: it is not “artificial intelligence.” The winter buried logic-programming-as-AI; the survivors are logic-programming-as-infrastructure, and none of them advertises the paradigm — the camouflage chapter 2 promised to explain. “Policy language,” “query language,” “code scanning,” “build tool”: the idea sells precisely when nobody says its name. A paradigm at once this useful and this unspeakable is a paradigm with a language problem, not an idea problem.

And the fragments do not add up. Each one solved the slice its niche demanded and stopped: CodeQL has world-class recursive queries and no notion of uncertainty; OPA decides but does not explain its decisions as derivations; WITH RECURSIVE has the fixpoint and syntax nobody defends; DDlog had incrementality and died of ecosystem; the ASP systems own hard choice and give yes/no answers only; none of them touches probability, cost, or learned components, though every one of their domains is full of all three — risk scores on vulnerabilities, confidence on policy inputs, weights on schedules. The engine survived everywhere. The language — one coherent tongue in which rules, recursion, choice, cost, probability, and explanation are citizens of the same semantics — survived nowhere. The fragments are a scattered proof of demand for it.

So the state of the field is this: an idea proven in production a dozen separate times, by a dozen communities, under a dozen names, with no common language to compound the wins. The obvious question — why not just crown one of the existing logic languages and consolidate? — deserves a serious answer, because the candidates are real: Prolog is alive and standardized, ASP has industrial solvers, CP is unmatched in its niche. The serious answer is chapter 4, and it requires a scalpel.