Module 02 · Lesson 03

Constraints, Guardrails, and Format Control

Reading time: 22 minutes Track: Prompt Mastery · Required for all learners Prerequisites: Module 02 · Lessons 01–02

What this lesson does

Constraints are the most underused element of the six-element framework — and in biotech, they're arguably the most important. A prompt without constraints produces output that may be wrong in ways that look right. A prompt with the right constraints produces output that's bounded, compliant, and reviewable.

By the end of this lesson, you'll be able to:

Build constraint stacks for the most common biotech work
Distinguish "hard constraints" from "soft constraints" and use each appropriately
Apply format control to produce output that doesn't need restructuring
Avoid the constraint failures that cause compliance and accuracy problems

This lesson is dense. It contains constraint libraries you'll reference for years. Don't try to memorize it — bookmark it and revisit.

01 · The two kinds of constraints

There are two functional categories of constraints, and they behave differently.

Hard constraints

Rules the output must not violate, period. Compliance, safety, scope, source restriction.

Examples:

"Do not generate any citations — leave [CITE] placeholders"
"Do not use any data not provided in this prompt"
"Do not state or imply causality for the adverse events listed"
"Do not include patient-identifiable information"
"Do not make comparative efficacy claims against marketed therapies"

Hard constraints are absolute. The model should fail to produce output rather than violate them. In practice, you should also verify hard constraints in review — the model can drift even with hard constraints stated.

Soft constraints

Stylistic and structural preferences. The output should follow them but a reasonable deviation isn't catastrophic.

Examples:

"Use third-person voice"
"Keep paragraphs under 100 words"
"Lead each section with the conclusion"
"Use plain language where possible"

Soft constraints shape the output but you can fix violations in editing without it being a compliance issue.

Why the distinction matters

If you bury hard constraints in a soft-constraint list, the model treats them all with equal weight. The result: occasional violation of hard constraints because they didn't stand out.

Rule: Separate hard and soft constraints in your prompt. Hard constraints get their own labeled section. Use language like "CRITICAL CONSTRAINTS — MUST NOT VIOLATE:" followed by the hard list, then "STYLISTIC GUIDANCE:" for the soft list.

02 · The biotech hard constraint library

These are the constraints that recur across nearly every biotech use case. Memorizing them isn't the goal — being able to recognize which apply to each task is.

Constraint 1 — No fabricated citations

"Do not generate any citations, references, or source attributions. If a claim would normally require a citation, insert the placeholder [CITE: brief description of what's being cited] in brackets. I will fill these in manually."

This single constraint prevents the most common biotech AI failure: hallucinated references that look real. Use it in every prompt that involves scientific or regulatory content.

Constraint 2 — Source restriction

"Use only the information I have provided in this prompt. Do not introduce data, trial results, label information, or other content from your training data. If you're uncertain whether something I've stated is correct, flag it with [VERIFY] — do not silently correct or augment."

This prevents the model from "helpfully" adding outside information that may be wrong or outdated. Critical for regulatory work where accuracy of provided data matters.

Constraint 3 — No causality inference

"Do not state or imply causality for adverse events, clinical outcomes, or other observations unless I have explicitly told you that causality has been determined. Use neutral language: 'subject experienced X' rather than 'X was caused by Y'."

Causality language is regulatory dynamite. AI tends to write it confidently when humans would be more cautious. Constrain it explicitly.

Constraint 4 — No comparative claims

"Do not make any comparative claims against other therapies, devices, or treatments, marketed or investigational. Do not use language like 'better than,' 'similar to,' 'unlike,' 'superior to,' or comparable phrasings. If a comparison is needed, leave a [COMPARE: X vs Y] placeholder."

Comparative claims have specific regulatory and legal requirements. Don't let AI generate them off-the-cuff.

Constraint 5 — No off-label content

"Do not generate content about uses, populations, dosing, or indications outside what I have explicitly stated. If the data I'm providing involves an unapproved use, do not extrapolate to potential approved uses or vice versa."

Off-label is one of the highest-risk areas in commercial biotech. Constrain it explicitly even if you think the context makes it obvious.

Constraint 6 — Patient privacy

"Do not include any patient-identifiable information in the output. Subject identifiers must be in the de-identified format I've used (e.g., 4012-007). Do not generate or include patient names, dates of birth, addresses, or any other PHI. Do not reference specific cases in ways that could identify individuals when combined with other publicly available information."

For any output that may be shared, even internally.

Constraint 7 — Regulatory terminology

"All adverse event terminology must use MedDRA preferred terms. All severity grading must use CTCAE v[X.X]. All efficacy endpoint terminology must use the definitions in our protocol [provided in context]. Do not substitute clinical or colloquial terms for the regulatory standards."

