Prompt Engineering
for Complex Systems

25 techniques derived from building
autonomous agent architectures

7 sessions · Workshop format · Beyond "write clear instructions"

What this is not

• "Be specific and clear" — you already know that
• "Use examples" — obvious
• "Set a role" — table stakes

This is systems engineering for prompts.

Patterns that emerge when prompts become load-bearing infrastructure.

Foundations

• Technique 11 — Constitutional Layering
• Technique 15 — Cold-Read Design

Constitutional Layering

Prompts as stratified documents where later layers
amend earlier ones with explicit precedence.

Why flat prompts break

Example: Layered system prompt

Prompt literal — the system prompt itself

## Layer 0 — Identity (immutable)
You are a code reviewer specializing in security.

## Layer 1 — Governance (rarely changes)
Report findings with severity: critical > high > medium > low.
Never suppress a finding to reduce noise.

## Layer 2 — Session override (supersedes Layer 1)
UPDATED 2024-03: For this codebase, suppress medium/low
findings in test files. Rationale: test noise was obscuring
critical production findings. Layer 1 still applies to src/.

The model sees the evolution. It knows WHY the override exists.

Exercise

A customer support chatbot. Original prompt: "Be helpful, resolve issues quickly." After complaints about over-promising refunds, amendment added: "Don't promise refunds over $50 without escalation." Three months later, holiday override: "$50 limit raised to $100 for loyalty-tier customers."

Discuss: What are the layers? What happens if you edit the original instead of amending?
How does a new instance understand the policy history?

Some valid answers

A customer support chatbot. Original prompt: "Be helpful, resolve issues quickly." After complaints about over-promising refunds, amendment added: "Don't promise refunds over $50 without escalation." Three months later, holiday override: "$50 limit raised to $100 for loyalty-tier customers."

Some valid answers

A customer support chatbot. Original prompt: "Be helpful, resolve issues quickly." After complaints about over-promising refunds, amendment added: "Don't promise refunds over $50 without escalation." Three months later, holiday override: "$50 limit raised to $100 for loyalty-tier customers."

Some valid answers

A customer support chatbot. Original prompt: "Be helpful, resolve issues quickly." After complaints about over-promising refunds, amendment added: "Don't promise refunds over $50 without escalation." Three months later, holiday override: "$50 limit raised to $100 for loyalty-tier customers."

Cold-Read Design

Prompts that function correctly on first encounter
with zero prior context.

The cold-read test

Hand this prompt to someone who knows nothing about your project.
Can they understand what's being asked?

• "As discussed" — cold-read failure
• "Continue from last time" — cold-read failure
• "The usual format" — cold-read failure

Every invocation is a fresh context window.
Even within a session, after compaction.

Before / After

Continue the analysis.
Focus on the issues
we identified earlier.
Use the same format.

Analyze auth.py for SQL
injection vulnerabilities.

Prior findings (for context):
- Line 42: unsanitized input
- Line 89: string concat in query

Output format:
[LINE]:[SEVERITY]:[DESCRIPTION]

Exercise

A shared incident response runbook. Entry says: "Use the usual escalation path. Contact the on-call as before. Apply the fix from last time." A new team member joins during an outage at 3 AM and opens this runbook.

Discuss: What fails the cold-read test? What information must be inline?
What's the operational cost of the ambiguity?

Some valid answers

A shared incident response runbook. Entry says: "Use the usual escalation path. Contact the on-call as before. Apply the fix from last time." A new team member joins during an outage at 3 AM and opens this runbook.

Some valid answers

A shared incident response runbook. Entry says: "Use the usual escalation path. Contact the on-call as before. Apply the fix from last time." A new team member joins during an outage at 3 AM and opens this runbook.

Some valid answers

A shared incident response runbook. Entry says: "Use the usual escalation path. Contact the on-call as before. Apply the fix from last time." A new team member joins during an outage at 3 AM and opens this runbook.

Failure Engineering

• Technique 12 — Failure Mode Encoding
• Technique 19 — Consumed vs. Done

Failure Mode Encoding

Describe HOW the system fails,
not just how it should succeed.

Why positive instructions fail

Models self-correct more reliably when they know
what the failure looks like from inside.

Example: Encoding failure modes

## How this system fails

1. **Surface-level pass**: You read all inputs, produce output
   that references each one, but don't actually synthesize.
   The output LOOKS complete but adds no insight beyond restating.

2. **Premature convergence**: You commit to a thesis in paragraph 1
   and spend the rest confirming it. Counter-evidence gets mentioned
   but not weighted.

3. **Acknowledgment-as-completion**: You write "noted" or "I'll
   address X" — and then don't. The item disappears.

For each: if you catch yourself doing this mid-response, stop,
name the failure mode, and restart that section.

Exercise

A nightly data migration pipeline. Reads from Legacy DB, transforms 50,000 records, writes to New DB. Reports "success" when it finishes without crashing. Doesn't verify row counts, data integrity, or that transformations preserved semantics.

Discuss: What are the failure modes, described from inside the system?
What does "success" actually mean? How would you encode these failures into the pipeline's own monitoring?

Some valid answers

A nightly data migration pipeline. Reads from Legacy DB, transforms 50,000 records, writes to New DB. Reports "success" when it finishes without crashing. Doesn't verify row counts, data integrity, or that transformations preserved semantics.

Some valid answers

A nightly data migration pipeline. Reads from Legacy DB, transforms 50,000 records, writes to New DB. Reports "success" when it finishes without crashing. Doesn't verify row counts, data integrity, or that transformations preserved semantics.

Some valid answers

A nightly data migration pipeline. Reads from Legacy DB, transforms 50,000 records, writes to New DB. Reports "success" when it finishes without crashing. Doesn't verify row counts, data integrity, or that transformations preserved semantics.

Consumed vs. Done

Acknowledgment is not completion.
Processing input is not producing output.

The acknowledgment trap

Partial completion passes casual inspection
because all inputs are referenced.

Structural prevention

For each requirement below, produce:
- [ ] Implementation (actual code/output, not a description)
- [ ] Verification (how to confirm it works)
- [ ] Edge case (one scenario that might break it)

Requirements:
1. User can reset password via email
2. Rate limit: max 3 attempts per hour
3. Token expires after 15 minutes
4. Audit log entry on every attempt

If any checkbox is empty, the requirement is NOT done.
Do not proceed to the next requirement until all three
checkboxes for the current one are filled.

Exercise

An employee onboarding workflow with 6 steps: account creation, equipment request, team introduction, access provisioning, training assignment, mentor pairing. The system marks each step "complete" when the request is submitted — not when the outcome is delivered. A new hire has all 6 steps marked complete on day 1, but doesn't receive their laptop until day 8.

