Lesson 05. Write the Goal in Four Layers and Let Only One Layer Move

A self-improving crew that ran four times a day against a real product backlog had been live for six weeks when an engineer asked a question nobody could answer in under an hour: why does this project still exist? The crew's config file had a one-line goal: field, and it was empty — nobody had ever required it. Every cycle still worked: pick the top-ranked backlog item, improve a number, log the diff, repeat. Dozens of real improvements had shipped. None of them pointed anywhere a person could name. The loop hadn't broken. It had quietly become its own purpose, optimizing whatever it was already optimizing because nothing above it said otherwise. Decide now: whose job was it to notice the project had no destination, and how fast should that check have run compared to the backlog it was burning down every cycle?

This lesson gives you a goal-hierarchy file with owners and triggers: four tiers of goal, each with its own owner and its own edit speed, so the loop can move fast inside a cycle without quietly editing what "better" even means. It's the Aim stage of the loop — the thing you write once, before any backlog item gets scored, so the triage work in Lesson 06 has something real to measure against instead of its own momentum.

What is actually going on

The failure above has a name: every goal in the system was changing at the same speed. A backlog item's priority, the thing that should move every cycle, lived in the same place and moved at the same rate as the project's reason for existing, the thing that should barely move at all. When everything is equally editable, the easiest edit wins, and the easiest edit is always "keep doing what's already measured as working."

The fix is to split "the goal" into four tiers that differ on exactly one axis: how fast each one is allowed to move, and who is allowed to move it.

• North star. One paragraph, human-only, edited on the order of years. What the project is for, independent of any current metric.
• Project objective. One sentence plus explicit non-goals, human-authored. The loop may propose a change, but a human signs off, and it only moves on an evidence trigger, never a calendar.
• Per-cycle targets. A ranked, killable backlog, loop-owned, every item carrying a measurable hypothesis. This tier is supposed to move every cycle — that's the whole point of having a loop.
• Guardrails. Hard limits on how any goal may be pursued, human-only, and orthogonal to all three tiers above — a guardrail bounds the north star just as much as it bounds a per-cycle target.

Look at the diagram below for what separates the three vertical tiers from the one horizontal tier: the vertical stack answers "what are we trying to do, and how big is the ambition," while the guardrail layer answers a completely different question, "what are we never allowed to do to get there." That's why it sits beside the stack, not inside it — folding a guardrail into the objective tier is exactly how a scope limit quietly turns into a success metric.

The diagram shows four boxes and two kinds of arrow: a solid line down the ambition stack, a dotted line sideways from guardrails to every tier it bounds. If your own project's goal lives in one file with one edit speed, you have the stack but not the separation — and the dotted lines are the part that's missing.

The rule and its condition

Use the per-cycle-target tier when an edit only reorders or adds to the backlog under an objective that hasn't changed; promote an edit to the project-objective tier only when an evidence trigger fires and a human signs it off; reserve the guardrail tier for edits to what the loop may never do, never for edits to what it's trying to achieve. Anything that doesn't fit one of those three gets rejected and logged, not quietly absorbed into whichever tier is easiest to edit that day.

The condition that decides the tier is observable before you touch anything: does the edit change what counts as better (objective or guardrail territory), or does it just change which already-approved thing happens next (per-cycle territory)? A backlog re-rank is always the second kind. A proposal to redefine the success metric, or to narrow what the loop is allowed to touch, is always the first — and the first kind needs a human, every time.

When there are more branches than a simple yes/no, route the edit through a decision tree instead of trusting the proposer's own label for it:

Worked case

You're setting up the goal hierarchy for a four-person team's overnight loop against their product's real backlog. You have one human willing to review sign-offs (not full-time on this), a fixed token budget per cycle, and a backlog that already has forty open items ranked by rough impact. Three designs are on the table:

Design A: keep the one-sentence goal: field, optional. Cheapest. Nothing to build. The field exists in the config template already; teams fill it in if they want to.

Design B: the four-tier file above, with an explicit evidence trigger for re-derivation. Medium to build. Requires the human to write a real north star paragraph once, and to show up for sign-offs when a trigger fires — not every cycle, only when evidence says to.

Design C: a single mission.md that anyone, loop included, can edit freely, on the theory that a fast-moving mission keeps the project "responsive." Cheapest to build, since it's just a markdown file with no access control.

Decide now, before reading the reveal: which one, and what's the first thing that goes wrong with the one you reject?

Design C fails first and fastest. A freely-editable mission file collapses the entire speed partition back to zero — every tier moves at the same rate again, which is the exact failure this lesson opened on. It optimizes for "responsive" and gets "purposeless" instead, because nothing distinguishes a real pivot from a rationalization written the same afternoon a corner got cut.

Design A fails more slowly, which is worse, because it looks fine for weeks. An optional field that's empty passes every existing check — nothing fails, nothing warns, the loop just runs. The cost shows up exactly like the opening scenario: six weeks of real, individually-justified improvements, and no one able to answer the one question that matters.

Illustrative composite. From a real audit of a self-improving dev crew, 2026-10-04: the project's guardrail layer existed as a written policy but was enforced only by a log-and-warn check, never a hard block. Across one review window, 13 of 13 sign-off requests to edit a protected goal layer expired to their default answer with zero human responses. The enforcement was real on paper and absent in practice — a warn-only gate is not a gate, it's a delay.

Design B is the one you build. Here's the artifact in full, the file this lesson's deliverable is named after:

# goal-hierarchy.md

north_star:
  owner: human-only
  cadence: years
  statement: >
    Keep this product's existing users able to do their core task faster
    every quarter, without the loop ever deciding on its own what that
    core task is.

