Apply to my task
arXiv:2609.09356 ★ 86 Sep 8, 2026

TRACE: Splitting the LLM's Job Into "Extracting Facts" and "Making the Decision" With Explicit Rules

Key result

Recall jumped almost 1.5-fold simply because the LLM was no longer asked to understand the text and make the decision in a single prompt. The TRACE method lets you pinpoint the cause of any classification error: either the model didn't recognize a fact, or it misapplied a rule. The secret is a strict split between "translating text into facts" and "applying rules" as two separate steps. The LLM only extracts canonical terms from a vocabulary, and the final verdict comes from explicit if-then rules that you write yourself.

01

TL;DR

TRACE is a prompt architecture that breaks a decision-making task into two separate steps: first the LLM only extracts facts from the text using a fixed vocabulary of terms, then a separate set of explicit rules (if-then) determines the final verdict. The LLM never makes the final decision itself; it only translates conversational text into structured data.

When one and the same LLM both understands the request and makes the clinical decision in a single prompt, two problems arise. First: if the model gets it wrong, there's no way to tell whether it misunderstood the symptom or misapplied the clinical criterion; those are two different kinds of error fused into one opaque answer. Second: any change to the prompt (adding a new criterion) requires rerunning every test, because the edits might accidentally break something else, and the model "drifts" between old and new behavior.

Splitting the task into "extraction" and "rule application" turns the decision into a transparent chain: if something goes wrong, you immediately see at which step, whether it's a bad translation, a symptom that didn't get extracted, misread context, or a rule that's outdated or missing. Each type of error gets fixed separately, with no risk of breaking the rest of the system.

Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.

02

Method Blueprint

STEP 1 (LLM prompt): Extract canonical terms from the request text
                     using a fixed vocabulary → list of facts/symptoms + context

STEP 2 (rules, not the LLM): Apply explicit if-then rules to the extracted
                          facts → final decision

Step 1 needs an LLM (understanding conversational speech, synonyms, dialects). Step 2 is fixed logic that a human can apply directly or hand to an LLM as a separate simple prompt: "apply these rules to these facts."

03

Example in Practice

Task: A sales team receives inquiries through a chatbot and needs to quickly tell whether this is a hot lead that should go straight to a rep, or an inquiry that can wait in the general queue.

Prompt (Step 1 — extraction):

Here's a message from a customer: "{inquiry_text}"

Extract only the facts that are explicitly mentioned in the text,
using this list of terms (if something similar is mentioned,
map it to the canonical form from the list):

- Budget: specified / not specified / "no budget"
- Decision timeline: "urgent/today/this week" / "within a month" / not specified
- Writer's role: owner/director / employee without decision rights / unclear
- Competitor mentioned: yes/no
- Ready to meet: today-tomorrow / this week / not ready

Don't conclude "hot lead or not." Just list the facts.

Prompt (Step 2 — rules, as a separate message or in the same chat):

Here are the extracted facts: {step 1 result}

Apply the rules:
- If "Role: owner/director" AND "Timeline: urgent" → HOT
- If "Budget: not specified" AND "Role: employee without decision rights" → NOT hot
- If "Ready to meet: today-tomorrow" → HOT, regardless of everything else
- Otherwise → queue for follow-up

Output the final verdict and state which rule fired.

Result: At the first step, the model produces a short list of facts with no interpretation, just recording what's explicitly written in the inquiry. At the second step, you get a verdict that names the specific rule that fired. If the result turns out wrong, you'll know exactly whether the error was in fact extraction (the model missed an important detail) or in the rules themselves (the rule is too narrow or outdated), and you can fix that specific piece without touching the rest.

04

Why It Works

LLMs struggle with tasks that require them to simultaneously understand conversational text and precisely apply a complex, multi-step decision criterion: they blend the two operations and start relying on their general intuition instead of your specific rules. Hence the instability: today the model reacts to one detail, tomorrow it misses the same detail in a similar case.

On the other hand, LLMs are excellent at translating conversational text into structured terms: recognizing synonyms, jargon, mixed languages, typos. That's exactly where the model's strength fully shines.

The method takes that strength (translating into terms) and separates it from the weakness (applying complex logic). You write the logic yourself as explicit rules: they don't "drift" from run to run, and you can read, edit and fix them surgically.

Control levers: - Vocabulary of terms — the more detailed and specific the list of synonyms, the more accurate the extraction. Expand it as you run into new phrasings that mean the same thing. - Rules — you can add or change them one at a time, without rewriting the whole extraction prompt. That's the method's main payoff: edits don't require re-validating the entire system. - Two separate requests instead of one — if you want to see the intermediate result (what exactly got extracted) for debugging, keep the steps separate. If the task is simple and you trust the model, you can ask it to do both steps in one prompt, but with an explicit requirement to list the facts first and then apply the rules.

05

Prompt Template

STEP 1 — Fact extraction:
Here's the text: "{text}"

Extract facts from the text using this vocabulary of terms (map to the canonical form,
even if the text uses a different phrasing/synonym/jargon):
{list_of_terms_and_their_synonyms}

Don't draw a final conclusion. Only list which terms from the list appear in the text,
and what context is given (if applicable: {additional_context_e_g_age_timeline_role}).

---

STEP 2 — Rule application:
Here are the extracted facts: {step_1_result}

Apply these rules in order and state which one fired first:
{list_of_if_then_rules}

Output the final verdict: {category_1} or {category_2}.

🚀 Quick start — paste into the chat:

Here's the TRACE template — a method that separates "fact extraction" from "rule application"
for precise decisions based on clear criteria. Adapt it to my task: {your task}.
Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask which terms/synonyms matter for your task and exactly which rules you want to apply, because the method won't work without them: the vocabulary and the rules are your expertise, and nobody can make them up for you.