Terminology consistency is what reviewers actually check. Constrain it.

Constraint 8 — Tone consistency

"Match the tone and terminology of the reference document I've provided. Do not introduce stylistic variations even if you think they would improve readability. Consistency across the submission/document set takes priority over individual section quality."

For multi-section documents where consistency matters more than any single section's polish.

Constraint 9 — Caveat preservation

"Preserve all caveats, limitations, and uncertainty language from the source materials I've provided. Do not strengthen or weaken qualifiers (e.g., 'may indicate' should not become 'indicates'; 'preliminary' should not become 'demonstrated'). Maintain the epistemic register of the source."

A subtle but important constraint. AI tends to firm up tentative language. In regulatory contexts, that's a problem.

Constraint 10 — Numerical precision

"Reproduce all numerical values from the source materials exactly. Do not round, approximate, or restate numbers in different units unless I explicitly request it. If a number is reported as '34.7%' do not write it as 'approximately 35%' or 'just over a third'."

For any output where data are being summarized. AI is prone to rounding "for readability" and it produces inaccurate summaries.

03 · Soft constraints — the format control library

Soft constraints shape readable output. The most useful ones recur across many tasks.

Length control

"Length: approximately [X words / X paragraphs]. Do not exceed [Y]."

Length specifications work better when ranged ("250-300 words") than when single ("300 words"). The model has trouble hitting exact counts.

Structural control

"Structure: [N] sections, each labeled [list section labels]. Each section should be [X paragraphs/words] approximately."

Specifying section structure upfront prevents the most common format failure (model produces a stream of text when you wanted sections).

Voice and tense

"Use third-person, past tense for completed activities. Use third-person, present tense for ongoing observations. Do not use first-person language anywhere."

Voice and tense rules vary by document type. State yours.

List vs prose

"Use prose, not bullet points. Bullet points are acceptable only in [specific section]."

Or the reverse. Either way, specify, because the model has no default and will mix them.

Heading conventions

"Use sentence case for headings (capitalize first word only). No heading should exceed 8 words. Do not number headings unless specifically requested."

Heading style varies. Encode yours.

Citation placement style

"Place citation placeholders [CITE: X] at the end of the sentence they support, before the period. Multiple citations in one sentence should be combined: [CITE: A, B, C]. Do not group citations at the end of paragraphs."

Citation conventions vary by publication / submission type. Specify.

Number formatting

"Spell out numbers under 10 (e.g., 'three') in prose. Use numerals for 10 and above. Use numerals for all percentages, doses, and measurements regardless of magnitude. Use commas as thousands separators."

Style guide minutiae the model will get wrong without explicit guidance.

04 · Worked example — constraint stack in action

Let's combine these constraints into a real prompt header. Scenario: a medical writer drafting a CSR safety summary section.

CRITICAL CONSTRAINTS — MUST NOT VIOLATE:

Use only the data provided in the attached safety summary tables. Do not introduce any data not present in the source. Flag uncertainty with [VERIFY].

Do not generate citations. Use [CITE: description] placeholders.

Do not state or imply causality unless the source explicitly states it. Use neutral observational language.

Do not make any comparative claims against other therapies.

All AE terminology must use MedDRA preferred terms (v25.0). All severity grading must use CTCAE v5.0.

No patient-identifiable information. Subject IDs must be in the de-identified format used in source tables.

Preserve all caveats and limitations from the source materials. Do not strengthen tentative language.

Reproduce numerical values exactly as in source tables. No rounding or approximation.

STYLISTIC GUIDANCE:

Third-person, past tense

Prose only, no bullet points

Section length: 600-800 words

Lead each subsection with the most clinically significant finding

Sentence-case headings, no numbering

Match the tone of the reference Section 12 from our prior CSR (provided below)

That looks like a lot. It is. Once written, it's reusable across every CSR you draft. Time invested upfront, time saved on every subsequent use.

05 · Format control beyond constraints — output templates

For repeatable tasks, define the output template explicitly. The model fills the template.

Template example — protocol deviation memo

"Produce output in exactly this structure:

PROTOCOL DEVIATION MEMO

Date: [date]
Study: [study ID and brief title]
Subject: [de-identified ID]
Classification: [Minor / Major / Critical]
Reporting Required: [Yes / No, with rationale]

1. DESCRIPTION OF DEVIATION
[Single paragraph, 100-150 words]

2. ROOT CAUSE
[Single paragraph, 75-100 words]

3. SUBJECT SAFETY IMPACT
[Single paragraph, 75-100 words]

4. DATA INTEGRITY IMPACT
[Single paragraph, 75-100 words]

