Chapter 24: Feedback Loops

A feedback loop is the mechanism by which an organization learns what is actually happening in its execution surface and corrects what needs correcting. In a traditional organization, feedback loops are mostly human: managers observe teams, teams observe customers, leadership observes markets. The signals are rich in context and slow in cycle time. A weekly retrospective catches what a quarterly review would miss. The rhythm works because human execution moves at roughly human pace.

In a hybrid organization, this rhythm breaks. The system layer generates signals far faster than any human loop can absorb them — a fraud detection model produces millions of decisions per day, an automated pricing engine adjusts thousands of prices per hour, a customer support AI handles cases in seconds. Waiting for a monthly review to detect a problem means waiting while the problem compounds across a scale of execution that no human review can reconstruct after the fact.

But the automated loop has the opposite problem. A threshold fires. An alert arrives. A metric crosses a boundary. None of this tells the organization what the signal means. Automated loops produce data without context — and data without context is not feedback. It is noise the organization has not yet decided what to do about.

The architectural answer is not to choose between the two. It is to design three loop types — human, automated, and blended — assign each to the execution modes and consequence levels where it fits, and define the signal-to-decision SLA that each executor's tier requires. The most consequential design question is the blended loop, and it is the one most organizations do not design explicitly.

THE CORE IDEA

Every feedback loop has three structural properties: signal source, cycle time, and context richness. Human loops have high context, slow cycle, and observation-based signal. Automated loops have low context, fast cycle, and metric-based signal. Blended loops combine automated signal with human interpretation — fast signal routed through a named interpreter who adds the context the data lacks.

The loop type determines the mechanism. The executor's consequence tier determines the speed. A feedback loop is not defined by how signal is generated, but by how quickly that signal becomes a decision. Designing the feedback architecture means assigning both the right loop type and the right consequence tier to every executor on the surface.

Figure: Three feedback loop types — signal source, cycle time, failure mode, and mode-to-loop mapping

Three loop types mapped to execution modes. The interpretation layer callout identifies where most blended loops fail: if no named interpreter is responsible for the signal, it accumulates in dashboards no one reads.

THE HUMAN LOOP: WHAT IT DOES WELL, AND WHERE IT FAILS

The human loop is the feedback mechanism every organization already runs. A manager observes a team. A team observes a customer. Leadership reviews performance. The loop has genuine strengths: rich context, immediate interpretation, and decision-makers who already hold the business knowledge the situation requires.

The human loop fails in one specific condition: when the execution surface being observed moves faster than the observer's cycle time. A manager's weekly one-on-one cannot observe a fraud detection model that made seventeen thousand decisions since the previous meeting. The human loop is not slow because humans are inefficient. It is slow because the signals it processes are contextual and the judgments it produces take time to form well. Applying the human loop to system-layer execution produces predictable failure: the system runs for months before the review cycle surfaces a problem, and by then the pattern has compounded at a volume the observer cannot reconstruct.

THE AUTOMATED LOOP: FAST SIGNAL, MISSING MEANING

The automated loop takes the opposite position. A metric is defined. A threshold is set. When the metric crosses the threshold, an action fires. Cycle time is milliseconds. The loop runs without human intervention.

What the automated loop cannot do is tell the organization what any particular signal means. An alert fires because latency crossed a threshold. Does that mean a system is degrading, a customer is being affected, an upstream dependency failed, or the threshold was set too aggressively? The data alone does not answer the question. The threshold crossing is an event. Its meaning requires interpretation — context about the business, the customer, the system's history.

Automated loops work well for a narrow class of situations: operational monitoring where the metric-to-meaning mapping is stable and well-understood. Service uptime. Error rates. Response latency. The monitoring industry has decades of practice translating these specific signals into reliable automated responses. Automated loops fail when applied to situations where the signal-to-meaning mapping is not stable — which is precisely the condition governance monitoring of consequential AI and automation faces.

THE BLENDED LOOP: WHERE MOST HYBRID GOVERNANCE LIVES

The blended loop is the structural answer to the hybrid organization's feedback problem. Automated systems produce signal at machine speed. Humans produce interpretation at human speed. The blended loop captures automated signal and routes it to a named interpreter on a cadence that matches the decision the signal is supposed to produce.

The structure has three components. First, automated monitoring generates signals. Second, a named interpreter receives the signals on a defined cadence and has protected time to interpret them in context. Third, the interpretation produces a defined decision output: no action, monitor more closely, initiate recalibration, escalate to leadership. Each component is required. Remove any one of them and the loop stops functioning.

The named interpreter. Every blended loop must have a specific named person or role accountable for interpreting the signals it produces. In the hybrid governance model this is typically the governance owner for the executor. The responsibility is structural: if signals from executor X are produced, person Y is accountable for interpreting them within the SLA defined by the executor's consequence tier.

The time budget. Interpretation takes time. A governance owner who is expected to interpret signals across multiple executors cannot do so in stolen moments between other responsibilities. The blended loop design includes a protected time budget — in most cases thirty to sixty minutes per week per executor under active T2 or T3 governance attention, with on-call availability for T1 executors.

The decision output. Every blended loop has a defined set of decision outputs the interpretation must produce: no action required, continue current monitoring, initiate recalibration, escalate to leadership, trigger mode transition. If the interpretation produces observations that do not cascade into decisions, the loop has broken between signal and action.