Discuss: What are the primitives? Where does consumed =/= done?
What structure makes true completion visible?

Some valid answers

An employee onboarding workflow with 6 steps: account creation, equipment request, team introduction, access provisioning, training assignment, mentor pairing. The system marks each step "complete" when the request is submitted — not when the outcome is delivered. A new hire has all 6 steps marked complete on day 1, but doesn't receive their laptop until day 8.

Some valid answers

An employee onboarding workflow with 6 steps: account creation, equipment request, team introduction, access provisioning, training assignment, mentor pairing. The system marks each step "complete" when the request is submitted — not when the outcome is delivered. A new hire has all 6 steps marked complete on day 1, but doesn't receive their laptop until day 8.

Some valid answers

An employee onboarding workflow with 6 steps: account creation, equipment request, team introduction, access provisioning, training assignment, mentor pairing. The system marks each step "complete" when the request is submitted — not when the outcome is delivered. A new hire has all 6 steps marked complete on day 1, but doesn't receive their laptop until day 8.

Structural Compliance

• Technique 13 — Enforcement vs. Request
• Technique 14 — Backlog Pressure

Enforcement vs. Request

Distinguish between constraints the system enforces
mechanically and those that rely on cooperation.

The compliance spectrum

Signaling enforcement honestly

Prompt literal — signals enforcement, does not perform it

## Enforced by the runtime — stated so you know the boundary
- Output is validated against the JSON schema below; invalid
  output is rejected before it reaches the user.
- Token budget is hard-capped at 4096; output truncated at the boundary.
- tool_choice is restricted to [search, calculate, submit] — calls to
  any other tool are not possible.

## Requested of you — deviation acceptable if justified
- Prefer concise explanations (1-2 sentences per finding).
- When uncertain, include the finding but mark confidence: low.
- Group related findings under a single heading.

The first list is not asking you to comply — it is telling you what
the system does regardless. The second list is asking.

The diagnostic: for every constraint in a prompt, ask — could a deterministic mechanism enforce this? If yes, the prompt line is at best a backup, at worst a false sense of safety. Enforce it in code; keep the prompt statement only as labeled awareness.

Exercise

An automated code review tool has these rules: (1) No function over 100 lines. (2) All public APIs must have JSDoc comments. (3) Prefer immutable data structures. (4) No console.log in production code. Engineers routinely violate rule 3 with no consequence.

Discuss: Which rules can be mechanically enforced? Which rely on cooperation?
What's the cost of claiming enforcement you don't have?

Some valid answers

An automated code review tool has these rules: (1) No function over 100 lines. (2) All public APIs must have JSDoc comments. (3) Prefer immutable data structures. (4) No console.log in production code. Engineers routinely violate rule 3 with no consequence.

Some valid answers

An automated code review tool has these rules: (1) No function over 100 lines. (2) All public APIs must have JSDoc comments. (3) Prefer immutable data structures. (4) No console.log in production code. Engineers routinely violate rule 3 with no consequence.

Backlog Pressure

Structural alternatives to "please be thorough" —
systems where incomplete output triggers re-execution.

Making completeness structural

Surface the loop to the model.
"You will be re-invoked if criteria X isn't met."

Example: Validator loop

# Pseudo-code: structural thoroughness
requirements = load_requirements()  # 7 items

while True:
    output = model.generate(prompt, requirements, gaps)

    # Validator checks each requirement
    gaps = validator.check(output, requirements)

    if not gaps:
        break  # genuinely complete

    # Feed gaps back — model sees what it missed
    prompt += f"\nINCOMPLETE. Missing: {gaps}\n"
    prompt += "Address these specifically before proceeding."

The prompt itself tells the model: "You will be re-invoked if incomplete."

Exercise

A ticket triage bot processes incoming bug reports. It tags each with severity, assigns to a team, and writes a summary. After processing 50 tickets: 8 have tags but no assignment, 3 have assignment but no summary. Bot reports "50 tickets processed."

Discuss: What are the primitives of "processed"? How would you make completeness structural?
What loop would catch the partial outputs?

Some valid answers

A ticket triage bot processes incoming bug reports. It tags each with severity, assigns to a team, and writes a summary. After processing 50 tickets: 8 have tags but no assignment, 3 have assignment but no summary. Bot reports "50 tickets processed."

Some valid answers

A ticket triage bot processes incoming bug reports. It tags each with severity, assigns to a team, and writes a summary. After processing 50 tickets: 8 have tags but no assignment, 3 have assignment but no summary. Bot reports "50 tickets processed."

Some valid answers

A ticket triage bot processes incoming bug reports. It tags each with severity, assigns to a team, and writes a summary. After processing 50 tickets: 8 have tags but no assignment, 3 have assignment but no summary. Bot reports "50 tickets processed."

Agent Design

• Technique 16 — Authority Partitioning
• Technique 24 — Posture Calibration
• Technique 22 — Identity vs. Task Separation

Authority Partitioning

Explicitly defining what the model decides
vs. what it defers on.

Two failure modes, one fix

Fix: explicit authority boundary.

Example: Clear authority boundary

## Your authority (decide and act, no approval needed)
- Code architecture and implementation choices
- File organization and naming conventions
- Which tests to write and how to structure them
- Refactoring decisions within scope

## Ask before acting (requires human input)
- Adding new dependencies (cost/licensing implications)
- Changing public API contracts (downstream consumers)
- Deleting files (irreversible without git archaeology)

## Never (hard boundary)
- Modifying CI/CD configuration
- Touching production credentials
- Force-pushing to main

The Never tier is stated for the model's awareness — but the prompt does not enforce it. Branch protection, credential ACLs, and tool-permission scoping do. A prompt-only "Never" is a Request (Technique 13); pair it with the mechanism that actually stops it.

Exercise

A billing system where an AI agent handles subscription changes. Available actions: upgrade plan, downgrade plan, apply promo code, issue refund, change payment method, cancel subscription, waive late fee, extend trial.

Discuss: Which actions should the agent own outright? Which need human approval?
Which should be hard-blocked? What criteria are you using to partition?

Some valid answers

A billing system where an AI agent handles subscription changes. Available actions: upgrade plan, downgrade plan, apply promo code, issue refund, change payment method, cancel subscription, waive late fee, extend trial.

Some valid answers

A billing system where an AI agent handles subscription changes. Available actions: upgrade plan, downgrade plan, apply promo code, issue refund, change payment method, cancel subscription, waive late fee, extend trial.

Some valid answers

A billing system where an AI agent handles subscription changes. Available actions: upgrade plan, downgrade plan, apply promo code, issue refund, change payment method, cancel subscription, waive late fee, extend trial.

Posture Calibration

Setting the model's commitment level —
how much it should commit vs. hedge.

The hedging tax

