cs.AIOct 29, 2026
SaveHybrid AI Patterns: Thirteen Ways to Couple Language Models with Rules, and How to Choose Among Them
Organizations: Institute of Computer Science, University of St. Gallen (HSG)
Abstract
Language models handle text well, and rule engines give conclusions with proofs. Systems that combine the two are usually described by example, and the same coupling turns up under different names in agent frameworks, guardrail toolkits and neuro-symbolic research. This document defines thirteen patterns for coupling a language model with an executable rule language, in the catalogue form introduced for object-oriented design: intent, motivation, applicability, participants, collaborations, consequences, implementation, known uses and related patterns. Four patterns concern what crosses the boundary between model and rules, five who controls whom, three how the model takes part in the reasoning, and one how knowledge is kept over time. Five invariants hold for every combination, and five failure patterns name the couplings that break them. We relate the catalogue to published pattern catalogues and taxonomies of hybrid and neuro-symbolic systems and show where they overlap with it. A decision guide leads from a problem to a pattern. It rests on our measurements, including the cases in which a model alone did as well as the hybrid or better, and it reports what each design cost.
Figures & tables
| Tool | Provided by | What the host does |
|---|---|---|
| _llm | framex.tools | one model call; see below |
| _query , _evidence_needs | framex.tools | a query on the rules themselves; the evidence that would settle a goal |
| _turn , _judge , _repairTurn | framex.dialogue | the dialogue model phrases a question; a judge decides a criterion; a repeated turn after a broken reply |
| _ask | framex.dialogue | one question to a person, as written, without a model |
| _checkCandidate | framex.candidates , by adapter | checks a drafted rule against cases, before and after |
| _forgetAnswers | framex.tools | removes stored model answers that contain a forgotten text |
Table 1: Tools used in this document.
| Tool | Request fields | Receipt |
|---|---|---|
| _llm | prompt (or with P ) and any named fields; groundIn , mustSay , contextKey , tool#maxContext for the host | the reply’s fields as result("k") and row(N, "k") ; with groundIn quoteFound and valueQuoted per row; with mustSay saysDecision ; with contextKey tool#sent("id") |
| _query | query | result("status") ( true , false , unknown or bindings ) and the whole answer as JSON in result("text") |
| _checkCandidate | candidate | status ( checked , rejected , error ), feedback , and after evaluation regressions , failedAfter , newlyFailing , newlyPassing , newViolations , changesConclusions , all as result("k") |
| _turn | question , attempt | answer , utterance ; after a broken reply formatError and received |
| _judge | criterion , question , answer | verdict ( yes , no , unclear ), reason , label ; after a broken reply formatError and received |
| _ask | question | question , answer |
Table 2: What each tool reads from a request and writes into its receipt. Every receipt also has tool#status and tool#completed ; a failed call has error instead of results.
Figure 1: The four elementary moves. Every arrow that enters the rules is a receipt; only the accept move writes facts.
| Pattern | Moves | Request triggered by | Accept decides |
|---|---|---|---|
| 1 Model as Sensor | request, receipt, accept | a pending input | whether a reading becomes a fact |
| 2 Model as Author | request, receipt, accept, ask | a policy text or a failing case | whether a draft is offered; a person adopts it |
| 3 Model as Translator | request, receipt, accept, request, receipt | a person’s question | whether the request may run; whether the reply states the rules’ decision |
| 4 Model Proposes, Rules Dispose | request, receipt, accept | the next step of a task | admit, refuse with a reason, or narrow |
| 5 Rules Steer the Model | request, receipt, ask | the derived step | which step follows; the judge’s reading as in 1 |
| 6 Critique and Repair | accept, then request again, bounded | a refused reply | the kind of failure and when to stop |
Table 3: The patterns as compositions of the four moves.
| # | Pattern | The model | The rules |
|---|---|---|---|
| What crosses the boundary | |||
| 1 | Model as Sensor | turns text into proposed facts | accept or reject each fact |
| 2 | Model as Author | drafts rules, tables, flows, tests | check them; a person adopts |
| 3 | Model as Translator | turns questions into checked requests, proofs into prose | answer and prove |
| 12 | Model Selects, Rules Write | chooses passage identifiers, phrases around values | show passages and values word for word |
| Who controls whom | |||
Table 4: The thirteen patterns in four groups.
Figure 2: Rule graph of p01-sensor.fx , generated from the program. A circle is one rule; “l. 23” means that the rule starts in line 23 of the listing. Legend in Table 9 .
Figure 3: Rule graph of p02-author.fx , generated from the program. A circle is one rule; “l. 23” means that the rule starts in line 23 of the listing. Legend in Table 9 .
Figure 4: Rule graph of p03-translator.fx , generated from the program. A circle is one rule; “l. 23” means that the rule starts in line 23 of the listing. Legend in Table 9 .
Figure 5: Rule graph of p12-select.fx , generated from the program. A circle is one rule; “l. 23” means that the rule starts in line 23 of the listing. Legend in Table 9 .
Figure 6: Rule graph of p04-dispose.fx , generated from the program. A circle is one rule; “l. 23” means that the rule starts in line 23 of the listing. Legend in Table 9 .
Figure 7: Flow diagram of p05-steer.fx : the steps of the flow and the transitions the flow library derives from them. Legend in Table 9 .
Figure 8: Rule graph of p07-competence.fx , generated from the program. A circle is one rule; “l. 23” means that the rule starts in line 23 of the listing. Legend in Table 9 .
Figure 9: Rule graph of p13-failsafe.fx , generated from the program. A circle is one rule; “l. 23” means that the rule starts in line 23 of the listing. Legend in Table 9 .
Figure 10: Rule graph of p08-hypothesis.fx , generated from the program. A circle is one rule; “l. 23” means that the rule starts in line 23 of the listing. Legend in Table 9 .
Figure 11: Rule graph of p09-critic.fx , generated from the program. A circle is one rule; “l. 23” means that the rule starts in line 23 of the listing. Legend in Table 9 .
Figure 12: Rule graph of p10-teach.fx , generated from the program. A circle is one rule; “l. 23” means that the rule starts in line 23 of the listing. Legend in Table 9 .
Figure 13: Rule graph of p11-memory.fx , generated from the program. A circle is one rule; “l. 23” means that the rule starts in line 23 of the listing. Legend in Table 9 .
| Application | Patterns | How |
|---|---|---|
| Assignment review | 1, 3, 6 | quote-checked extraction; chat model calls the rules; completeness check |
| Interview, suitability, triage | 5, 1, 6, 7 | flow steers; judge as sensor; format repair; unclear to a person |
| Campervan search | 1, 5 | one classification per listing, requested by rule |
| Allocation | 4, 5, 1 | bounded recommendation; point-in-time evidence; grader verdicts |
| Agent framework | 4, 5, 6, 1 | admitted actions; derived phase and context; stalled repair stops; memory claims |
| Personal memory (DreamRAG lite) | 11 (storing) | admission, supersession, conflict and withdrawal of memories as rules; this application has no recall by rules, the program of pattern 11 has |
Table 5: Patterns in the applications from which the catalogue was drawn.
| Pattern | Kautz type | Boxology, modular patterns | Language-model and agent literature | Status |
|---|---|---|---|---|
| 1 Model as Sensor | Neuro | Symbolic | learning with symbolic output (4.1) | KG construction ( Pan et al., 2024 ) | known |
| 2 Model as Author | – | engineered model (1c) | model acquisition ( Kambhampati et al., 2024 ) | known in part |
| 3 Model as Translator | Symbolic[Neuro] | LLM-augmented KG ( de Boer et al., 2025 ) | Logic-LM, LINC, SatLM | known |
| 4 Model Proposes, Rules Dispose | Symbolic[Neuro] | – | guardrails, rule safeguards, hard critics | known |
| 5 Rules Steer the Model | Symbolic[Neuro] | meta-reasoning for control (4.8), training only | routing, dialogue rails | new as stated |
| 6 Critique and Repair | – | – | solver feedback, back-prompting | known |
Table 6: The thirteen patterns in published classifications. “–” means no counterpart.
Figure 14: Decision guide. Answer every question; the patterns of all answers that lead right combine. Critique and Repair (6) accompanies every pattern whose reply is checked.
| Problem | Patterns | Deciding force | Caution from the measurements |
|---|---|---|---|
| Facts are in documents or speech | 1, 6 | a reading can be checked (quote, closed list) | fit the acceptance rule to the reader: a strict quote rule hurt a small model |
| Answer aggregates over many objects | 1, then rules | lists and counts are exact in rules | a model alone failed exhaustive lists at 100 agreements; extraction cost is paid once |
| A policy text must become rules | 2, 6 | a complete check exists (syntax, cell language, cases) | messages that name the fix doubled first-request repairs |
| A regulation changed | 2, 9 | regression cases decide; a person adopts | a draft outside the cell language is refused with its reason |
| People ask in their own words | 3 | the answer needs a proof | on easy cases a model alone was as accurate and cheaper |
| An agent acts | 4, 5, 6 | some effects must never happen | completion only from recorded evidence |
Table 7: Problems, patterns, deciding forces and cautions.
Appendix figures & tables2 assets
Supplementary material from the paper’s appendix.
Appendix
| Symbol | Name | Meaning in this catalogue |
|---|---|---|
| data: text | instance: data | Model-free input or output, here text: a document, a question, a model’s reply before it is read as facts. |
| symbol | instance: symbol | Model-based structure: facts, requests, proposals, verdicts. A note below the box gives its status, such as proposed or accepted . |
| model: gen | model: generative (the LLM) | A language model that infers new data from data ( de Boer et al., 2025 ) ; the note names its role (dialogue model, judge, critic). |
| model: sem | model: semantic (the FrameX rule base) | A rule base: the FrameX rules, a flow, a slot policy, a checker with its cases. |
| infer | process: infer | Applying a model to an instance. With a generative model above it, one model call. |
| infer: deduce | process: infer, deduce | Applying the rules: deriving, accepting, refusing, deciding. |
Table 8: Elements of the boxology diagrams.
| Symbol | Meaning |
|---|---|
| Document | Facts of a class or object, with their slots, and the prompt objects. |
| read → _llm | An external request and its tool. |
| receipt | The receipt the host writes, with the fields the rules read: result("k") , row("k") , tool#status , error . |
| accepted(I) | Slots or classes that the rules derive. A box lists the slots of one rule head. |
| l. 23 | One rule. The label is the line of the program listing where the rule starts: “l. 23” is the rule in line 23. |
| l. 14 | A rule that issues an external request, labelled by its line in the same way. |
Table 9: Elements of the rule graphs and the flow diagram.