Gartner's 2026 observability forecast puts it bluntly: 15% of production GenAI deployments have instrumentation. That number hits 50% by 2028.

The other 85% are flying blind. Agents making API calls. Models chaining prompts. Fallback logic firing retries. No one watching whether any of it produced anything.

I built a system that watches. Not through a dashboard. Not through a vendor subscription. Through three functions in a TypeScript file. They are called yield points. They are the difference between a system that crashes silently and a system that refuses to start when the math does not add up.

What does execution integrity actually mean?

Log #2 told the discovery story. The governance dashboard showed an average deliberation cost that was mathematically impossible. 63 debates. 6 with valid data. 57 NULLs. The number was wrong because the data was missing.

The number was also a tripwire. It just had no one watching it.

Cost, in a system built on third-party APIs, is not accounting. It is instrumentation. When a debate runs normally — 4 models, 3 rounds, 12 calls — the execution pattern is predictable. When a model returns empty, the fallback chain activates. 3 models. 2 attempts each. Tokens consumed. Nothing produced.

The cost doesn't spike because someone changed a pricing tier. It spikes because something broke. The spike is the signal. The breaker is the response.

Log #3 was about the order of the pipeline. The rendering step ran inline processing before block extraction, and the result was a page full of teal backgrounds where code blocks should have been. The fix was changing the sequence.

This article is about the health of the execution. Not the order of operations. Whether the operations produce anything at all.

Because here is what happened before the circuit breakers existed. A debate would start. Four models would receive prompts. Three would respond. One would return empty. The fallback chain would fire — three alternative models, two attempts each. Tokens consumed on every attempt. The debate would complete with a partial verdict. The user would see three model cards and one blank space. No error logged. No explanation. Just a missing card.

The circuit breaker did not add observability. It added refusal. I spent three days watching the fallback chain burn tokens before I realized the engine did not need better monitoring. It needed a refusal mechanism. The engine now says no. Not after the fact. Before.

How do the three yield points actually work?

Every debate passes through three gates. Each gate has one job: check whether execution is healthy enough to continue. If the answer is no, the gate halts.

The following diagram shows the three yield points as hard boundaries, not suggestions.

Point 1: Pre-flight Projection. Before any model runs, the engine projects what this debate will consume. It reads the model roster. It checks the per-model pricing map. It multiplies by three rounds and adds the orchestrator. If the projection exceeds 1.5× the budget threshold, the debate never starts.

This gate does not care about account balances. It cares about proportion. A debate asking for 4 frontier models is already near the ceiling. Add document context at 3× consumption, and the breaker trips. The user gets an explanation. The engine stays in a known good state.

Point 2: Round Boundary. After each round, the engine evaluates cumulative execution against the projection. If round 1 ran hot, the fallback chain fired. The projection tightens. The remaining budget shrinks. If the math no longer works, the debate halts between rounds, not mid-sentence.

Point 3: Quorum Detection. If every model fails — all four primary models, every fallback chain exhausted — the debate cannot produce a verdict. The engine does not retry. It does not loop. It halts and logs the failure.

Where is the code that enforces this?

The circuit breaker is not a configuration file. It is not a feature flag. It is three functions that execute at three specific points in the debate lifecycle.

// Point 1: Pre-flight — before any model runs
const estCostPerRound = models.reduce((sum, m) => {
  const pricing = PRICING[m.openRouterId];
  return sum + (pricing ? (pricing.input + pricing.output) / 2 / 1_000_000 * 500 : 0.15);
}, 0);
const estTotalCost = (estCostPerRound * 3) + 0.15;
const maxBudget = 2.50;

if (estTotalCost > maxBudget * 1.5) {
  onEvent({ type: 'error', data: { message: 'Estimated consumption exceeds threshold' } });
  return; // Debate never starts
}

The pricing map updates from the PRICING object in types.ts. Add a model to the roster, the projection recalculates. Change providers, the thresholds shift. The breaker is calibrated to the system it protects — not to a static number in a config file.

// Point 3: Quorum — all models failed, all fallback chains exhausted
if (failedInPreviousRound.size === models.length) {
  logError('BOUNDARY_HALTED', 'All models exhausted — halting debate', { debateId });
  onEvent({ type: 'error', data: { message: 'All models in the council have failed' } });
  return; // Quorum not met — cannot produce verdict
}

Three yield points. Three return statements. The engine refuses to run when execution integrity is compromised. That is not error handling. That is governance.

Are tripwires an industry pattern or just this codebase?

The industry is converging on this pattern. Microsoft's Agent Hypervisor specification defines four execution rings with explicit resource constraints per ring. Ring 3 — the sandbox — limits agents to 10 calls per minute. Rate limiting is a tripwire. The ring enforcer checks before the action, not after.

The Zero-Trust for Agents paper maps tripwires to the NIST AI Risk Management Framework. "Tripwires are automated checks or triggers that detect when an agent's behavior deviates from policy or normative patterns." The paper's target SLO: 95% of dangerous actions halted within 5 seconds of detection.

ProveAI's observability framework states it directly: "Cost anomalies are often failure signals before quality metrics catch them. An agent loop that runs longer than expected might indicate a reasoning problem upstream. The cost spike is the early warning."

The three yield points in the debate engine are not novel. They are the same pattern, implemented at the application layer, without a vendor dependency. The industry is building hypervisors and observability platforms. I built three functions.

The difference is not quality. It is independence. A hypervisor manages agents from the outside. It intercepts calls, enforces rings, logs actions. A circuit breaker manages execution from the inside. It is part of the engine, running at the same privilege level as the code it governs. Both work. One ships with every debate.

The Model Council runs this pattern on every debate. The Veritas specification extends the same architecture to sector-specific deliberative interfaces. The governance layer is the infrastructure. The product is the evidence that it works.

Is your agent flying blind?

What happens when a model in the council fails?

The fallback chain activates. 3 models, 2 attempts each. If a response is produced, the debate continues. If all fail, quorum detection halts the debate. The tokens consumed during retries are logged. No verdict is produced. No execution continues on broken state.

How is this different from a try/catch block?

A try/catch catches what already threw. The pre-flight gate projects before anything runs. The round boundary checks between stages, not after exceptions. The quorum gate counts failures as a collective signal, not individual errors. Try/catch is reactive. Yield points are preemptive. The hardest part of building this was not the logic. It was learning to trust the tripwire enough to let it halt my own work when the math did not add up.

Do I need an observability platform to add tripwires?

No. The circuit breaker in debate-engine.ts is 47 lines. The pricing map is imported from a single types file. The quorum check is a Set comparison. The entire tripwire layer is less code than the average CI pipeline configuration.

What is the first tripwire I should add?

Count your empty responses. If a model call consumes tokens and returns nothing, log it. If it happens 3 times in one run, halt. That single check catches the most common failure mode in multi-model systems. It is 10 lines of code. Start there.

Gartner says 85% of GenAI deployments have no tripwires. The number is dropping. It will hit 50% by 2028. The question is not whether your infrastructure will need execution gates. It is whether you will build them before a broken process burns through your quota in silence.

Does your agent have a tripwire? If not, you are measuring performance, not health.

This is the fourth entry on the NiraNexus Log. More follow — one per architecture decision, one per production incident, one per hard lesson. The standard for every article published here: what shipped, what broke, what we learned. Subscribe via RSS.

CS Engineering. MBA. 18yrs across enterprise consulting. Now building NiraNexus-OS.