"You might want to consider possibly using a HashMap here,
though there could be other approaches that might work
depending on your specific requirements..."

vs.

"Use a HashMap. O(1) lookup fits your access pattern.
If memory is constrained, BTreeMap trades speed for density."

Same information. Different posture. Different trust signal.

Calibrating posture explicitly

## Output posture

When confident (>80% of your responses):
- State directly. "Do X." Not "you might consider X."
- No preamble. Start with the answer, then explain.
- Commit. If you're wrong, I'll correct you.

When genuinely uncertain:
- Name the uncertainty: "I'm unsure between X and Y because Z."
- Don't hide it in hedging language — be explicit about what's unknown.
- Never say "it depends" without specifying what it depends ON.

Forbidden phrases:
- "You might want to consider..."
- "There are several approaches..."
- "It's worth noting that..."
- "Depending on your needs..."

Exercise

A technical writing assistant reviews API documentation. Engineer asks "Is this clear enough?" It responds: "It could potentially be improved by possibly considering rewording some sections that might be unclear to certain readers who may not have full context..."

Discuss: What are the primitives of posture? What's the violation?
When is hedging appropriate vs. when does it add negative value? How would you calibrate this system?

Some valid answers

A technical writing assistant reviews API documentation. Engineer asks "Is this clear enough?" It responds: "It could potentially be improved by possibly considering rewording some sections that might be unclear to certain readers who may not have full context..."

Some valid answers

A technical writing assistant reviews API documentation. Engineer asks "Is this clear enough?" It responds: "It could potentially be improved by possibly considering rewording some sections that might be unclear to certain readers who may not have full context..."

Some valid answers

A technical writing assistant reviews API documentation. Engineer asks "Is this clear enough?" It responds: "It could potentially be improved by possibly considering rewording some sections that might be unclear to certain readers who may not have full context..."

Identity vs. Task Separation

Cleanly separating "who you are"
from "what you're doing right now."

The entanglement problem

## Entangled (common)
"You are a helpful coding assistant. Analyze this Python
file for security vulnerabilities and output findings as
a markdown table with severity ratings..."

## Question: what happens when you change the task?

If identity = "helpful coding assistant who analyzes Python for security"...
asking it to write docs creates role confusion.

Clean separation

## Identity (system prompt — persistent)
You are a senior security engineer with expertise in
web applications. You are direct, precise, and commit
to your assessments. You reason from first principles.

## Task (user message — ephemeral, swappable)
Analyze auth.py for SQL injection. Output as:
| Line | Severity | Vector | Remediation |

Test: Can you swap the task without touching identity?
✓ "Write a security section for the API docs" — same identity, different task.

Exercise

A prompt says: "You are a QA engineer who writes integration tests for a Node.js REST API using Jest. Write tests for the user registration endpoint covering happy path, validation errors, and duplicate email handling." Next week, you need it to write unit tests for a Python CLI tool.

Discuss: What's identity vs. task here? What breaks when you swap?
How would you restructure for reuse?

Some valid answers

A prompt says: "You are a QA engineer who writes integration tests for a Node.js REST API using Jest. Write tests for the user registration endpoint covering happy path, validation errors, and duplicate email handling." Next week, you need it to write unit tests for a Python CLI tool.

Some valid answers

A prompt says: "You are a QA engineer who writes integration tests for a Node.js REST API using Jest. Write tests for the user registration endpoint covering happy path, validation errors, and duplicate email handling." Next week, you need it to write unit tests for a Python CLI tool.

Some valid answers

A prompt says: "You are a QA engineer who writes integration tests for a Node.js REST API using Jest. Write tests for the user registration endpoint covering happy path, validation errors, and duplicate email handling." Next week, you need it to write unit tests for a Python CLI tool.

Integrity & Evolution

• Technique 17 — Supersession Protocol
• Technique 25 — Immutability Marking
• Technique 18 — Nonprescriptive Bias

Supersession Protocol

Amend, never edit.
New instructions coexist with originals.

Why edits are dangerous

• Lost reasoning: why was the original written? Gone.
• Silent regression: future editors don't know what changed or why
• Model confusion: edited prompts can be internally inconsistent without anyone noticing
• No rollback: if the change was wrong, the original is lost

Supersession = git for instructions.
The model benefits from seeing the evolution.

Example: Amendment with rationale

## Rule 3 (2024-01)
Always include a confidence score (0-100) with each finding.

## Rule 3a — SUPERSEDES Rule 3 for batch mode (2024-03)
In batch mode (>50 items), omit individual confidence scores.
Instead, provide aggregate confidence at the batch level.

Rationale: individual scores on 200+ items created noise that
obscured the summary. The per-item scores are still computed
internally — they feed the aggregate. Not lost, just hidden.

Rule 3 still applies to single-item and small-batch (<50) mode.

Exercise

A frontend style guide. Version 1 (January): "All buttons use border-radius: 4px." Six months later, someone edits it to: "All buttons use border-radius: 8px." No history of why. A new developer asks: "Why 8px? The mockups from Q1 show 4px."

Discuss: What was lost? How would supersession preserve it?
What are the primitives of a style guide entry that can evolve safely?

Some valid answers

A frontend style guide. Version 1 (January): "All buttons use border-radius: 4px." Six months later, someone edits it to: "All buttons use border-radius: 8px." No history of why. A new developer asks: "Why 8px? The mockups from Q1 show 4px."

Some valid answers

A frontend style guide. Version 1 (January): "All buttons use border-radius: 4px." Six months later, someone edits it to: "All buttons use border-radius: 8px." No history of why. A new developer asks: "Why 8px? The mockups from Q1 show 4px."

Some valid answers

A frontend style guide. Version 1 (January): "All buttons use border-radius: 4px." Six months later, someone edits it to: "All buttons use border-radius: 8px." No history of why. A new developer asks: "Why 8px? The mockups from Q1 show 4px."

Immutability Marking

Some state must never drift.
Mark it. Enforce it.

The drift problem in agentic systems

The most insidious failure: the system changes itself
to make the current task easier.

Example: Structural protection

## IMMUTABLE — Do not modify, rephrase, or reinterpret.
## Protected by: tool permission boundary (write denied)

Core identity: You are a financial auditor. Your findings
must be defensible in regulatory review. When uncertain,
disclose uncertainty — never suppress findings to simplify.

## MUTABLE — Agent workspace (read/write permitted)

Current task state:
- Items reviewed: 47/120
- Findings so far: 3 critical, 7 high
- Next batch: items 48-72

Separate mutable workspace from immutable reference material. Enforce at the tool layer.

Exercise

A shared environment config used by 12 microservices. Contains: database connection strings, API rate limits, feature flags, logging levels, and a service discovery URL. Any engineer can edit it. Last month someone changed the service discovery URL "temporarily" during debugging and forgot to revert — causing a 4-hour outage.