06

Limitations

⚠️ You need criteria that can be formalized: the method only works where the decision can be spelled out as explicit if-then rules. For highly subjective tasks (rating the creativity of a text, the tone of an email), decomposition won't help, because there's no clear logic to pull out of the model.

⚠️ Extra work up front: you have to build the vocabulary and the rule list by hand once. Without that prep work, the method won't get off the ground; it's not a "one-line prompt."

⚠️ Costlier and a bit slower: two steps instead of one increase request cost and response time. If the task is simple and errors aren't critical, the overhead may not pay off.

⚠️ Extracting context doesn't always improve accuracy: in the study, separately extracting context (e.g., age, gestational term) didn't improve the result by itself, but it remained necessary to be able to verify whether a context-dependent rule fired correctly.

07

Resources

Auditable Emergency Triage for Maternal and Newborn Care in India. Shobhit Jagga, Aman Dalmia, Niharika Priyadarshini et al. (Noora Health, The Agency Fund). AAAI 2027.

Research digest

Key result

Recall jumped almost 1.5-fold simply because the LLM was no longer asked to understand the text and make the decision in a single prompt. The TRACE method lets you pinpoint the cause of any classification error: either the model didn't recognize a fact, or it misapplied a rule. The secret is a strict split between "translating text into facts" and "applying rules" as two separate steps. The LLM only extracts canonical terms from a vocabulary, and the final verdict comes from explicit if-then rules that you write yourself.

Principle

The model is like a court interpreter: it translates the witness's words but doesn't pass the sentence. Translating and deciding are two different jobs, and mixing them in one prompt is a mistake. Step 1: the LLM turns "no contractions for the second day" into a canonical term from your vocabulary. Step 2: separate if-then rules determine the verdict, and the model plays no part here.

Why it works

When an LLM is simultaneously translating jargon and juggling a complex multi-step criterion, it mixes up the two operations. It starts relying on its general intuition instead of your specific rules, hence the run-to-run instability. Splitting the tasks removes that confusion — recall grew almost 1.5-fold. Plus a bonus: any error is now visible by step, whether it's a bad translation, a missed symptom or an outdated rule. It gets fixed surgically, with no risk of breaking the rest of the system.

When to apply

Classification against clear criteria → lead qualification, ticket moderation, resume scoring, medical triage, especially when you need to explain why a particular decision was made. NOT suited to subjective tasks such as rating the tone of an email or the creativity of a text, where there's no clear logic to turn into rules.

Mini recipe

1. Build a vocabulary of terms: write down all the synonyms and jargon people use to describe the facts you need — "no budget," "nothing set aside," "too expensive" = one canonical term 2. Write if-then rules: explicitly, in order, specifying which rule wins first in a conflict 3. Prompt 1 (extraction): give the model the text + vocabulary and forbid it from drawing conclusions; it only lists the facts 4. Prompt 2 (rules): give it the step 1 result + the rule list, and ask it to output the verdict and name the rule that fired 5. Test on real cases: if there's an error, you immediately see whether to fix the vocabulary or the rule, without touching anything else

Examples

[BAD]: `Assess whether this is a hot lead: "The customer says there's no budget yet, but wants to meet this week"` — the model guesses with everything jumbled together, confuses the lack of budget with readiness to meet, and tomorrow on similar text will give a different answer [GOOD]: Step 1 — `Extract facts using the vocabulary: Budget: specified/not specified, Ready to meet: today-tomorrow/this week/not ready. Don't draw a conclusion.` Then step 2 — `Here are the facts: {result}. Rule: if Ready to meet=today-tomorrow → HOT regardless of everything else. State the rule that fired.` Result: a HOT verdict with the exact reason — you can see that the meeting rule fired, not the budget one

In plain words

Models screw up badly when you try to make them do two things at once: parse muddled human speech and make a critical decision based on it. The model quickly starts judging by gut feel, delivering one verdict today and a completely different one tomorrow on the exact same inputs. The TRACE architecture solves this simply: it permanently strips the LLM of the right to deliver a verdict and leaves it only the role of translator from chaos into facts.

It's like hiring a court stenographer and suddenly making them hand down the sentence. Technically they wrote everything down, but the logic of the law is foreign to them, so they might easily acquit a guilty party just because of some heart-wrenching phrasing. A sound decision has to come from a hard rule, and the model's job is simply to fill in the record without freelancing.

The method works in two isolated steps. First the model performs structured extraction: it pulls parameters out of the text strictly according to a fixed vocabulary of terms. Then deterministic if-then logic takes over, a plain, rock-solid algorithm with no model hallucinations, which reaches the decision by formula. The key point: the LLM never decides on its own; it just collects dry data for the code.

The system was tested on emergency triage of pregnant women and new mothers in India, where the cost of an error is a human life. But the principle is universal: the setup fits lead scoring in a CRM, chat moderation or tech support one-to-one. Anywhere a person writes a rambling wall of text and the business needs to instantly cut the noise and spot the hot inquiry, this approach saves you from chaos.

Bottom line: stop forcing a language model to act as an infallible oracle. Separate text parsing from the final logic. Let the model pull out raw facts, and hand decision-making to good old code, or you'll keep wondering where that important client vanished to and why your conversion rate dropped.

AI lab assistant

Apply this study to your task

Describe what you're working on. AI takes the method and the measured results from this paper and adapts them to your case, or writes a ready prompt built on them.

Based on TRACE: Splitting the LLM's Job Into "Extracting Facts" and "Making the Decision" With Explicit Rules arXiv:2609.09356

Sign in to apply this study New accounts get 50 free credits.