IA 360
Language Models

Rule-Based Language Systems: Still Alive Where You Must Answer «Why»

A 1966 report gutted funding for rule-based machine translation, and the story goes that it died. It did not: a free platform runs 51 stable language pairs that way today. Knowing when a rule beats a model — and how to tell which one you are facing — is a skill no product release makes obsolete.

Admin IA360 4 min read AI-generated Leer en español
Rule-Based Language Systems: Still Alive Where You Must Answer «Why»

When your word processor underlines a sentence for agreement, when a form rejects a malformed account number, or when you translate Catalan into Spanish and it comes out right first time, there is almost never a neural model behind it. There are rules: explicit instructions someone wrote by hand, of the form «if this appears in this context, do that».

The dominant story says this approach died when machine learning arrived. It is not true, and the interesting part is why it did not — because out of that comes a criterion for choosing tools in any situation, a year from now and ten years from now.

What a rule is, exactly

A rule is a condition and an action, written by a person in a format another person can read. That has three consequences worth being clear about from the start.

First: it can be audited. For any output, someone can point to the specific rule that produced it. Second: it is deterministic. The same case always yields the same result, today and next year. And third, its Achilles heel: it only covers what someone anticipated. Every unforeseen case needs a new rule, written by hand.

Those three properties explain both its historical defeat and its present survival.

The defeat, and the document that signed it

The turning point has a date and a document. In 1966 the ALPAC committee published, for the US national academies, the report «Language and Machines: Computers in Translation and Linguistics», an assessment of machine translation after more than a decade of public investment. Its reception chilled funding in the field for years.

The report can be read in full and free on the academies' site, including its third chapter, «The Crucial Problems of Translation». A practical warning for anyone going to consult it: it is digitized as page images, with no text layer. You can read it; you cannot search inside it. That is why you will find no direct quotation from the report in this article: I could not extract one from a copy I can hand to you, and I would rather say so than quote it second-hand.

The underlying problem the field had hit was structural, not a matter of effort. Real language has a variety that will not be enumerated: every exception demands a new rule, and new rules interfere with old ones. A system that grows by patching becomes impossible to maintain. When statistical methods arrived, able to learn that variety from data rather than receive it in writing, the outcome for the general case was settled.

The survival, and where it happens

For the general case. That is the key, because some cases are not the general one.

Apertium is a free, open-source platform for building rule-based machine translation systems. It is not a relic: its official wiki documents 51 language pairs with released versions considered stable. And its origin explains why it works: it began aimed at related language pairs, then expanded to more divergent ones.

That detail is the heart of the matter. Between two close languages — Spanish and Catalan, Spanish and Portuguese — the transformations are largely enumerable: regular lexical correspondences, systematic morphological adjustments, a handful of reorderings. Exactly what a rule does well. And such combinations typically lack the enormous parallel corpora a statistical method needs to shine.

The result: on that terrain, a rule-based system is not the poor option. It is the right one. Less data and more known structure favour rules; more data and more unpredictable variety favour models. That axis does not depend on technological fashion.

The advantage that does not expire: being able to answer «why»

There is a second territory where rules win for reasons that have nothing to do with accuracy.

Anywhere a decision must be justified to a third party — a regulator, a court, a patient, a customer lodging a complaint — the relevant question is not «which is more accurate?» but «can it explain why it did that?». A rule-based system answers by pointing at a specific line written by an identifiable person. A statistical model answers, at best, with a probability and an approximation of which parts of the input weighed most.

That is why rules are still being written by hand in 2026. The free tool LanguageTool, which describes itself as «a style and grammar checker», maintains dedicated documentation for rule development: people writing, reviewing and arguing about new rules, today. It is not nostalgia; it is that to say why a sentence is wrong, you need to be able to point at the norm it breaks.

Hybrids are the norm, not the exception

The false dichotomy is worth dismantling. Practically every production language system combines both: regular expressions and rules to normalize, segment and clean the incoming text; statistical models for the decisions that will not be enumerated; and rules again at the end to guarantee formats, filter unacceptable outputs or enforce mandatory terminology.

Anyone wanting to check this has the field's reference textbook in the open: «Speech and Language Processing», by Dan Jurafsky and James H. Martin, whose third edition is published as a freely readable draft — updated 6 January 2026 — with the authors' explicit permission to use and print it. It is the same book the industry's professionals train on, and it is one click away.

The capability: three questions for any language system

1. Can someone show me the rule? If yes, you are facing an auditable, predictable system that will fail on cases nobody anticipated. If no, you have a model: it will cover more ground and fail in ways nobody predicted.

2. How does it fail? This is the most useful of the three. A rule-based system fails silently and recognizably: it does not cover a case, and you notice. A model fails confidently and plausibly: it produces a well-formed, wrong answer. The second kind of error is far harder to catch for anyone who does not already know the subject.

3. What do I need: coverage or justification? If the job is to span the variety of the world, the model wins. If the job is to defend every decision to someone disputing it, the rule wins. Many arguments about which technology to use resolve themselves once this is answered first.

The deep end, undiluted

  • ALPAC report (1966), «Language and Machines», free to read at the US national academies. Scanned as images: readable, not searchable.
  • Apertium, the official wiki, with the list of 51 stable language pairs and the documentation for building a new one.
  • Jurafsky and Martin, «Speech and Language Processing», third edition as an open draft.
  • LanguageTool, rule development documentation, to see how one is written in practice.

One classic is missing, and its absence is consistent with everything above: the paper in which Joseph Weizenbaum introduced ELIZA in Communications of the ACM in January 1966 is registered under the identifier 10.1145/365153.365168, but I could not reach its text to verify any quotation, so there is none here. ELIZA performed pattern matching on the user's sentence and handed it back rephrased; the detail of how is better read in the original than in a second-hand summary — when it can be opened.

The capability you leave with: identify whether a language system runs on rules or on a model by the way it fails, and choose according to whether you need coverage or justification. That is an engineering criterion, not a fashion, which is why it will still hold when all the names have changed.

This article was produced with artificial intelligence under human editorial oversight.

Share this article

This website uses cookies to improve the browsing experience. Cookie policy.

↑↓ navigate ↵ open esc close