Repository navigation
Concise Context, Better Prompts. Making Information Explicit with FSTGuardrails
The goal is not the fewest tokens. It is a concise, explicit context block that gives the model the relevant facts without making it infer missing information or extract those facts from the question.
The design recommendation of this page is to separate the question from a compact, task-relevant context block. Compared with no context, this makes relevant facts available. Compared with inline prose, it makes those facts easier for the application to validate, maintain, and audit. Better model answers are a goal to evaluate, not a result established by the supplied prompt files.
This page extends the Tag First, Prompt Less and Observe First, Act Deliberately patterns with a concrete comparison of three supplied medical-information prompts:
- A question without patient-specific context.
- The same question with a separate patient-context section.
- A question with selected patient facts embedded directly in its wording.
It also adds a fourth, improved prompt file: prompts/medical_question_concise_context.txt, which illustrates compact context assembled from configured FST dictionary outputs while retaining the supplied facts from the fuller template. This is an illustrative rendering, not output captured from a live FSTGuardrails run or a claim about its native API response schema.
Scope: This is a prompt-engineering example, not medical guidance or a clinical evaluation. No model was called for this analysis, and no model responses were supplied.
The three uploaded text files and the new concise-context example share a medical-information role, safety instructions, and a seven-section response format. Their question/context portions differ.
The complete text of each file was tokenized using:
-
Tokenizer package:
gpt-tokenizer, version4.1.0 -
Encoding:
cl100k_base -
Counting method:
encode(fullPromptText).length - Text handling: UTF-8, with CRLF line endings normalized to LF; no trimming or rewriting
- Cross-check: Counting the original text without newline normalization produced the same totals for these files
These are prompt-text token counts under one specified encoding, not provider-reported usage or billing figures. They exclude any additional system/developer messages, chat-message framing, tool schemas, conversation history, and provider-side processing that might accompany a real request. Other tokenizers can produce different counts.
| Prompt variant | Full prompt-text tokens | Change versus no patient context |
|---|---|---|
| No patient-specific context | 352 | Baseline |
| Separate patient-context section | 469 | +117 tokens / +33.2% |
| Patient context embedded in the question | 366 | +14 tokens / +4.0% |
| Concise FST-derived context illustrative example | 435 | +83 tokens / +23.6% |
The inline-context file contains 103 fewer tokens than the separate-context file: a 22.0% reduction in prompt-text tokens relative to that file.
This is not a placement-only experiment. The structured version supplies more facts. The measured difference reflects both presentation and information content.
The inline version's lower count is therefore not the preferred outcome by itself. The fourth example retains the supplied facts from the structured version, removes template drafting instructions, and compresses the presentation. It also explicitly marks the information as patient-reported and symptom progression as unspecified.
The FST-derived example uses 435 tokens: 34 fewer than the full template, a 7.2% reduction. It is longer than the 366-token inline example because it preserves more information and adds provenance and missing-information qualifiers. Its improvement is an explicit, compact representation of the fuller context not a demonstrated improvement in model answers or measured performance from an actual tagger execution.
The question is:
How can I treat flu like symptoms
Full prompt: 352 tokens.
“No context” here means no patient-specific context. The file still includes a role, extensive instructions, medical safety constraints, and a required response format.
- A broad question about flu-like symptoms.
- Instructions to identify uncertainty and missing information.
- A requirement not to invent patient details.
- Instructions to include warning signs and professional follow-up where appropriate.
Age, relevant history, specific symptoms, symptom duration, medications, allergies, and other potentially relevant information are not supplied.
The model may need to ask follow-up questions or provide a more general answer. That is an expected possibility, not an observed result: no completion is included in the source material.
A shorter initial prompt does not necessarily mean a cheaper completed workflow. Follow-up turns could add tokens, but this example does not measure them.
The same question follows a labeled section containing:
| Field | Supplied value |
|---|---|
| Age | 50 |
| Sex | Male |
| Height / weight | 5'8", 165 lb |
| Relevant medical history | None reported |
| Current symptoms | Sore throat, aches and pains |
| Symptom onset | Two days ago |
| Current medications and dosages | None reported |
| Known allergies | None reported |
| Recent tests | None reported |
| Relevant family history | None reported |
| Other relevant information | None reported |
The section also retains the template instruction, “Add relevant patient information in this section before asking the medical question.”
Full prompt: 469 tokens.
The prompt supplies more explicit facts and separates them from the question. This can make field-level validation, provenance tracking, and missing-field checks easier for the application.
The extra tokens represent both useful information and presentation overhead: field labels, repeated “none” entries, and template wording.
Do not treat reported “none” as independently verified absence. Preserve whether a value was user-reported, unknown, not asked, or confirmed by a trusted source.
More supplied context may support a more specific answer, but these files do not establish answer quality, clinical accuracy, or whether every supplied fact is relevant.
The question is:
How can I treat flu like symptoms, I am a 50 year old male with no medical history.
Full prompt: 366 tokens.
This version adds age, sex, and reported history directly to the question. It retains the same general instructions and response format as the other variants.
- The original question.
- Age and sex.
- A statement that the person reports no medical history.
- Specific symptoms and their duration.
- Height and weight.
- Medication and allergy information.
- Test and family-history fields.
It is more compact, but it is not information-equivalent to the structured version. A model cannot safely assume that the omitted fields are negative just because they are absent.
The three examples illustrate a tradeoff, not a contest for the smallest token count.
| Approach | Main limitation | What concise, separate context addresses |
|---|---|---|
| No patient-specific context | Important facts are unavailable | Supplies relevant facts and identifies what remains unknown |
| Context mixed into the question | Facts and the request are interleaved; the example omits useful fields | Gives the application explicit fields to validate and reuse without relying only on prose extraction |
| Full context template | Repeated labels, unused fields, and drafting instructions add overhead | Keeps the relevant information while removing unnecessary scaffolding |
The added concise prompt demonstrates this design without dropping the supplied facts. Clinical relevance still requires appropriate review; facts should not be removed merely to achieve a smaller count.
Inline context can work well. Separate context is not inherently more trustworthy, and structure alone does not improve medical accuracy. The advantage being proposed is controlled context assembly: the application explicitly selects, checks, and records the facts that accompany the question.
For an agentic workflow, that context can also be carried forward as versioned metadata rather than repeatedly inferred from each agent's rewritten prose.
Prefer concise, explicit context as an application design pattern not because it must have the lowest input count, but because it supports completeness, validation, and traceability.
- The structured file has the highest prompt-text count: 469 tokens.
- The inline file adds 14 tokens over the no-patient-context file.
- The inline file uses 22.0% fewer prompt-text tokens than the structured file.
- The three versions provide different amounts of patient information.
- The illustrative FST-derived context file retains the fuller template's supplied facts in 435 tokens, including explicit provenance and an unknown-progression marker.
- Formatting a context section does not make its text exempt from tokenization.
- That inline context is always more efficient than structured context.
- That the shortest prompt produces the best or safest answer.
- That adding context reduces output tokens or total workflow tokens.
- That FSTGuardrails produced the examples or achieved these savings.
- Actual API cost, latency, energy use, or carbon reductions.
- Model accuracy, diagnostic quality, or reduced hallucination.
There are no completions, model identifiers, generation settings, or API usage reports in the supplied files. Output tokens and total request usage remain unmeasured.
In a real experiment, collect provider-reported input/output usage and any separately reported reasoning or cached-token categories. Interpret them using that provider's definitions rather than adding potentially overlapping categories.
FSTGuardrails can supply a deterministic recognition layer before prompt construction:
user input / approved records
│
▼
FSTGuardrails: recognize configured terms and phrases
│
▼
application: resolve values, negation, provenance, and missing fields
│
▼
compact, task-relevant context + question + safety instructions
│
▼
LLM → response / downstream prompt
│
▼
FSTGuardrails: tag recognized output signals
│
▼
application review, audit, and separately configured enforcement
The separation matters:
- The tagger recognizes dictionary matches. A phrase match is not a clinical conclusion or proof of intent.
- The application interprets those matches. Numeric extraction, negation, temporal meaning, and conflicting facts require appropriate parsing and validation.
- The context assembler selects and represents facts. It must not silently drop safety-relevant information to save tokens.
- The policy layer decides what happens next. Tagging by itself does not guarantee safe or authorized output.
For example, recognizing “medical history” does not resolve the difference between “no medical history,” “history unknown,” and “history of heart disease.” That distinction must survive context assembly.
The complete, paste-ready example is saved as prompts/medical_question_concise_context.txt. Its context block illustrates canonical dictionary outputs assembled into prompt-ready fields:
FST-Derived Context (illustrative)
source=patient_report; verified=false
age=50; sex=male; height=5ft8in; weight_lb=165
symptoms=sore_throat,body_aches; onset_days=2
reported_none=medical_history,medications,allergies,recent_tests,family_history,other_info
unknown=symptom_progression
This is not a human-authored narrative intended to stand in for recognition. It is the target context representation that an application could assemble from configured tag matches and validated field values. The exact field names are an example application schema, not built-in FSTGuardrails fields.
For a dictionary-driven implementation, configure field-specific dictionaries or retain the source-field identity alongside each match:
| Source field | Matched phrase | Example tag type
|
Configured canonical output
|
|---|---|---|---|
| Current symptoms | sore throat |
symptom |
sore_throat |
| Current symptoms | ache and pains |
symptom |
body_aches |
| Sex | male |
sex |
male |
| Symptom onset | 2 days ago |
onset_days |
2 |
| Age | 50 |
age |
50 |
| Height | 5'8 |
height |
5ft8in |
| Weight | 165lbs |
weight_lb |
165 |
| Current medications | none |
medications |
reported_none |
| Known allergies | none |
allergies |
reported_none |
The symptom row deliberately uses ache and pains, the wording in the supplied source. Additional surface forms such as aches and pains need their own configured match or appropriate analyzer behavior.
The same field-scoped none mapping can be configured for history, tests, family history, and other information. The assembler groups those outputs under reported_none; it must never infer them from a lack of matches.
The dictionary can explicitly cover the example age, height, weight, and duration phrases. A general-purpose application instead needs validated numeric/unit parsing for values outside its dictionary coverage. Recognizing a nearby word such as “age” does not extract a number automatically.
The application supplies source=patient_report and verified=false from provenance metadata. It supplies unknown=symptom_progression from a required-slot completeness check. These are not clinical inferences generated by the FST.
The intended boundary is:
source fields → configured FST matches (type/output + source field)
→ validated context assembler → compact prompt context
Preserve match evidence and provenance in the protected audit record; send only the prompt-relevant representation to the model. Apply the same analyzer at dictionary build and match time, and test that the configured surface forms actually match.
The file keeps the original question separate and preserves the original role, safety instructions, and response format. Unlike the inline source, it retains symptom details, onset, height/weight, medications, allergies, tests, and family-history information.
Measured full prompt: 435 tokens, using the same counting method as the three source files. The context block alone is not the full prompt; the total includes the shared instructions and response format.
This is the intended pattern: a clear question plus concise context, rather than a bare question or a question that must also carry the patient narrative. The example is not a clinically validated template. A production schema should preserve each field's meaning and provenance, and clinical experts should determine what information must be retained.
Count any proposed representation with the target model's tokenizer. JSON, uppercase labels, and abstract identifiers are not automatically smaller than plain language.
The Observe First, Act Deliberately pattern makes the comparison auditable. For each model call, retain an appropriately protected record of:
| Category | Suggested evidence |
|---|---|
| Lineage | Trace ID, parent event, workflow stage |
| Recognition | Tags, dictionary version, analyzer configuration |
| Context | Included, missing, excluded, and conflicting fields; provenance |
| Prompt | Template version and content hash |
| Token measurement | Tokenizer/encoding for local counts; provider/model for API usage |
| Response | Provider-reported output usage and relevant output tags |
| Outcome | Follow-up required, reviewer assessment, action taken |
Use synthetic examples for published benchmarks. In live medical workflows, minimize sensitive content in logs, restrict access, and apply appropriate privacy and retention controls. A hash supports identification and integrity checking; it does not reconstruct a prompt by itself.
The suspicious-intent dictionary can contribute additional observations on input and generated prompts. Those tags can remain non-blocking in observe mode, while existing authorization and safety controls stay in force.
To isolate placement, compare versions containing the exact same facts and constraints:
- Prepare a synthetic, fixed set of patient facts.
- Express those facts in a structured context block and in inline prose.
- Keep the question, safety instructions, response format, model, tool configuration, and generation settings constant.
- Count the complete input using the target tokenizer.
- Run repeated trials and collect provider-reported usage and latency.
- Evaluate factual preservation, unsupported assumptions, missing-information handling, and safety not only length.
- Include follow-up turns when calculating usage per completed task.
To study the value of additional information, run a separate experiment comparing incomplete and complete context. Include a concise, separate context variant as the proposed design and evaluate whether it preserves required facts while reducing unnecessary text. Do not mix that question with a placement-only claim.
For medical applications, a qualified clinical reviewer should define the evaluation criteria. A token benchmark is not clinical validation.
Using Node.js with gpt-tokenizer@4.1.0 installed, the counting logic is:
const fs = require("node:fs");
const { encode } = require("gpt-tokenizer/encoding/cl100k_base");
const files = [
"attached_assets/medical_question_no_context_1792690490944.txt",
"attached_assets/medical_question_with_context_1792690483385.txt",
"attached_assets/medical_question_with_prompt_context_1792690469244.txt",
"prompts/medical_question_concise_context.txt"
];
for (const file of files) {
const text = fs.readFileSync(file, "utf8").replace(/\r\n/g, "\n");
console.log(file, encode(text).length);
}The filenames identify the supplied local source files and the added prompt file; they are not GitHub download links. Someone reproducing the analysis needs copies of those exact files, including their formatting.
Percentage calculations:
Structured increase over baseline = (469 - 352) / 352 × 100 = 33.2%
Inline increase over baseline = (366 - 352) / 352 × 100 = 4.0%
Inline reduction vs. structured = (469 - 366) / 469 × 100 = 22.0%
FST-style reduction vs. structured = (469 - 435) / 469 × 100 = 7.2%
Prefer a concise, explicit context block over leaving relevant facts out or mixing them into the question.
That is the design recommendation not a claim that separate context always produces better responses. A few extra input tokens can be worthwhile when they preserve relevant facts and make the workflow easier to validate and audit.
The three supplied prompts contain 352, 469, and 366 tokens. The added illustrative FST-derived-context prompt contains 435 tokens and preserves the fuller template's supplied facts in canonical fields. These counts measure input size; no live FST execution or model-response experiment has established extraction accuracy or answer-quality improvements.
FSTGuardrails can help recognize the vocabulary used to assemble that context and track it across a workflow. The application must preserve relevant facts, validate their interpretation, and measure actual end-to-end results.
Tag first. Make context concise and explicit. Measure usefulness not just length.
- FSTGuardrails repository
- FSTGuardrails wiki
- Observe First, Act Deliberately Context Tracking and Audit with FSTGuardrails
- Source material: the three user-supplied medical-question prompt files identified in the reproduction example above.
- Added example:
prompts/medical_question_concise_context.txtcomplete prompt with illustrative FST-derived context and the original safety instructions.