CONSEQUENCE TIERS AND SIGNAL-TO-DECISION SLA

Blended loop latency is not a single number. It is a tiered commitment that varies by executor consequence level. The consequence tier is assigned in the authority grant record when the ACG authorizes the executor. The tier determines the SLA — the maximum time between signal generation and decision — and the standby obligation the governance owner accepts when they take the role.

Figure: Executor consequence tiers — signal-to-decision SLA, standby requirement, and SLA breach triggers

Three consequence tiers with associated SLAs, standby requirements, interpretation cadences, and breach escalation paths. Tier is assigned at ACG review and recorded in the authority grant record. Re-tiering requires a delegation decision.

Tier 1 — Critical consequence. Executors making real-time decisions with direct customer, financial, or regulatory impact at scale. SLA: four hours or less. The governance owner is on-call — explicitly reachable within the SLA window with a named backup and documented escalation chain. An hours-level SLA only works if the standby obligation is designed into the authority grant record, not assumed. A Tier 1 SLA with no standby design is a promise the organization cannot keep.

Tier 2 — Significant consequence. Executors making consequential decisions at volume with delayed or reversible impact. SLA: forty-eight hours. The governance owner is responsive within one business day. Threshold breaches bypass the weekly cadence and trigger direct notification. The weekly monitoring session is the standard cadence; the notification path is the exception channel for signals that cannot wait.

Tier 3 — Standard consequence. Executors operating within well-understood boundaries with limited downstream consequence. SLA: seven days, aligned to the weekly monitoring cadence. No standby requirement. The governance owner reviews at their scheduled session. An SLA breach at Tier 3 is flagged at the monthly governance review — it is not an immediate escalation condition.

The consequence tier is a governance commitment, not a technical classification. When the ACG assigns Tier 1 to an executor, it is establishing that the organization commits to responding to signals from that executor within four hours. If the organization cannot make that commitment credibly — because the governance owner has no backup, the on-call structure does not exist, or the escalation chain is unclear — the executor should not be authorized to operate in Tier 1. The tier assignment is the moment at which the organization decides whether its governance model can actually support the executor it is authorizing.

THE OWNERSHIP REGISTER: LOOP GOVERNANCE METADATA

The ownership register established in Part III records executor name, execution mode, governance owner, and purpose owner. Chapter 24 extends the register with seven loop governance metadata fields: loop type, consequence tier, signal-to-decision SLA, named interpreter, interpretation cadence, last review date, and current status.

The last review date is the most operationally significant addition. It is the field that makes the loop health signal visible without investigation. A Tier 2 executor whose last review date is twenty-one days ago has missed three weekly monitoring sessions and breached its forty-eight-hour SLA repeatedly. That fact is invisible in the monitoring dashboard — the signals are firing correctly. It is visible in the register — because the last review date has not been updated.

Figure: Ownership register with loop governance metadata — amber columns are Chapter 24 additions

The register's existing fields (executor, mode, governance owner, purpose owner) are extended with loop type, tier, SLA, interpreter, cadence, last review date, and status. The pricing engine row shows an overdue T2 executor — last reviewed 21 days ago against a 48-hour SLA. The problem is visible in the register without examining any dashboard.

Running the register as a governance health check at the monthly session means asking one question per executor: is the last review date within the SLA for this tier? Any row where the answer is no has a loop that has stopped functioning regardless of whether the monitoring infrastructure is technically operational. The register makes the difference between a loop that exists and a loop that is working visible to the CTO without requiring access to each executor's individual dashboard.

SIGNAL-TO-DECISION LATENCY AS THE LOOP HEALTH METRIC

A feedback loop is not healthy because it produces signals. It is healthy because signals produce decisions within the timeframe the tier SLA requires. Signal-to-decision latency — the time between when a signal is generated and when a decision is made in response — is the one metric that catches all three loop failure modes.

When actual latency diverges materially from the tier SLA, the loop has failed even if all its components appear to be functioning. A Tier 2 executor whose blended loop is producing decisions in three weeks instead of forty-eight hours has a collapsed interpretation layer — regardless of whether the monitoring infrastructure is healthy and the dashboard is live.

The quarterly governance review from Chapter 22 includes a standing check: for each executor tier, what is the ratio of signals that crossed a recalibration threshold to recalibrations actually initiated? When the second number is materially lower than the first, the interpretation layer is where the governance model is leaking. The gap is the signal-to-decision latency failure in aggregate — and it points directly to which executors need a named interpreter, a protected time budget, and a defined decision output assigned before the next quarter.

THE FAILURE MODE

The organization has monitoring infrastructure but no interpretation layer. Dashboards are live. Signals fire. No decisions follow.

The failure is invisible in the infrastructure view and visible only in the decision view: how many signals crossed recalibration thresholds versus how many recalibrations were initiated, how many Tier 1 and Tier 2 executors have last review dates within their SLA versus how many have drifted past it. When those ratios are poor, the loop architecture is not functioning — regardless of how well the monitoring is built.

The correction is the same three components every blended loop requires: name the interpreter, protect the time, define the decision outputs. Add the consequence tier and its SLA to the authority grant record before the executor goes live. Track the last review date in the ownership register. Review it monthly. The structural investment is modest. Without it, the feedback architecture accumulates signals and produces no learning.