5. CORRECTIVE AND PREVENTIVE ACTION
[Single paragraph, 100-150 words]

6. REPORTING STATUS
[Single paragraph, 50-75 words]

Fill the template using the information I'm providing below."

Output templates are particularly powerful because they:

Eliminate format ambiguity entirely
Make output instantly comparable across cases
Reduce review burden (reviewer knows exactly where each element is)
Enable QC checks (missing sections are immediately visible)

For any document type you produce more than 3-4 times per year, building an output template is high-leverage.

06 · The "ask the model to verify" pattern

One advanced constraint technique: ask the model to check its own work before presenting the output.

"Before producing the final output, internally verify:

All numerical values match the source tables exactly

No causality language was used

All AE terms are MedDRA preferred terms

No citations were generated (only [CITE] placeholders)

The output length is within the specified range

Only after passing these checks, produce the final output."

Does this work? Partially. The model isn't perfectly capable of auditing itself — its self-checks can miss the same errors that produced the original output. But it does catch some obvious violations, and it costs you nothing to include.

Use this for medium-stakes outputs. Don't rely on it as the sole verification for high-stakes work.

07 · Constraint failures — recognition and recovery

Even with strong constraints, the model sometimes fails. Recognize these patterns:

Failure pattern 1 — Silent constraint violation

The model produces output that violates a hard constraint without flagging it. Most common with citations (fabricated despite [CITE] instruction) and with causality language (firm causality despite "no causality" instruction).

Recognition: Always scan output for the specific constrained items even when the constraint was clear.

Recovery: Reissue the prompt with stronger language: "I noticed the previous output [violated constraint X]. Reproduce the output with that specific constraint corrected."

Failure pattern 2 — Constraint drift in long outputs

For long outputs, the model may follow constraints early then drift. Constraints stated at the start lose attention weight far from the generation point.

Recognition: Check the latter half of long outputs more carefully than the first half.

Recovery: For very long outputs, break the task into sections and reapply constraints to each.

Failure pattern 3 — Constraint conflict

You stated two constraints that conflict. The model resolves the conflict however it can, often in a way you didn't intend.

Recognition: When output is strangely structured, check whether your constraints fought each other.

Recovery: Pick one of the conflicting constraints and rewrite, removing or modifying the other.

Failure pattern 4 — Overzealous compliance

The model follows a constraint so strictly that the output becomes stilted or unreadable. Common with "use only this terminology" constraints when the terminology is sparse.

Recognition: Output feels mechanical or repetitive.

Recovery: Soften the constraint: "Prefer X terminology when possible; use Y or Z if X would create unnatural phrasing."

08 · A note on token cost

Constraint stacks add tokens to your prompts. For tools charged per token (most API uses), this has real cost.

The math for biotech:

A heavy constraint stack adds maybe 300-500 tokens to a prompt
At Claude's current pricing, that's a few cents per call
The time saved from getting compliant output on first try is minutes to hours
ROI is effectively infinite

Stop worrying about token cost for high-stakes work. Worry about it only for very high-volume, low-stakes automation where you're calling the API thousands of times.

09 · A practical exercise

Take a document type you produce regularly. Spend 15 minutes building a constraint stack for it. Include:

5-7 hard constraints specific to your document type
4-5 stylistic guidelines
An output template if applicable

Save it. The next time you draft this document type, you start with that stack and substitute the case-specific content.

This is the foundation of your prompt library, which we'll formalize in Lesson 06.

10 · Knowledge check

Three questions.

Q1. Why should hard constraints be visually separated from soft constraints in a prompt?

a) It makes the prompt easier to read b) The model treats all constraints with equal weight unless they're separated; hiding hard constraints among soft ones leads to occasional violation of critical rules c) It's required for compliance documentation d) It reduces token cost

Q2. Which of these is the most important biotech-specific hard constraint to include in any scientific prompt?

a) Length constraints b) Voice and tense constraints c) "Do not generate citations — use [CITE] placeholders" — preventing the single most common AI failure in biotech d) Heading conventions

Q3. When the model "drifts" from a constraint in the latter portion of a long output, what's the best recovery strategy?

a) Restart the entire conversation with a stricter constraint b) Accept it — long outputs always drift c) Break the task into sections and reapply the constraints to each, since constraint attention degrades over long outputs d) Use a smaller model, which drifts less

Answers: Q1: b · Q2: c · Q3: c

11 · What's next

Lesson 04 — Iterative refinement and prompt debugging — covers what to do when the first prompt didn't produce what you needed. This is the difference between people who give up on prompts that don't work and people who systematically improve them.

End of Lesson 03.