The Goldilocks Zone

An instruction can be too brittle or too vague. Both fail. The altitude in between is where a rule gets followed on inputs you never saw.

Why this, for you: the first thing you decide about any rule is not what it says — it's how high it sits. Get the altitude wrong and the rule breaks on the first edge case or constrains nothing at all. Every later lesson assumes you can pick the right altitude first.

This course is about one thing: writing instructions that actually get followed. Not clever prompts — compliant ones. We start at the most basic lever, the one you set before you write a single word of the rule: its level of abstraction.

1 Two ways to miss

Every instruction sits at an altitude — from high-level principle down to case-by-case lookup table. There are two symmetric failure modes, and most weak prompts land in one of them.

Too brittle enumerates cases — it works on what you anticipated and breaks on everything else. Too vague ("be helpful, accurate, concise") gives no real constraint — any output satisfies it, so the model falls back to its pre-training defaults.

Brittle prompts grow without bound: each new edge case needs another rule, and the list marches straight toward the compliance ceiling (Lesson 4). Vague prompts never constrained anything to begin with.

2 The right altitude generalises

A well-calibrated instruction tells the agent how to reason, not what to decide for each case. That produces behaviour that survives inputs the author never imagined.

Too brittle	Right altitude
"Never edit files in `/src/auth/`"	"Treat auth code as high-risk; understand the session and token impact before editing"
"Always add a test for every function"	"Business-logic changes need test coverage; types, formatting, comments do not"

The right-altitude versions activate knowledge the model already has — "auth is high-risk" pulls in session and token reasoning that would take a dozen enumerated rules to approximate. The brittle versions break the moment an edge case appears that the author didn't list.

The test: introduce an edge case the prompt didn't anticipate. A good-altitude prompt degrades gracefully — the agent applies the nearest heuristic. A brittle one falls through to vague defaults.

3 Altitude varies by section

You don't pick one altitude for the whole prompt. Anthropic's context-engineering guide recommends organising a system prompt into sections, each at its own level — and mixing altitudes within a section produces inconsistency.

Section	Altitude
Background — role, scope	High — principles and context
Instructions — how to behave	Medium — heuristics
Tool guidance — when/how to call	Low — precise constraints
Output format — structure	Precise — exact requirements

When to drop the altitude on purpose

Heuristics are the wrong call for hard boundaries. For security rules, fixed-schema extraction (FHIR, EDI), or low-capability models that pattern-match rather than generalise, enumerate explicitly. "Never log values from the credentials object" closes a gap that "treat sensitive data carefully" leaves open.

↪ Your win: pick the altitude before you write the rule

Aim for "how to reason," not "what to decide" — heuristics generalise; lookup tables break.
Run the edge-case test — if one new rule needs three more to patch its edges, raise the altitude.
Match altitude to section — background high, tool guidance precise; don't mix within a section.
Drop low for hard boundaries — security, fixed schemas, weak models want explicit enumeration.

Retrieval practice — recall, don't peek

Question 1A "too vague" instruction fails because…

Question 2The right altitude tells the agent…

Question 3The practical test for altitude is to…

Question 4Which section should sit at the lowest, most precise altitude?

Question 5A heuristic is the wrong choice when the rule guards…

Ask me anything. Want to see one of your own rules re-pitched to the right altitude, or how to split a single section that's mixing principle and precise constraints? Next in Part 1: Say What To Do — instruction polarity and the power of negative space.