Tln — The Modern Expert-System Language

Name: Tln
Author: OpenTalon

Tln modernizes Prolog expert systems into a deterministic, testable, data-native rule platform. Domain experts write rules that read like English; a native Go engine plans and evaluates them over your live data — with built-in ML primitives, first-class MCP tool orchestration, and a .tln.test framework.

Prolog — standardized as ISO/IEC 13211-1 in 1995 — pioneered expert systems. Tln keeps the idea (facts, rules, inference) and modernizes everything around it: no assert/retract spaghetti, no hand-rolled query-and-format plumbing, no “trust me, it works.” Same logic, modern platform.

Why Tln?

The world moves faster than it did in 1995. We have new languages, new frameworks, and — above all — LLMs. That shift is exactly what calls for a Prolog successor built for today’s world: one with native MCP support, a plugin system, and more.

It also brings modern language ergonomics built into the core — including metaprogramming: compile-time macros in the spirit of Elixir (defmacro / quote / unquote) that generate rules before validation, so boilerplate disappears while the runtime stays pure and deterministic.

And Tln isn’t just a language — it’s a whole ecosystem: the language itself, plugins, databases, and even agentic orchestration. Connecting expert systems to agents, MCP, and business rules is the goal of Tln.

Same rule, modernized

A fleet-maintenance check: flag active vehicles overdue for service. Left, standard ISO Prolog; right, the same decision in Tln.

ISO Prolog (1995)

% Facts arrive from external systems as generic triples:
%   record(Entity, Id, Type, Category, Status, Date).
%   attr(Entity, Id, Name, Value).

active_vehicle(E, Id) :-
    record(E, Id, item, 'Vehicles', active, _).

service_overdue(E, Id) :-
    active_vehicle(E, Id),
    attr(E, Id, km, Km),
    attr(E, Id, last_service_km, Last),
    Km > Last + 20000.

% "Flag matching items with a label" is on you: query, collect, format.
report_overdue(E) :-
    forall(service_overdue(E, Id),
           ( attr(E, Id, name, Name),
             attr(E, Id, km, Km),
             format("~w: ~w km since last service~n", [Name, Km]) )).

Tln

// Facts arrive from external systems as generic triples:
//   record(Entity, Id, Type, Category, Status, Date)
//   attr(Entity, Id, Name, Value)

define "active_vehicle" {
  type == "item"
  and status == "active"
  and category == "Vehicles"
}

detect "Service overdue" {
  for records where is "active_vehicle"
    and attr "km" > attr "last_service_km" + 20000
  flag matching items
  label "{item.name}: {attr.km} km since last service"
}

The Tln version declares the outcome — flag, label — instead of scripting the query and the print loop. It compiles to a deterministic query plan, is unit-testable with .tln.test, and the same detect block can escalate straight into an MCP workflow.

Beyond Prolog

Modern capabilities beyond classic Prolog:

MCP tool orchestration — workflow, reactive on change → workflow, scheduled collect, and stale-fact enrich, all calling real tools.
Built-in ML — predict, forecast, classify, cluster, find similar — 11 explainable primitives, no external pipeline.
A real test framework — .tln.test with given / when / expect, so rules are verified, not hoped.
Metaprogramming — compile-time macros (defmacro / quote / unquote, Elixir-style) that generate rules before validation, keeping the runtime pure.

And in production it’s the decision core of OpenTalon, the enterprise AI-orchestration ecosystem: the LLM handles intent, Tln handles knowledge and inference.

MCP tools & workflows

Prolog is a pure inference engine. It answers queries; it does not do things. There is no standard way to call an external tool, and nothing reactive — a fact changing can’t fire an action, because the language has no notion of “an action” or of “changing.” In practice you bolt on non-standard extensions and hand-roll all the orchestration yourself. Tln makes tools and reactivity first-class, through the Model Context Protocol (MCP). This is the capability that turns a ruleset into a running agent — and it’s what powers OpenTalon in production. ...

Built-in ML

Expert systems hit a wall the moment a decision needs a learned judgement — “is this reading anomalous?”, “what’s this incident’s likely cause?”, “when will we run out?”. In Prolog you leave the language: export the data, run a Python/R pipeline, glue the answer back. Tln builds the common cases in as blocks, each returning an explanation alongside its value — so an ML result is as auditable as any rule. ...

Testing

A ruleset that decides claims, or blocks a deployment, or reorders stock, needs to be tested — not eyeballed. ISO Prolog has no standard test framework (SWI ships the non-standard plunit); Tln has one built in, and it needs no database. given / when / expect A .tln.test file seeds facts in a given block, runs a named block with when, and asserts on the result: test "greets the world" { given { record 1 type "greeting" attr 1 "name" "World" } when detect "Hello, World" expect { flagged 1 label contains "Hello, World!" count == 1 } } The given block is the fact schema you’d otherwise load from an external system — record and attr triples — so tests are hermetic and fast (the runner materializes them in memory; no FactStore required). ...

Metaprogramming

Tln does metaprogramming the Elixir way: macros are code that writes code, and they run at compile time. A defmacro expands into ordinary blocks before validation and planning — so the validator, planner, and runtime never see a macro, and the engine stays exactly as deterministic and terminating as always. The one place unbounded computation is allowed is expansion itself, bounded by a step budget (a compile error, never a runtime hang). That’s also why macros live in core, not a plugin: only core owns the grammar and the compile phases. ...

Tln — The Modern Expert-System Language#

Why Tln?#

Same rule, modernized#

Beyond Prolog#

Tln — The Modern Expert-System Language

Why Tln?

Same rule, modernized

Beyond Prolog