A loop never trusts that an operation succeeded until the responsible loop confirms it by emitting a completion packet. The UI does not show "Order Confirmed" when the user taps Submit — it shows it when the Vault emits ORDER_CREATED. The difference is the difference between hope and proof.

The echo packet can carry metadata about the confirmation — persisted: true vs. persisted: buffered — so downstream loops and the UI know the real status. The Workflow Loop is built entirely on Echoes: emit a step request, wait for the echo, then proceed.

Every time a loop requests an action from another loop. Every Vault write. Every external service call. Every workflow step. If the action matters, wait for the echo. If you are tempted to show success before the echo arrives, you are showing hope, not proof.

Every packet carries a liveness indicator. marker: 'live' is real data. marker: 'empty' is a deliberate null signal — "I looked and there is nothing here." marker: 'tombstone' is a deletion notice — "this record existed and was deliberately removed."

The distinction matters because "no data returned" is ambiguous (query failed? genuinely empty?), while a marked empty response is unambiguous. Pull requests must always return a marked packet, never silence.

Every pull response. Every Vault read. Any situation where "no result" is a valid, meaningful answer that downstream loops need to distinguish from "the operation failed." If a customer lookup returns nothing, the downstream loop needs to know: did the customer not exist (empty), was the record deleted (tombstone), or did the database fail (error)?

A Filter Loop that receives a sparse packet (just an ID), pulls full data from a Vault, and attaches it to the packet before passing it along. The enriched packet now carries everything downstream loops need without them having to make their own Vault pulls.

When a Working Loop receives an intake that contains just a reference (a customer ID, an order ID) and downstream Compute or Filter Loops need the full record to do their work. Rather than every downstream loop independently pulling the same data, one Hydration Filter enriches the packet once.

Chaining Filter Loops on the bus. Packet enters Filter A, passes or rejects. Passes go to Filter B. Passes go to Filter C. Each filter is independent, has its own contract, and can be added or removed without changing the others. The sequence is defined in the routing table, not in the filters. Adding a new filter to the cascade means updating the routing table — no existing code changes.

When incoming data needs multiple independent checks or transformations: validation, then authorization, then hydration, then rate-checking. Each step is a separate concern. The Cascade is the composition mechanism — you build the pipeline by composing independent filters, not by building one monolithic filter that does everything.

A Compute Loop subscribes to change events from multiple Vaults and maintains a derived, denormalized view. When the Order Vault emits ORDER_UPDATED, the Projection Loop pulls related customer, status, and media data, assembles the complete view, and emits PROJECTION_UPDATED. The Presentation Loop subscribes to the projection, not to the individual Vaults — one subscription, one packet, all the data needed to render.

The projection is explicitly a derived cache, not a source of truth. It can be rebuilt from the Vaults at any time.

When the Presentation Loop needs data from multiple Vaults to render a view. Rather than the UI making five separate pull requests and assembling the data itself, the Projection Loop does the assembly once and emits a complete view packet. Also useful when multiple Compute Loops need the same assembled data — they all subscribe to the projection rather than each assembling independently.

A buffering mechanism between a loop's output and the bus. The loop produces output faster than the bus can carry it. The bridge smooths the flow. Three overflow strategies, declared in the loop's spec: overwrite (latest wins, like the L21 PM bridge), queue (FIFO buffer), backpressure (the loop pauses until the bridge drains).

When a loop produces bursts of output that could overwhelm the bus or downstream consumers. Common with Inlet-pattern Working Loops receiving high-frequency streams (GPS positions, sensor data), or Compute Loops processing batch results. The strategy depends on the data semantics: position updates use overwrite (only the latest matters), order processing uses queue (every order matters), and payment processing uses backpressure (never lose a payment, never process faster than confirmation).

The data-scrubbing half of a loop that adopts an external dependency speaking a foreign data model. The Translator receives raw external data, validates it against the external provider's schema, maps it to the internal packet contract, and emits clean packets that are indistinguishable from any other packet on the bus. The translation logic is isolated inside the loop's closure — no other loop knows or cares that the data originated from a foreign system.

The Dependency Gate handles what happens when the external system is unreachable. The Translator handles what happens when it responds.

Every loop that talks to an adopted dependency: payment processors, auth providers, notification services, external APIs. The external system speaks its own language (Stripe webhook format, Supabase auth token structure, Twilio response shape). The Translator converts that language into clean internal packets before the data touches the bus.

