The three layers

Once a loop works, the next loop tends to sit on top of it: one loop's pass launching another loop's entire run. Three layers are enough to describe the stacks you'll actually meet, and each is named by one thing — what varies between its passes.

Task, goal, steering

Task loop — the attempt varies. The task is fixed: make this test pass, migrate this file, answer this question with sources. Each pass is another attempt at the same task, informed by what earlier attempts learned. Attempts vary; the task doesn't.

Goal loop — the task varies. The goal is fixed: keep the test suite green, keep dependencies current, keep the docs matching the code. Each pass surveys the goal, picks the next task worth doing, and typically launches a task-loop run to do it. Tasks vary; the goal doesn't.

Steering loop — the goal varies. Each pass steps back and asks whether the goals themselves are still the right ones — retiring stale ones, adding new ones, reweighting the rest against whatever mandate the loop steers by. Goals vary; the mandate doesn't.

The nesting law from the vocabulary lesson applies here: a goal-loop pass typically contains a task-loop run. And the caution applies too — a steering pass may launch several goal-loop runs and review them asynchronously as they finish. The layers stack; they don't have to stack neatly.

One boundary carries over from the first lesson: no layer name below the loop rung. Task loop, goal loop, and steering loop each require the full definition — repeated pass, carried state, explicit check, stop rule, a harness that owns repetition. A workflow that assigns tasks is not a goal loop. A dashboard where someone re-prioritizes weekly is not a steering loop. Those are fine things; they just have their own names.

The hold rule

Layer names are claims, and claims need evidence:

Don't claim a layer without a pass log at that layer.

The sharpest case is the top. Don't call something a steering loop unless you can produce a steering-loop pass log — dated passes in which the goal set was reviewed against an explicit check and changed or deliberately held, each with a recorded verdict. If what actually happens is that a person adjusts the goals whenever it occurs to them, you have goal loops plus a thoughtful human. That's a genuinely good setup — call it what it is.

The same bar applies one layer down: no goal-loop claim without a log of passes choosing tasks against a fixed goal. The pass log is the difference between describing your system and describing your ambition.

The induction rule

Only stack verified loops. Trust climbs bottom-up.

A goal loop is only as trustworthy as the task loops it launches. If task-loop runs end honestly — done means the check passed, blocked means a real blocker, exhausted means a real budget — then the goal layer inherits records it can act on. If they don't, the goal loop compounds the noise: it schedules new work based on verdicts that mean nothing.

So the order is fixed. Verify task loops by reading their runs — that's what the pass log is for. Only then build a goal loop over them, and verify it the same way before anyone breathes the word steering. There's no shortcut where a clever top layer compensates for an unverified bottom one; stacking multiplies whatever reliability, or unreliability, the bottom has.

Honestly labeled, most working systems today are task loops, with goal loops appearing exactly where task loops have earned it. That's not a confession. That's the induction rule doing its job.

Do this next

If you have a task loop whose runs end honestly, you've earned the next layer: use the Quick Start to package the next run.