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
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.
Appendix
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.
Appendix
Table 9: Elements of the rule graphs and the flow diagram.
Large language models are highly capable of answering difficult questions by retrieving, recombining, and attending to information in long contexts. For agentic tasks, an additional capability is required: the preservation of an exact state while repeatedly applying rules. We find that this reliability is absent across language models. To demonstrate, we query 126 leading model variants with the task of counting a long string of repeated characters, and we find they all cannot accurately count above a model-dependent, syntax-sensitive counting capacity threshold. Failures are abrupt and persist even with increasing model size, inference time computation, and external tool. Mechanistic probing indicates that models use a finite number of internal states to mimic counting as a rule and fail once these states are exhausted. Furthermore, such states are the basis for performing complex tasks beyond counting. These results indicate that fundamentally new model architectures are required for autonomous agents to achieve truly reliable rule following capabilities.
Tianxiang Dai, Jonathan Fan
Department of Electrical Engineering, Stanford University, Stanford, CA 94305.
When a language model follows an in-context conditional rule such as "if P(x) then A else B," does it assemble a runtime circuit with one module that tests the predicate and another that routes the answer? We probe this with activation patching under a four-donor design whose two swapped-rule donors make the condition and the answer word disagree, so each layer reveals which of the two it carries. Across three open models from two families and six languages sharing one fixed item bank, a mid-stack residual band carries the predicate's truth value: patching it reroutes the answer with predicate-outcome flip near 1.0 and mapping flip near 0.0, meeting a strict pre-specified isolation criterion in 17 of 18 cells, and the same localization holds across five predicate families. The router shows the opposite profile. A learned subspace flips A and B near-perfectly within the trained pair yet transfers to a new pair at approximately 0 in every model, while in Gemma-3-4B (the only model probed cross-lingually) it transfers at approximately 0.98 to the same pair in other languages. Under every probe we ran, the router direction is token-bound and non-transferable (largely answer-readout in Gemma, pair-specific in Qwen) rather than an abstract routing module. Test is modular; under these probes, route is not.
Luxshan Thavarasa, Sivasuthan Sukumar
Independent Researcher, Colombo, Sri Lanka · Department of Computer Science and Engineering, University of Moratuwa, Sri Lanka
Existing multi-model and tool-augmented systems communicate by generating text, serializing every exchange through the output vocabulary. Can two pretrained language models instead coordinate through a continuous, concurrent channel? The Bicameral Model couples two frozen language models through a trainable neural interface on their intermediate hidden states. At every generation step, both models run in lockstep: a primary model drives the task while an auxiliary model operates tools, solves constraints, or executes code, with both conditioning on each other's activations through a translation network and a learned suppression gate (∼1% of combined parameters). The gate learns a selective communication protocol from task loss alone, without a prescribed format. We demonstrate the mechanism across three tool backends. On arithmetic, coupling two 0.5B models with a calculator raises accuracy from 36% to 96%. On logic grid puzzles, coupling two 0.6B models with a Z3 solver achieves 1.7× the unaugmented baseline on ZebraLogic. On mathematical reasoning, coupling with a Python sandbox enables the auxiliary to generate problem-specific code from hidden-state signals alone, without ever seeing the problem text.