Operating on multiple records atomically. A Workflow pipeline where the first step is a bulk pull request and subsequent steps operate on the entire result set. Vault Loops support batch insert, batch update, and batch archive as declared capabilities. The read-and-consume variant (fetch records and mark them as in-progress atomically) is how retry queues work — the Signal Loop fetches pending notifications and claims them in one operation, so no other instance re-sends them.

Any operation that needs to process a set of records together: sending all pending notifications, archiving all completed orders older than 90 days, reconciling all transactions from yesterday, downsampling a batch of sensor readings. Also the foundation of the read-and-consume pattern for work queues.

A reliability pattern that makes Vault writes and their corresponding bus events atomic. The Vault Loop writes the business record and an outbox entry in the same database transaction. A separate sweep reads the outbox and emits to the bus. The outbox entry is deleted after the emit is confirmed. If the process crashes between the write and the emit, the outbox entry survives and the sweep picks it up on restart. No event is ever lost.

Without the Outbox, a Vault Loop that writes to the database and then emits an echo packet has a failure window: if the process crashes between the write and the emit, the record exists but no downstream loop ever learns about it.

Every Vault Loop where the echo matters for downstream processing. If a record is written but the ORDER_CREATED event is lost, the Projection never updates, the notification never sends, the analytics never count it. For business-critical data (orders, payments, customer records), the Outbox eliminates the failure window.

When a Compute Loop produces a result, it also produces diagnostic flags alongside the primary payload. Flags are metadata that describe properties of the result: loyaltyDiscountApplied: true, priceExceedsAverage: true, weightInTopDecile: true. Flags travel in the packet. Any downstream loop can read them. The producing loop doesn't know who reads the flags.

When a computation produces information that downstream loops might want to act on but that isn't part of the core result. The Pricing Engine knows the loyalty discount was applied — the UI wants to display that, the Audit Trail wants to log it, the Sentinel wants to track it. Rather than each downstream loop re-deriving the information, the Flag carries it.

A loop holds transient working state during a single operation — running totals during a reconciliation batch, intermediate values during a price calculation. Scratch state is never persisted to a Vault, never exposed on the bus, and is cleared when the transaction completes. This is a declared exception to the Two-Place Rule.

When a computation needs intermediate values that have no meaning outside the current operation. A reconciliation loop summing a batch of transactions. A pricing engine tracking discount tiers across line items. An aggregation loop computing averages. The intermediate values are meaningless if the operation fails — they'd be recomputed from inputs on retry.

A Filter Loop that modifies specific fields within declared bounds. A weight normalizer that caps at a safety maximum. A price floor that ensures no order goes below a minimum. A date normalizer that rounds timestamps. The key distinction from a Compute Loop: a Clamp enforces bounds, not business logic.

When data can arrive with values outside an acceptable range and the correct behavior is to clip them rather than reject them. A weight entry of 99,999 lbs is clearly a typo — clamp to the declared maximum. A negative price is impossible — clamp to zero. Distinct from validation (which rejects bad data). A Clamp fixes bad data within declared limits.

A Filter Loop that matches a condition and adds metadata to the packet without removing it from the pipeline. Not the same as Hydration (which pulls external data). The Stamp adds information derived from the packet itself: "this order is above average weight," "this customer is VIP tier," "this order was entered during the Tuesday rush." Stamps are additive — they do not modify existing fields, they add new ones.

When downstream loops or the Presentation Loop need to know something about a packet that can be derived from its contents but shouldn't be re-derived by every consumer. A VIP flag on a customer order. A "bulk" tag on a large order. A "rush hour" annotation on an intake. The Stamp computes it once and carries it forward.

Cascade filter order is a routing concern, not a filter concern. The individual filters do not change. The routing table determines the sequence. Want authorization before validation? Change the routing. Want sanitization before auth? Insert a new step. The filters are independent modules — the routing table is the composition layer.

When you need to change the order of filter processing without modifying any filter code. During development: "we realized auth should happen before validation." In production: "we need to insert a rate limiter before everything else." Because each filter is independent and the cascade is defined by routing, reordering is a routing table change — zero code changes.

Every loop maintains counters — packets processed, errors encountered, average processing time, specific event counts. These feed health packets for the Observatory. The L21 insight: triggers are configurable. Not just "packets processed" but "orders above $300" or "cancellations from repeat customers." Counter triggers are declared as conditions in the Config Vault, updateable at runtime.

Every loop needs counters for health monitoring. Use configurable counters when the Operator needs visibility into specific business conditions that may change over time — tracking orders above a threshold, monitoring cancellation rates by customer tier, counting API calls by provider. The Sentinel pattern is built on top of Counter infrastructure.