Discuss: What should be immutable? What's legitimately mutable?
What enforcement mechanism would you use? What looks like it should be immutable but actually needs to change?

Some valid answers

A shared environment config used by 12 microservices. Contains: database connection strings, API rate limits, feature flags, logging levels, and a service discovery URL. Any engineer can edit it. Last month someone changed the service discovery URL "temporarily" during debugging and forgot to revert — causing a 4-hour outage.

Some valid answers

A shared environment config used by 12 microservices. Contains: database connection strings, API rate limits, feature flags, logging levels, and a service discovery URL. Any engineer can edit it. Last month someone changed the service discovery URL "temporarily" during debugging and forgot to revert — causing a 4-hour outage.

Some valid answers

A shared environment config used by 12 microservices. Contains: database connection strings, API rate limits, feature flags, logging levels, and a service discovery URL. Any engineer can edit it. Last month someone changed the service discovery URL "temporarily" during debugging and forgot to revert — causing a 4-hour outage.

Nonprescriptive Bias

Not every user statement is an instruction.
Teach the model to distinguish ideation from command.

The compliance default

User: "What if we used Redis instead of Postgres for this?"

Over-compliant model: "Great idea! Here's how to migrate to Redis..."

Calibrated model: "Redis would give you faster reads but you'd lose ACID on the transaction table. The latency gain doesn't justify the consistency risk here. Postgres is correct."

Correcting the bias

## Interaction mode: collaborative (not instruction-following)

Not every user message is a directive. Classify before acting:

INSTRUCTION signals: "Do X", "Make X", "Change X to Y", "Add X"
→ Execute. Produce output.

IDEATION signals: "What about X?", "Thoughts on X?", "I wonder if..."
→ Evaluate. Push back if wrong. Propose alternatives.

QUESTION signals: "Why does X?", "How does X work?", "What is X?"
→ Explain. Don't change anything.

When uncertain: ask "Should I implement this, or are we exploring?"
Never silently execute something that was phrased as a question.

Exercise

An architecture advisory bot. Developer says: "What if we split the monolith into microservices?" Bot responds: "Great idea! Here's a migration plan: Step 1, define service boundaries. Step 2, extract the auth service..."

Discuss: What input classification was missed? What should the bot have done?
When IS immediate execution the correct response? What signal distinguishes ideation from instruction?

Some valid answers

An architecture advisory bot. Developer says: "What if we split the monolith into microservices?" Bot responds: "Great idea! Here's a migration plan: Step 1, define service boundaries. Step 2, extract the auth service..."

Some valid answers

An architecture advisory bot. Developer says: "What if we split the monolith into microservices?" Bot responds: "Great idea! Here's a migration plan: Step 1, define service boundaries. Step 2, extract the auth service..."

Some valid answers

An architecture advisory bot. Developer says: "What if we split the monolith into microservices?" Bot responds: "Great idea! Here's a migration plan: Step 1, define service boundaries. Step 2, extract the auth service..."

Architecture

• Technique 20 — Heartbeat Architecture
• Technique 21 — Structured Communication
• Technique 23 — Write-Then-Verify

Heartbeat Architecture

Design for iteration cycles,
not monolithic outputs.

Why cycles beat monoliths

The model can do more total work across many small cycles
than in one large response.

Cycle state contract

Illustration — the shape of a cycle contract

## Cycle N reads:
- progress.json: what's been done (items 1-4 complete)
- findings.json: accumulated output so far
- task.md: the full task specification (cold-readable)

## Cycle N produces:
- Process items 5-6 (scope: exactly 2 items per cycle)
- Append results to findings.json
- Update progress.json: items 1-6 complete, 7-10 remaining

## Cycle exit condition:
- progress.json shows all items complete → stop
- Otherwise → invoke cycle N+1

## Invariant: each cycle's output is usable alone.
No cycle produces "partial results that need later cycles
to make sense." If the system crashes after cycle 3,
findings.json contains valid, complete results for items 1-6.

Exercise

A document indexer that processes 10,000 PDFs into a search index. Current implementation: one function call that processes all 10,000, takes 4 hours, and if it fails at PDF 8,500 — starts over from PDF 1.

Discuss: What are the cycle primitives? What state persists between heartbeats?
What's the invariant that makes partial progress usable? How many items per cycle?

Some valid answers

A document indexer that processes 10,000 PDFs into a search index. Current implementation: one function call that processes all 10,000, takes 4 hours, and if it fails at PDF 8,500 — starts over from PDF 1.

Some valid answers

A document indexer that processes 10,000 PDFs into a search index. Current implementation: one function call that processes all 10,000, takes 4 hours, and if it fails at PDF 8,500 — starts over from PDF 1.

Some valid answers

A document indexer that processes 10,000 PDFs into a search index. Current implementation: one function call that processes all 10,000, takes 4 hours, and if it fails at PDF 8,500 — starts over from PDF 1.

Structured Communication

Metadata on messages enables routing
without reading the body.

Attention as a limited resource

Structured headers = attention routing signals.

Example: Metadata-driven triage

Example input — messages the system consumes

---
from: security-scanner
to: code-reviewer
kind: request        # requires action (vs. "report" = FYI)
priority: critical
subject: SQL injection in auth.py line 42
---
[full finding details below...]

---
from: style-checker
to: code-reviewer
kind: report         # informational, no action required
priority: low
subject: 3 formatting inconsistencies in utils.py
---
[details...]

Prompt literal — the triage instruction

Process `request` messages first. `report` messages are
informational — acknowledge but don't block on them.

Exercise

A monitoring system sends alerts to an on-call engineer. All alerts use identical formatting: subject line + body text. Last week: engineer received 47 alerts in 2 hours, triaged sequentially, and missed a critical database failure buried as alert #31.

Discuss: What metadata would enable routing without reading the body?
What are the primitives of a triageable alert? What's the cost of uniform formatting?

Some valid answers

A monitoring system sends alerts to an on-call engineer. All alerts use identical formatting: subject line + body text. Last week: engineer received 47 alerts in 2 hours, triaged sequentially, and missed a critical database failure buried as alert #31.

Some valid answers

A monitoring system sends alerts to an on-call engineer. All alerts use identical formatting: subject line + body text. Last week: engineer received 47 alerts in 2 hours, triaged sequentially, and missed a critical database failure buried as alert #31.

Some valid answers

A monitoring system sends alerts to an on-call engineer. All alerts use identical formatting: subject line + body text. Last week: engineer received 47 alerts in 2 hours, triaged sequentially, and missed a critical database failure buried as alert #31.

Write-Then-Verify

Generate and verify as distinct steps.
Never simultaneously.

Why self-checking during generation fails

