Skip to main content

Loop Registry

One loop is a discipline. Ten loops are a system — and a system needs an inventory, or loops silently stop running and nobody notices until the damage compounds.

The Entry Contract​

The registry keeps one machine-readable entry per loop:

  • Setpoint — what the loop holds or raises. A loop without a declared setpoint is a ritual.
  • Gauge — the one command or check that reads the loop's health. If reading the loop takes judgment, it will not get read.
  • Cadence — when the gauge is read: per edit, at session start, at job close, weekly. Unread gauges are theater.
  • Owner — which team, tool, or system answers when the loop goes red.
  • Kill signal — the named condition under which the loop is ceremony and gets deleted. Every registered loop carries its own death test.

Status Read​

The registry earns its place only through one command that walks every entry, runs each gauge, and reports green, amber, or red per loop — read at session start and at job close.

The status read is a gauge, not a gate: red loops feed the controller that decides the correction; they never block by themselves. A loop with no reader wired reports itself as unmeasured — visible debt instead of silent green.

How To Apply​

  1. Inventory the loops you already run — including the ones enforced by habit rather than tooling.
  2. Write one registry entry per loop: setpoint, gauge, cadence, owner, kill signal. If a field cannot be filled, the loop is not yet real.
  3. Wire the single status read into the moments you already have: session start and job close. Do not invent a new ritual to read it.
  4. Verify the gauge can go red: trip one loop deliberately and check the status read reports it. A read that cannot fail is decoration.
  5. On a fixed review cadence, test each kill signal against reality and delete the loops that meet theirs.

Failure Modes​

  • Silent loop death — a loop that stopped being read keeps its reputation. The status read makes absence visible.
  • Registry as shelf — entries accumulate that nobody acts on. The kill signal plus a stop rule ("a loop nobody reads for a month gets deleted") keeps the registry a working instrument, not a museum.

Inner Meets Outer​

Inner loops (engineering, testing, agent runs) and outer loops (customer demand versus fulfillment) belong in the same registry with a tier marker. The whole point is reading both on one surface, so an outer-loop miss can be traced to the inner loop that should have caught it — demand signals and delivery health stop living in separate reports.

Context​

  • depends-on Feedback Loops — The three loop types define what an entry is registering
  • pairs-with Virtuous Feedback Loop — VVFL is the per-loop discipline; the registry is the many-loop inventory
  • applies-to Open Knowledge Format — A registry is metadata that must earn navigation value, same as any structured surface
  • proved-by Reality Scoreboard — A registry claims nothing; its status read is the visible proof surface

Questions​

Which of your loops would report unmeasured today — and is that debt visible anywhere?

  • What cadence is short enough to catch loop drift but long enough that the status read stays cheap?
  • Who owns an outer-tier loop when fulfillment misses trace back to an inner loop another team runs?
  • Which registered loop has gone longest without its kill signal being tested against reality?