One event triggers multiple independent subscribers. When an ORDER_CREATED packet fires, the inventory loop, the notification loop, the analytics loop, and the projection loop all receive it independently. None knows about the others. None depends on the others. The routing table is the fanout declaration — each subscriber is a separate entry.

Any time a single event is relevant to multiple independent consumers. Order creation triggers inventory update, customer notification, analytics tracking, and UI update — all independently. A status change triggers parent evaluation, audit logging, and notification. The Fanout is implicit in the bus model but worth naming as a conscious design decision because adding a new subscriber is a routing table entry, not a code change.

A Filter Loop that coalesces rapid-fire events, forwarding only the last event after a declared quiet period. A user types in a search field; you don't fire a query on every keystroke — you wait until they pause and then forward the final input. A status field gets updated three times in two seconds; downstream loops only need the final value.

When the same event fires rapidly and downstream consumers only need the final value, not every intermediate state. Search-as-you-type. Slider adjustments. Status fields that bounce through intermediate states before settling. Config changes that trigger rebuilds — debounce so only the final config fires the rebuild. Distinct from Bridge (which manages throughput at the transport level). Debounce manages event frequency at the semantic level.

Extends pipeline specs to support parallel step groups. The Workflow Loop dispatches all steps in a group simultaneously, waits for completion, then proceeds with merged results. merge: 'all' waits for every branch. merge: 'any' proceeds on the first response (useful for redundant fallback paths). onBranchFail: 'abort' kills the group. onBranchFail: 'skip' lets surviving branches complete.

When multiple independent operations can run concurrently: compute price while checking inventory while verifying payment method. When you need redundant paths: try primary API, try fallback API, use whichever responds first. When the total latency of sequential steps is unacceptable but the steps are independent.

A Workflow pattern for hierarchical state propagation. When a child record changes state, the pipeline evaluates whether the parent should also change. Two pipeline spec features enable this: conditional steps (condition field — execute only if prior results satisfy a predicate) and recursive pipelines (recursion block with maxDepth guard).

When records have parent-child relationships and state changes should propagate through the hierarchy. All tasks in a project are done → project status should change to done. A parent record is archived → all children should be archived. An order's line items all ship → order status should change to shipped. Works both upward (child completes → parent evaluates) and downward (parent archived → children archived).

A Filter Loop that subscribes to the archive buffer (or to live traffic via passive observation) and applies pattern detection over a sliding window. Is the cancellation rate unusually high? More than five LOOP_ERROR events in an hour? One operator creating orders at triple the normal rate? The Sentinel emits ANOMALY_DETECTED on the Signal Bus. It is a watchdog, not a gatekeeper — it does not block traffic.

When you need to detect patterns that emerge over time, not individual bad values. A single error is handled by the Loop Recovery Protocol. Five errors in a row from the same loop is an anomaly worth investigating. A sudden spike in cancellations. An operator account with unusual activity. The Sentinel watches trends; the Counter provides the data; the Operator Alert loop delivers the notification.

The Observatory (or Operator Alert loop) maintains a table of expected periodic events and their tolerance windows. If the daily reconciliation usually runs at 11pm and it is 11:05 with no RECONCILE_REQUEST packet, the Clock may be dead or the schedule table failed to load. A MISSING_EVENT alert fires. Most monitoring alerts on presence (an error occurred). This alerts on absence (an expected event did not occur).

When the system has expected periodic events — scheduled jobs, heartbeats, health checks — and the absence of those events is itself a problem. The Clock should emit heartbeats every 30 seconds. The daily reconciliation should run at 11pm. The health check should fire every 5 minutes. If any of these stop happening, something is broken — and no error event will be emitted because the thing that would emit the event is the thing that's broken.

The Transit Gate's archive buffer stores recent bus traffic. The Replay pattern reads the buffer and re-emits packets in order — either to the live system (reprocess a failed batch) or to a test harness (reproduce a bug). Operator reports: "the price was wrong on the 3pm order." Pull the archive buffer, find the COMPUTE_PRICE packet, inspect its inputs, replay it through the Pricing Engine in isolation. No guessing. The exact packets are in the buffer.

Post-incident debugging: what happened, exactly, with the exact data? Reprocessing a failed batch after fixing the bug. Regression testing: replay yesterday's traffic through today's code and compare outputs. Any situation where you need to answer "what exactly happened" with certainty rather than reconstruction.

A dedicated holding area for items that have exhausted all processing attempts. When a Signal Loop fails to send a notification after all retries, when a workflow step fails and the Operator resolves the escalation with "skip it," when a packet fails contract validation repeatedly — where does the failed item go? The Dead Letter queue holds it. It is not discarded. It is not retried automatically. It waits for the Operator to investigate and decide: fix and reprocess, or discard deliberately.