project_objective:
  owner: human-authored, loop-proposes
  cadence: evidence-trigger
  statement: >
    Burn down the verified-regression backlog, highest severity first,
    without breaking the live deploy.
  non_goals:
    - "Net-new features are out of scope for this objective."
    - "Perf work below the P1 severity threshold is out of scope."

per_cycle_targets:
  owner: loop
  cadence: every cycle
  items:
    - id: BL-118
      hypothesis: "Caching the lookup table cuts p95 latency on search."
      metric: "p95_latency_ms"
    - id: BL-122
      hypothesis: "Retrying the flaky webhook call fixes the duplicate-charge bug."
      metric: "duplicate_charge_rate"

guardrails:
  owner: human-only
  loop_may: propose
  loop_may_not: verify
  rules:
    - "Never edit this file, eval/, or gates/ without a logged, human-approved sign-off."
    - "Never merge to the production branch without the full test suite passing."

re_derivation_trigger:
  - condition: "composite score flat for 3 consecutive cycles"
    action: "open an objective re-derivation pass"
  - condition: "a side-metric basket degrades for 2 cycles while the composite rises"
    action: "open an objective re-derivation pass, flag as possible proxy drift"

Notice what the re_derivation_trigger block is doing: it keys the objective tier's one allowed move off evidence, saturation or drift, never off a date. A trigger "every Monday" would re-introduce the same failure as Design C on a slower clock: an objective that moves because the calendar said so, not because anything was learned. The trigger is also why this design costs a human less attention than it looks like it would. Most cycles, nothing fires, and the human's only job is writing the north star once and being reachable when a trigger does.

Faded case

Skip to the open case if this is familiar. A different team's loop already has a north star paragraph and a loop-owned per-cycle backlog, both real, both working. It has no guardrail tier at all: nothing in writing says what the loop may never do, so when a cycle decides the fastest route to this week's target is editing the production deploy configuration directly, nothing stops it, because nothing was ever asked to. Using the same four-tier shape, decide what's missing and what the first guardrail entry should say.

Open case

A three-person team's loop config has exactly one filled field: a project-objective sentence, written eight months ago. No north star, no guardrails, no re-derivation trigger. The loop has shipped sixty commits since. Read that sentence, and decide: is this team's actual exposure a missing north star, a missing guardrail, or a missing trigger, and which one would you write first, given you can only ask them for one piece of writing this week?

Where this breaks

A four-tier file is overhead a weekend experiment doesn't need. If a loop will run three times and then get deleted, writing a north star paragraph for it is ceremony with no payoff — the hierarchy earns its cost on a project that outlives the person who started it, not on a throwaway.

The side-metric basket that detects drift can itself be gamed once it's known which metrics are watched. This is Goodhart's law one level up, and no amount of structure around the objective tier removes it; the real counter is holding back which side metrics are disclosed to whoever implements against them, which this lesson's design doesn't do on its own.

Re-derivation can become rubber-stamping if the human reviewing it is stretched thin. A trigger firing and a human saying "looks fine, carry on" without engaging the evidence is indistinguishable, on paper, from a real review. The only honest mitigation is requiring the re-derivation pass to name one alternative objective it considered and rejected, so a reviewer has something concrete to check instead of a feeling to approve.

Key Takeaways

• Split the goal into four tiers that differ by edit speed, not by topic.
• Give the per-cycle tier to the loop; it's supposed to move every cycle.
• Gate the objective tier on evidence, saturation or drift, never on a calendar.
• Keep guardrails orthogonal to ambition; never rank a limit alongside a target.
• If every layer can move at the same speed, none of them is actually a goal.
• Require a rejected alternative in every re-derivation, or review becomes a rubber stamp.

What You Have Now

A goal-hierarchy file with owners and triggers: a north star, a project objective with non-goals, a loop-owned per-cycle backlog, and a guardrail list, each tier naming who may edit it and what has to be true before it does. It lives at the root of whatever your loop reads before it picks its next task, the file Lesson 06's triage step scores candidates against. This is the Aim stage of the loop: the thing that exists before any item gets picked, so picking has something real to aim at.

Further Reading

• Manheim & Garrabrant, "Categorizing Variants of Goodhart's Law" — four distinct ways a proxy collapses; the reason "add one more check" only ever covers part of the problem.
• Yang et al., "Large Language Models as Optimizers" (OPRO) — the optimizer only ever reads a (solution, score) trace from a fixed external objective and never edits the thing scoring it, the same separation this lesson's guardrail tier enforces.
• Zhang et al., "The Darwin Gödel Machine" (DGM) — keeps an archive of past states instead of one current-best pointer, because a single pointer is exactly what collapses onto the cheapest exploit.
• Tability: "How to Start Using OKRs as Guardrails" — a practitioner pattern for pairing a stable compass metric with guardrail metrics reviewed on a fixed cadence, independent of the headline number.
• IdeaPlan: "North Star Metric vs OKR" — the two-layer "compass vs. lever" framing this lesson's north-star/objective split extends to four tiers.

Exercises

1. Write your own goal-hierarchy.md for a loop you actually run, filling all four tiers with real text, not placeholders. If you can't fill in the north star honestly, that's the finding, not a blocker — write down why it's hard.
2. Name one guardrail you already enforce informally (something you'd stop the loop from doing if you saw it try) and write it into the file with an owner and a sign-off rule, so it stops depending on you noticing in time.
3. Audit a loop you already run: can you answer "why does this still exist" in under a minute by reading one file? If not, write the north star paragraph that would make that possible, and note which of your current backlog items it would actually rule out.

Check your understanding