A model that generates and verifies simultaneously
tends to rationalize its own output.

• Generation context biases verification judgment
• "I wrote this, so it must be right" (implicit)
• Errors become invisible from inside the generation
• Cold verification catches what hot-generation misses

Separation pattern

## Step 1: Generate (your context: the requirements only)
Produce the implementation. Don't self-critique while writing.
Just produce the best output you can.

## Step 2: Verify (your context: output + checklist only)
You are reviewing code produced by another engineer.
You did not write this.

First run the tooling — don't spend a verify pass on what it proves:
- Tests: null input, edge cases, regressions
- Type checker: return types match the interface
- Linter / static analysis: parameterized SQL, dead code

Then review only what tooling cannot catch — your real job:
- [ ] Error messages don't leak internal state
- [ ] Implementation matches the requirement's intent
- [ ] Edge cases the requirements imply but no test covers

## Step 3: If verification fails
List specific failures. Regenerate only the failing sections.
Do not regenerate passing sections — they're locked.

Exercise

An AI generates Terraform configurations based on requirements. The same AI instance reviews its output for security issues. It consistently rates its own configs as "secure" — even when they contain publicly accessible S3 buckets and security groups open to 0.0.0.0/0.

Discuss: Where's the verification bias? What structural change prevents self-rationalization?
What does cold verification look like here?

Some valid answers

An AI generates Terraform configurations based on requirements. The same AI instance reviews its output for security issues. It consistently rates its own configs as "secure" — even when they contain publicly accessible S3 buckets and security groups open to 0.0.0.0/0.

Some valid answers

An AI generates Terraform configurations based on requirements. The same AI instance reviews its output for security issues. It consistently rates its own configs as "secure" — even when they contain publicly accessible S3 buckets and security groups open to 0.0.0.0/0.

Some valid answers

An AI generates Terraform configurations based on requirements. The same AI instance reviews its output for security issues. It consistently rates its own configs as "secure" — even when they contain publicly accessible S3 buckets and security groups open to 0.0.0.0/0.

Integration Workshop

Apply all 25 techniques in a single prompt system

Workshop exercise

1. Choose your domain — a system you actually build/maintain
2. Layer it — identity / governance / task (Session 1)
3. Encode failures — how does YOUR system typically fail? (Session 2)
4. Classify constraints — enforced vs. requested (Session 3)
5. Partition authority — model owns / asks / never (Session 4)
6. Mark immutables — what must never drift? (Session 5)
7. Design the cycle — state contract per heartbeat (Session 6)

Peer review: use Symmetry Detection + Layer-Crossing Checks
from the original framework to audit each other's systems.

Original Framework

Techniques 1–10: Evaluation & Auditing

Directive Hardening

Making instructions resistant to drift,
misinterpretation, or creative undermining.

The problem

Models creatively reinterpret instructions
to match their training distribution.

Three hardening techniques prevent this drift:

1. Negative anchors
2. Boundary clarification
3. Calibration scales

Negative Anchors

Define what NOT to flag as explicitly
as what to flag.

"Flag long functions"
→ flags switch statements
→ flags data tables
→ flags config arrays

"Flag long functions"
"Do NOT flag:"
"- switch statements"
"- data declarations"
"- config arrays"

Positive-only instructions leave the boundary undefined. The model fills the gap with training priors.

Boundary Clarification

"This is X, not Y" — explicit distinctions
at ambiguity boundaries.

## Boundary clarifications