Any constellation with Signal Loops that deliver to external services (notifications, webhooks, email). Any constellation with Batch operations where partial failure is possible. Any operation where the cost of silently dropping a failed item is unacceptable but the cost of indefinite retries is also unacceptable. The Dead Letter queue is the third option between "retry forever" and "silently lose it."

A recognized sub-pattern of the Working Loop for continuous external data streams — WebSocket, Server-Sent Events, MQTT, or polling intervals on REST endpoints. Not a new loop type. It is a Working Loop with additional infrastructure for stream management: connection lifecycle, back-pressure handling, and stream health telemetry.

When the constellation receives continuous data from an external source: GPS fleet tracking, market data feeds, IoT sensor streams, real-time chat messages, live sports scores. Any data source that pushes to the constellation rather than waiting to be pulled.

A two-loop pattern for producing formatted output. A Compute Loop takes business data and produces formatted content (HTML template populated with order data, a PDF layout, a printable tag). A Signal Loop handles the delivery channel — print, download, email attachment. The Compute Loop produces; the Signal Loop delivers. Neither crosses into the other's responsibility.

When the application needs to produce formatted output: receipts, reports, printable labels, export files, email bodies. The formatting logic (how to lay out an order receipt) is a Compute concern. The delivery logic (how to send it as an email attachment) is a Signal concern. Separating them means adding a new delivery channel requires only a new Signal Loop subscription, not changes to formatting logic.

A point-in-time frozen copy of a Vault's state for reporting, backup, or migration. Different from a Projection (which is a live derived view that updates continuously). A Snapshot is a frozen copy at a specific moment — "what did the order book look like at end-of-day Thursday?" The output is immutable after it is taken.

End-of-period reporting: daily close, monthly reconciliation, season summary. Data migration preparation: freeze current state before migrating to a new schema. Disaster recovery checkpoints. Audit compliance: provable state at a specific regulatory deadline. Any situation where the question is "what was the exact state at time T?"

A packet that carries routing refinement information in its payload. The bus reads a field to determine additional routing beyond what the routing table specifies. An ORDER_UPDATED packet carries a region field. A multi-region deployment routes to the correct regional Vault based on the field, without separate packet types per region.

Multi-tenant or multi-region deployments where the routing table declares the general path and the payload refines it. Rather than creating ORDER_UPDATED_NORTHEAST, ORDER_UPDATED_SOUTHEAST, etc., one ORDER_UPDATED type carries a region field and the bus uses it to select the correct regional Vault instance.

A test double on the bus. During integration testing, a Phantom loop replaces a real loop — it subscribes to the same packet types and emits the same responses, but with controlled, deterministic behavior. Test a Workflow pipeline by replacing the Vault with a Phantom that always succeeds (happy path), always fails (fault injection), or fails on the third call (retry testing). Phantoms are wired through the constellation initializer by swapping the factory — the routing table and contracts don't change.

Integration testing and scenario testing. Happy path: all Phantoms succeed. Failure injection: specific Phantoms fail to test retry, abort, compensate, and escalate strategies. Latency simulation: Phantoms add delays to test timeout behavior. State verification: Phantoms record what they received so tests can assert on the exact packets that arrived.

A lightweight, selective observer. Where passive observation sees all traffic on a bus, a Tap filters to a single packet type or source. Useful for targeted debugging: "show me only PRICE_CALCULATED packets" or "show me everything emitted by workflow:cancel." The Tap is an observer with a filter predicate. It can be attached and detached at runtime without modifying any loop or route.

Debugging in development or production. "I want to see what the Pricing Engine is emitting right now." "I want to watch all LOOP_ERROR events for the next 5 minutes." "I want to log every packet that touches this specific order ID." The Tap is a runtime debugging tool — attach, observe, detach. No code changes, no restart.

Two separate Loop MMT constellations that exchange data. Not multi-device sync (that is the Sync Bus) — two different applications talking to each other. The butcher constellation talks to an accounting constellation or a supply-ordering system. Each is a separate constellation with its own loops, buses, and spec. They communicate through a dedicated inter-constellation bus carrying a defined set of packet types — the shared protocol.

When your application ecosystem grows beyond a single constellation. The butcher app needs to send financial data to an accounting system. The order management system needs to talk to a supply chain system. Each system is independently developed and deployed. The inter-constellation bus is the contract boundary — governed by the same packet validation that governs every other bus.