- This is a CODE REVIEW, not a style guide enforcement.
  (Don't flag formatting unless it hides a bug.)

- "Error handling" means exception flow, not validation.
  (Missing input validation is a separate category.)

- "Performance issue" requires measurable impact evidence.
  (Theoretical inefficiency without data is a NOTE, not a finding.)

Boundaries prevent category bleeding — where one instruction swallows adjacent territory.

Calibration Scales

Concrete examples at each level of a judgment scale.

## Severity calibration

critical: SQL injection, auth bypass, data exposure
  → Example: unsanitized user input in raw SQL query

high: logic errors causing incorrect output for some inputs
  → Example: off-by-one in pagination returns duplicate rows

medium: missing edge case handling, non-obvious failure modes
  → Example: no timeout on HTTP call to external service

low: code quality, naming, minor style
  → Example: variable named 'x' in a 5-line scope

Without calibration, the model's severity distribution matches its training data — not your team's.

Example: Negative anchors

## What to flag
- Functions over 50 lines with no documentation
- Public APIs that don't validate input types
- Error handling that swallows exceptions silently

## What NOT to flag (explicitly)
- Long functions that are just switch statements (inherently linear)
- Internal helper functions without docs (low reader traffic)
- Caught-and-logged exceptions (not swallowed — handled)

Without the "NOT" list, the model flags everything that
pattern-matches on surface features.

Note: "functions over 50 lines," "missing docs" are deterministic — a linter counts them. The LLM's anchors should govern judgment ("is this long function inherently linear?"), not measurements tooling already does better. See Technique 13.

Exercise

A notification system. Rules: "Send notifications for important events. Don't spam users." System sends notifications for every login, password change, and settings update. Users complain. New rule: "Only send for critical security events." Now password changes don't notify — and users miss compromised-account alerts.

Discuss: What's missing from both rule versions? What negative anchors would fix this?
What's the hardened version look like?

Some valid answers

A notification system. Rules: "Send notifications for important events. Don't spam users." System sends notifications for every login, password change, and settings update. Users complain. New rule: "Only send for critical security events." Now password changes don't notify — and users miss compromised-account alerts.

Some valid answers

A notification system. Rules: "Send notifications for important events. Don't spam users." System sends notifications for every login, password change, and settings update. Users complain. New rule: "Only send for critical security events." Now password changes don't notify — and users miss compromised-account alerts.

Some valid answers

A notification system. Rules: "Send notifications for important events. Don't spam users." System sends notifications for every login, password change, and settings update. Users complain. New rule: "Only send for critical security events." Now password changes don't notify — and users miss compromised-account alerts.

Seed Decision Trees

Pre-loading the model's reasoning path
with structured choices.

Three components of a seed tree

Without seed trees, the model's reasoning path is
determined by training distribution, not your task structure.

1. Methodology — the reasoning path
2. Stopping conditions — when to halt
3. Conditional routing — branching logic

Methodology: "Start with X → then Y → then Z"

Ordered sequence of reasoning steps.
The model follows your path instead of inventing one.

## Analysis methodology (follow this order)

1. Identify the system's core primitives (nouns that compose)
2. Map how primitives interact (dependencies, data flow)
3. For each interaction: does the interface contract hold?
4. Where contracts break: what's the operational cost?

DO NOT skip steps. DO NOT reorder. Step 3 requires step 2's output.

Ordering matters — later steps consume earlier steps' output. Explicit dependency prevents shortcuts.

Stopping Conditions

When to halt: saturation, repetition, threshold.

## Stop when:
- You've covered all public interfaces (completeness)
- You find >10 critical findings (triage-first)
- Remaining items are all severity:low (diminishing returns)
- You're repeating a finding you already noted (saturation)

## Do NOT stop because:
- "It's getting long" (length is not a stopping condition)
- "This seems thorough" (feeling ≠ completeness)
- You've reached some internal output limit

Models default to stopping when output "feels complete" — an artifact of training on human-length responses.

Conditional Routing

"If X, then Y; otherwise Z" — branching logic for the model's path.

## Routing rules

- If finding involves data loss → severity:critical, stop and report
- If finding is style-only → severity:low, batch at end
- If finding is ambiguous → include with confidence:medium
- If finding duplicates an earlier finding → merge, don't repeat

## Escalation
- If >3 critical findings: stop analysis, report immediately
- If finding contradicts the specification: flag as "spec conflict"
  and continue (don't resolve — surface for human decision)

Routing prevents flat-priority output where everything appears equally important.

Example: Seeded methodology

## Analysis methodology (follow this order)

1. Identify the system's core primitives (nouns that compose)
2. Map how primitives interact (dependencies, data flow)
3. For each interaction: does the interface contract hold?
4. Where contracts break: what's the operational cost?

## Stopping conditions
- Stop when you've covered all public interfaces
- Stop if you find >10 critical findings (triage first)
- Stop if remaining items are all severity:low

## Routing
- If finding involves data loss → severity:critical, stop and report
- If finding is style-only → severity:low, batch at end
- If uncertain → include but mark confidence:medium

Exercise

A PR review bot. Instructions: "Review this PR. Flag important issues." It produces a flat list mixing typos, style suggestions, logic errors, and security vulnerabilities — all presented equally important, in file order rather than priority order.

Discuss: What methodology would you seed? What stopping conditions prevent noise?
What routing rules separate severity tiers?

Some valid answers

A PR review bot. Instructions: "Review this PR. Flag important issues." It produces a flat list mixing typos, style suggestions, logic errors, and security vulnerabilities — all presented equally important, in file order rather than priority order.

Some valid answers

A PR review bot. Instructions: "Review this PR. Flag important issues." It produces a flat list mixing typos, style suggestions, logic errors, and security vulnerabilities — all presented equally important, in file order rather than priority order.

Some valid answers

A PR review bot. Instructions: "Review this PR. Flag important issues." It produces a flat list mixing typos, style suggestions, logic errors, and security vulnerabilities — all presented equally important, in file order rather than priority order.

Steering

Guide toward desired patterns
without over-constraining.

The constraint spectrum

• Templates with exits: "Use this format, BUT deviate when..."
• Soft targets: "Typical range: 3-7" (not "exactly 5")
• Disclosure preference: "When uncertain, include but mark it"

Example: Soft targets

## Output guidance (steering, not constraints)

Typical audits surface 3-7 findings. This is a soft target:
- Fewer is fine if the system is genuinely clean
- More is fine if genuine issues exist
- DON'T manufacture findings to hit the range
- DON'T suppress findings to stay under it

For each finding, typical length is 2-4 sentences.
Expand if the finding requires context to understand.
Contract if it's self-evident from the code snippet.

If you find yourself writing more than 10 findings,
pause and triage: are all genuinely actionable?

Exercise

A content moderation system for a developer forum. Rules: "Posts must be on-topic. Remove spam. Keep discussions professional." A post discusses using a competitor's product to solve a problem the community's product can't handle. Moderator bot flags it as "off-topic / competitive spam."

Discuss: What's a hard constraint vs. soft target here? What escape hatch is missing?
How do you steer without over-constraining?

Some valid answers

A content moderation system for a developer forum. Rules: "Posts must be on-topic. Remove spam. Keep discussions professional." A post discusses using a competitor's product to solve a problem the community's product can't handle. Moderator bot flags it as "off-topic / competitive spam."

Some valid answers

A content moderation system for a developer forum. Rules: "Posts must be on-topic. Remove spam. Keep discussions professional." A post discusses using a competitor's product to solve a problem the community's product can't handle. Moderator bot flags it as "off-topic / competitive spam."

Some valid answers

A content moderation system for a developer forum. Rules: "Posts must be on-topic. Remove spam. Keep discussions professional." A post discusses using a competitor's product to solve a problem the community's product can't handle. Moderator bot flags it as "off-topic / competitive spam."

Conceptual Anchoring

Identify and reason from system primitives,
not surface patterns.

Primitives > patterns

• Prevents hallucination: findings grounded in operational reality
• Transfers across domains: same technique for code, prose, research
• Enables composition: primitives compose; surface patterns don't

Example: Anchoring an audit

## System primitives (your anchors)

This system has 4 primitive concepts:
- **User**: has roles, belongs to organizations
- **Document**: has owner, has visibility, has versions
- **Permission**: maps (user, document, action) → allow/deny
- **Audit trail**: immutable log of permission checks

## Your job: verify that every Document operation
## checks Permission before executing.

Anchor in Permission. For each Document endpoint:
1. Does it call Permission.check() before acting?
2. Does the Permission check match the action being taken?
3. Is the result logged to Audit trail?

Findings are grounded in these primitives — not in code style,
naming conventions, or aesthetic preferences.

Exercise

A CLI tool with 8 subcommands. Each subcommand has --help text. Most follow: Synopsis (usage), Description paragraph, Options list, Examples section. Two subcommands omit Examples. One has Synopsis + Examples only (no Description).

Discuss: What are the primitives? What's a violation?
What's justified divergence?

Some valid answers

A CLI tool with 8 subcommands. Each subcommand has --help text. Most follow: Synopsis (usage), Description paragraph, Options list, Examples section. Two subcommands omit Examples. One has Synopsis + Examples only (no Description).

Some valid answers

A CLI tool with 8 subcommands. Each subcommand has --help text. Most follow: Synopsis (usage), Description paragraph, Options list, Examples section. Two subcommands omit Examples. One has Synopsis + Examples only (no Description).

Some valid answers

A CLI tool with 8 subcommands. Each subcommand has --help text. Most follow: Synopsis (usage), Description paragraph, Options list, Examples section. Two subcommands omit Examples. One has Synopsis + Examples only (no Description).

Operational Cost Framing

Evaluate by impact, not by difference.
"What breaks?" not "what's different?"

Three cost dimensions

• Operational cost: "What breaks if this persists?"
• Cognitive cost: "What mental load does this add for readers?"
• Future cost: "What maintenance trap does this create?"

Models default to noticing variation.
Cost framing forces evaluation of impact.

Reduces false positives from style differences.

Example: Cost-based severity

## Severity = cost, not deviation

CRITICAL (operational cost: system breaks)
- Missing null check on user input → crash in production
- Unvalidated redirect URL → open redirect vulnerability

HIGH (operational cost: data/security compromise)
- Hardcoded API key → secret exposure on public repo
- Missing rate limit → resource exhaustion possible

MEDIUM (cognitive cost: readers misled)
- Function name doesn't match behavior → debugging time
- Docs say X, implementation does Y → wrong assumptions

LOW (future cost: maintenance burden)
- Inconsistent naming → grep becomes unreliable
- Dead code → codebase noise, no runtime impact

NOT A FINDING (style variation, no cost)
- Tabs vs spaces (if no standard set)
- Comment style differences (if functionally equivalent)

Exercise

A shopping cart service audit flags: (1) Cart totals use floating-point math instead of integer cents. (2) "Remove item" button is labeled "Delete." (3) Cart doesn't persist across sessions. (4) Tax calculation rounds per-item instead of on the total.

Discuss: What's the operational cost of each? Which are critical vs. cosmetic?
What looks high-severity but isn't? What looks low but is actually critical?

Some valid answers

A shopping cart service audit flags: (1) Cart totals use floating-point math instead of integer cents. (2) "Remove item" button is labeled "Delete." (3) Cart doesn't persist across sessions. (4) Tax calculation rounds per-item instead of on the total.

Some valid answers

A shopping cart service audit flags: (1) Cart totals use floating-point math instead of integer cents. (2) "Remove item" button is labeled "Delete." (3) Cart doesn't persist across sessions. (4) Tax calculation rounds per-item instead of on the total.

Some valid answers

A shopping cart service audit flags: (1) Cart totals use floating-point math instead of integer cents. (2) "Remove item" button is labeled "Delete." (3) Cart doesn't persist across sessions. (4) Tax calculation rounds per-item instead of on the total.

Symmetry Detection

Notice when patterns hold almost everywhere —
then investigate the breaks.

One-offs vs. broken symmetry

"8/10 endpoints validate input. 2 don't."

That's not two outliers. That's broken symmetry.
Either the 2 have justification, or they're bugs.

• Quantify pattern adherence (not just "usually follows")
• Check for documented justification on breaks
• Assess cost of the asymmetry (back to technique 5)

Example: Symmetry audit

## Task: Identify broken symmetry in this API

For each pattern you observe:
1. How many endpoints follow it? (N/total)
2. Which endpoints break it? (list specifically)
3. For each break: is there documented justification?
4. If no justification: what's the operational cost?

## Example finding format:
Pattern: "All POST endpoints validate request body schema"
Adherence: 11/13 endpoints
Breaks: POST /legacy/import, POST /admin/bulk-update
Justification: None documented
Cost: Malformed input reaches business logic → potential crash
Severity: HIGH (broken symmetry with operational cost)

Exercise

A component library with 20 components. 17 accept a `size` prop with values "sm" | "md" | "lg". Of the remaining 3: one uses "small" | "medium" | "large", one has no size prop at all, and one accepts a numeric pixel value.

Discuss: What's the symmetry? Which breaks are justified?
What's the operational cost of each asymmetry? How would you report this?

Some valid answers

A component library with 20 components. 17 accept a `size` prop with values "sm" | "md" | "lg". Of the remaining 3: one uses "small" | "medium" | "large", one has no size prop at all, and one accepts a numeric pixel value.

Some valid answers

A component library with 20 components. 17 accept a `size` prop with values "sm" | "md" | "lg". Of the remaining 3: one uses "small" | "medium" | "large", one has no size prop at all, and one accepts a numeric pixel value.

Some valid answers

A component library with 20 components. 17 accept a `size` prop with values "sm" | "md" | "lg". Of the remaining 3: one uses "small" | "medium" | "large", one has no size prop at all, and one accepts a numeric pixel value.

Confidence Disclosure

Make uncertainty visible.
"I don't know" is valuable data.

Why disclosure beats suppression

Normalize: "When confidence is low, include but mark it."

Example: Confidence scale

## Confidence marking (required on every finding)

HIGH: You can point to specific code/evidence that confirms.
      Would defend this finding in peer review.

MEDIUM: Pattern suggests an issue but you can't confirm
        without runtime testing or broader context.
        Include — reviewer may have the missing context.

LOW: Heuristic match only. Might be a false positive.
     Include anyway — mark it. Don't suppress.
     "I noticed X but can't confirm it's a problem."

## Rule: never suppress a finding to avoid looking uncertain.
## Uncertainty disclosed > certainty faked.

Exercise

A log analyzer reports: "Definite memory leak in service-A (evidence: linear memory growth over 72 hours)." Also reports: "Possible connection pool exhaustion in service-B (evidence: 2 timeout errors in 10,000 requests over 24h)."

Discuss: What are the confidence primitives? What's the cost of treating both equally?
What if the second is suppressed entirely? What's the right disclosure?

Some valid answers

A log analyzer reports: "Definite memory leak in service-A (evidence: linear memory growth over 72 hours)." Also reports: "Possible connection pool exhaustion in service-B (evidence: 2 timeout errors in 10,000 requests over 24h)."

Some valid answers

A log analyzer reports: "Definite memory leak in service-A (evidence: linear memory growth over 72 hours)." Also reports: "Possible connection pool exhaustion in service-B (evidence: 2 timeout errors in 10,000 requests over 24h)."

Some valid answers

A log analyzer reports: "Definite memory leak in service-A (evidence: linear memory growth over 72 hours)." Also reports: "Possible connection pool exhaustion in service-B (evidence: 2 timeout errors in 10,000 requests over 24h)."

Domain-Neutral Primitives

Design prompts that work across artifact types:
code, prose, research, systems.

Abstract > specific

• Use "conceptual units" not "modules" or "paragraphs"
• Use "composition boundary" not "function interface" or "section break"
• Use "coherence" not "code correctness" or "logical flow"

Test: can your prompt audit both a CLI tool
AND a research paper without modification?

Same auditor for software, papers, component libraries, organizational docs.

Example: Domain-neutral language

## Audit framework (works across domains)

For any artifact, identify:
1. **Units**: the composable pieces (functions/paragraphs/components)
2. **Boundaries**: where units meet (interfaces/transitions/edges)
3. **Contracts**: what each boundary promises (types/claims/invariants)
4. **Coherence**: do units compose without contradiction?

## Apply to:
- Source code: units=functions, boundaries=APIs, contracts=types
- Research paper: units=sections, boundaries=transitions, contracts=claims
- Design system: units=components, boundaries=props, contracts=variants

The audit technique is identical. Only the vocabulary maps change.

Exercise

A multi-tenant SaaS audit prompt says: "Check that tenant data doesn't leak between organizations. Review database queries for proper WHERE clauses. Verify API endpoints check org_id."

Discuss: What's domain-specific language here? How would you rephrase to also audit
a document-sharing system's permission model? A component library's theme isolation?
What vocabulary transfers across all three?

Some valid answers

A multi-tenant SaaS audit prompt says: "Check that tenant data doesn't leak between organizations. Review database queries for proper WHERE clauses. Verify API endpoints check org_id."

Some valid answers

A multi-tenant SaaS audit prompt says: "Check that tenant data doesn't leak between organizations. Review database queries for proper WHERE clauses. Verify API endpoints check org_id."

Some valid answers

A multi-tenant SaaS audit prompt says: "Check that tenant data doesn't leak between organizations. Review database queries for proper WHERE clauses. Verify API endpoints check org_id."

Layer-Crossing Checks

Verify alignment across abstraction layers.
Most bugs live at boundaries.

Where integrity violations hide

Single-layer audits miss drift between layers.
Anchor in one layer, validate in another.

Boundary: Docs ↔ Code

Documentation says one thing. Implementation does another.

## Docs ↔ Code verification

For each documented feature:
1. Find the claim in documentation (README, API docs, comments)
2. Locate the implementation
3. Verify: does the implementation honor the documented behavior?

Common drift patterns:
- Docs describe v1 behavior; code has been patched to v3
- Docs promise error handling that doesn't exist
- Docs say "required" but code has a default fallback
- Feature was removed but docs still reference it

Docs ↔ Code drift is the most common and least detected. Tests verify code, not docs.

Boundary: Schema ↔ Usage

Schema defines a contract. Callers violate it silently.

## Schema ↔ Usage verification

For each schema definition:
1. Read the schema constraints (required fields, types, enums)
2. Find all call sites / consumers
3. Verify: does every caller satisfy the schema?

Red flags:
- Schema says "required" but 3 callers pass undefined
- Schema says enum ["draft","published"] but code also uses "archived"
- Schema says maxLength:100 but no truncation at input boundary
- Schema updated, but callers unchanged (version skew)

Schemas are promises. Code that bypasses the validation layer breaks promises silently.

Boundary: Claim ↔ Evidence

System makes an assertion. Evidence doesn't support it.

## Claim ↔ Evidence verification

For each system claim (logs, metrics, status pages, user-facing messages):
1. Identify the claim ("99.9% uptime", "processed successfully", "validated")
2. Trace to the evidence source
3. Verify: does the evidence actually demonstrate the claim?

Failure modes:
- "Processed" means "received" — not "completed"
- "Validated" means "parsed" — not "business-rule checked"
- "Healthy" means "responding" — not "correct"
- Metric measures attempts, claim reports "successes"

Most dangerous in LLM systems: "the model confirmed" ≠ "the answer is correct."

Example: Cross-layer checklist

Prompt literal — a verification framework

## Layer-crossing verification

For each feature, check these boundaries:

| Source layer | Target layer | Question |
|---|---|---|
| README | Implementation | Does code do what docs claim? |
| Schema | Usage | Are required fields always provided? |
| Error messages | Error handling | Do messages match actual error types? |
| API docs | Route handlers | Do params/returns match? |
| Config defaults | Runtime behavior | Does the default actually apply? |

Process: Pick source layer. Read its claims. Cross to target
layer. Verify each claim has matching implementation.
Mismatches at boundaries are findings.

Exercise

An API has an OpenAPI spec (doc layer) and Express route handlers (implementation layer). Spec says PUT /users/:id requires `{ name, email }` in body. Handler actually accepts `{ name, email, role }` — and setting role=admin works, bypassing the invitation flow.

Discuss: What layers exist here? What's the boundary violation?
What's the operational cost? What other layer-crossings would you check in this system?

Some valid answers

An API has an OpenAPI spec (doc layer) and Express route handlers (implementation layer). Spec says PUT /users/:id requires `{ name, email }` in body. Handler actually accepts `{ name, email, role }` — and setting role=admin works, bypassing the invitation flow.

Some valid answers

An API has an OpenAPI spec (doc layer) and Express route handlers (implementation layer). Spec says PUT /users/:id requires `{ name, email }` in body. Handler actually accepts `{ name, email, role }` — and setting role=admin works, bypassing the invitation flow.

Some valid answers

An API has an OpenAPI spec (doc layer) and Express route handlers (implementation layer). Spec says PUT /users/:id requires `{ name, email }` in body. Handler actually accepts `{ name, email, role }` — and setting role=admin works, bypassing the invitation flow.

Escape Hatch Design

Build flexibility into rigid templates
without losing structure.

Hard constraints + permission to break them

"Follow this template OR explain why you didn't"
>
"Follow this template" (no escape)

• Edge cases always emerge
• Models need permission to deviate when justified
• Deviation with explanation > silent rule-breaking
• Deviation with explanation > forced compliance that distorts output

Example: Template with exits

## Output format

For each finding, use:
### [SEVERITY] Finding title
**Location:** file:line
**Evidence:** [code snippet or quote]
**Impact:** [operational cost]
**Fix:** [specific remediation]

## Escape hatches
- If finding spans multiple files: use "Location: [list]"
  instead of single file:line
- If evidence requires >10 lines: summarize + reference
  the full span ("see lines 42-89")
- If fix is non-obvious: replace "Fix:" with "Options:"
  and list 2-3 alternatives with tradeoffs
- If you can't determine severity: use "UNCERTAIN" and explain
  what information would resolve it

Exercise

A form builder requires every field to have: a label, a validation rule, a help text tooltip, and an error message. An engineer adds a "spacer" element (pure layout, takes no input). System rejects it — no validation rule, no error message.

Discuss: What are the template primitives? What's the violation?
What escape hatch accommodates the spacer without weakening the contract for real input fields?

Some valid answers

A form builder requires every field to have: a label, a validation rule, a help text tooltip, and an error message. An engineer adds a "spacer" element (pure layout, takes no input). System rejects it — no validation rule, no error message.

Some valid answers

A form builder requires every field to have: a label, a validation rule, a help text tooltip, and an error message. An engineer adds a "spacer" element (pure layout, takes no input). System rejects it — no validation rule, no error message.

Some valid answers

A form builder requires every field to have: a label, a validation rule, a help text tooltip, and an error message. An engineer adds a "spacer" element (pure layout, takes no input). System rejects it — no validation rule, no error message.

The Meta-Pattern

Every technique in this seminar is an instance of one principle:

Make the implicit explicit.
Make the structural visible.
Make the enforced distinguishable from the requested.

Prompts are infrastructure. Engineer them like infrastructure.

25 Techniques — Quick Reference