1 Introduction↩︎

Modern LLMs are optimized for next-token likelihood. This objective rewards fluency and stylistic plausibility but has no direct relation to whether a generated artifact corresponds to a verifiable state of the world. A model can confidently report that a file exists, that a test passes, or that a function returns a particular value when none of these are true. This failure mode is widely discussed under the umbrella of hallucination [1], [2]. We take the view that it is not a calibration issue but the consequence of optimizing a divergence over symbol sequences rather than a divergence over external states.

We focus on the case where the agent’s task is to drive an external system. A repository, a database, a test suite into a target configuration. In this setting, hallucination manifests as a divergence between two state estimates: the claim state encoded in the model’s narrative output, and the reference state obtained by querying the external system. We call this divergence epistemic entropy. The control problem is to monitor and reduce it.

The following shall stand as main contributions for this paper.

1.0.0.1 Contributions.

1. A formal definition of epistemic entropy for LLM-driven control over external state (Sec. 3).

2. HCRC, a deterministic control wrapper whose advance condition is a Heaviside step over a confidence–verification product (Sec. 4).

3. The Arial parallel worker pool, in which non-LLM checkers operate on disjoint evidence channels and aggregate into a single gate (Sec. 5).

4. A structural guarantee that under sound checkers no step is committed while any predicate fails (Theorem 2), and a per-step bound on the reduction in epistemic entropy (Theorem 3).

5. Reproducible experiments across thirteen proposers from four providers (Groq Llama-3.3-70B and Llama-3.1-8B; OpenAI’s open-weight GPT-OSS-120B via OpenRouter; seven OpenAI GPT models; three Anthropic Claude models) showing that unwrapped false-completion rates of \(4\)–\(7\%\) collapse to \(0\)–\(3\%\) on capable proposers when HCRC is enabled, with sub-1.5 mean retries per committed step (Sec. 9), and ablations on \(250\) runs covering worker composition, threshold \(\tau\), and predicate gaming.

6. A production deployment of the framework as the control plane of an agentic coding environment (Sec. 11): hardware-indexed execution profiles that size the Arial pool to a compute budget, verification-slaved progress reporting in which no interface element may claim more than the gate has committed, and gate-licensed memory compaction in which only gate-derived records may replace session context.

7. A consolidated set of seven empirical findings (Sec. 10) supported by data-driven plots: the Heaviside barrier holds at \(\tau{=}1\) across every tested proposer, HCRC normalizes residual FCR across capability, HCRC can be faster than the unwrapped LLM on capable models, threshold tuning is non-monotonic, strong proposers do not game visible predicates, the Validator–Tests pair carries most of the verification load, and epistemic entropy decays monotonically only under the gate.

2 Related Work↩︎

There is a substantial body of literature demonstrating cases of doxastic confabulation in large language models; we survey those that are not peculiar to our study.

2.0.0.1 Hallucination in language models.

Surveys [1]–[3] taxonomize hallucinations into intrinsic (contradicting the prompt) and extrinsic (contradicting the world). Most mitigation targets the former via decoding [4], sampling [5], or training-time methods [6]. Recent theoretical results argue that hallucination is not fully removable at the model level: calibrated models must hallucinate at a positive rate [7], and inevitability results hold for any computable LLM [8]. These results motivate our position directly if generation cannot be made error-free, the error must be caught at the execution layer. Our setting is extrinsic by construction: the world is a concrete repository or environment, and disagreement is mechanically detectable. Model self-knowledge helps but does not suffice: even well-calibrated confidence [9], [10] is a property of the claim channel, whereas the gate adjudicates on the reality channel.

2.0.0.2 Tools, retrieval, and verification.

Augmenting LLMs with tools [11], [12] or retrieved context [13] reduces but does not eliminate hallucination; the model still chooses when to invoke a tool and how to interpret its output. Process-supervised reward models [14] apply step-level verification during training. HCRC differs: verification is mandatory and post-hoc, every committed step must pass decidable predicate checks, regardless of how the step was generated.

2.0.0.3 Self-refinement and self-judging.

Self-Refine [15], Reflexion [16], and self-debug [17] loop a model against its own critique, and constitutional or debate-style schemes [18], [19] scale the judge with another model. These methods use a model as judge, which is known to be biased [20]; moreover, models are unreliable at recognizing their own reasoning errors [21], [22], and self-repair recovers less than commonly assumed on code tasks [23]. We use non-LLM checkers (filesystem, AST, tests) as the authority; the LLM is restricted to proposer.

2.0.0.4 Output verification and fact-checking.

A complementary line verifies generations after the fact: trained verifier models re-rank solutions [24], SelfCheckGPT tests sampling consistency [25], FActScore decomposes long-form output into atomic facts checked against a corpus [26], chain-of-verification interleaves check questions [27], and guardrail frameworks interpose programmable filters [28]. These verify text against text or corpora; HCRC verifies state against decidable predicates and couples the verdict to a hard execution barrier rather than a score.

2.0.0.5 Structured reasoning.

Chain-of-thought and its generalizations [29]–[31] restructure the proposer’s search; program-aided variants [32], [33] delegate computation to an interpreter. All improve the proposal distribution and all remain unverified at commit time; HCRC is orthogonal and can wrap any of them.

2.0.0.6 Runtime verification and verified AI.

Outside LLMs, monitoring executions against formal properties is a mature discipline [34], and verified-AI programs argue for environment-in-the-loop guarantees [35]. Proof assistants have begun to incorporate LLM proposers under kernel-checked verification [36] the same proposer/checker asymmetry we exploit: generation may be heuristic when acceptance is sound.

2.0.0.7 Coding agents and benchmarks.

Code generation has progressed from function-level benchmarks [37]–[39] to repository-scale agents [40]–[42] and multi-agent frameworks that distribute roles across model instances [43]–[45]. Role distribution alone does not change the epistemic situation because every judge is still a model and models are prone to confabulations from time to time; our worker pool distributes verification across non-model evidence channels instead. They typically report pass/fail at task completion. We are concerned with intermediate steps of which at each step, is the agent’s claim of progress congruent with the repository of the external system or tool. Our framework can wrap any such agent.

2.0.0.8 Bang-bang control.

The Heaviside (bang-bang) policy has a long history in classical control [46], [47], and hard barriers against silent error propagation echo the concrete-problems framing of AI safety [48]. We adopt the step policy deliberately to replace soft confidence scores, which compound in autonomous loops.

3 Epistemic Entropy↩︎

Let \(\mathcal{S}\) denote the space of observable system states (e.g., contents of a working directory together with outputs of a fixed set of commands). At time \(t\), the external system is in some state \(s_t \in \mathcal{S}\), accessible only through queries; the agent maintains a claim state \(\hat{s}_t\), derived from the most recent LLM output. Both are evaluated through a finite collection of verification predicates \[\mathcal{P} = \{p_1, p_2, \ldots, p_m\}, \quad p_j : \mathcal{S} \to \{0,1\},\] each decidable in bounded time (file_exists, file_contains, test_passes, parses, …). We use doxastic for properties of the model’s claim state \(\hat{s}\) and alethic for properties of the reference state \(s\); the gate of §4 adjudicates only on alethic evidence. Algorithm 3 expands the predicate evaluator into the four decidable kinds we implement.

A doxastic confabulation (in the wider literature, a hallucination) is any LLM output that increases \(\Delta\) without a concomitant decrease in \(S_e\): the narrative progresses, the alethic state does not.

3.1 LLM anatomy and where claims emerge↩︎

Figure 4 gives an exploded view of a decoder-only transformer of the kind we use as proposer. Four sites contribute to epistemic entropy: (i) tokenization, which lossily maps identifiers and paths to embedding indices; (ii) attention, whose long-context references can collapse to nearest patterns; (iii) the feed-forward block, whose memorized fragments can override grounded context; and (iv) sampling, which selects plausibility over truth. The claim state \(\hat{s}_t\) is recovered from a structured tail block parsed from the decoded token stream. Crucially, none of the workers in Section 5 reads internal model state; they read the repository.

For completeness we take special note of the part of the model that emits the claim. as visible in Figure 5 which shows a transformer block; the claim state \(\hat{s}_t\) is parsed from a structured tail block in the output stream. The Figure 6 also shows the autoregressive KV-cache structure that maintains the in-context evidence the model has seen. Most Importantly, the verification channel does not read from this cache: it reads directly from the filesystem.

4 Heaviside Continuity of Rolling Coefficients↩︎

This framework is inspired by the works of Oliver Heaviside on the definition of the step function as a mechanism for continous processing. We asses that the framework is strong on homogeneous systems that are inherently continous. In its simplest form the HCRC framework simply tries to decompose problems into homogeneous abstract atomic steps that cannot be broken down further. The rolling coeffficient part of the framework is where the measures are taken into account. Almost any system with a complete cycle can be classified as rolling coefficients for example, the minutes of an hour, the 24 hours of the day can be classified as rolling coefficients, the miles in a lap of a Formula 1 circuit and etc can become the rolling coeffients.

4.1 Pipeline structure↩︎

We formally define that a task is decomposed into an ordered sequence of Rolling Coefficients \[\mathcal{R} = (R_1, \ldots, R_n),\qquad R_i = (\text{intent}_i, \text{prompt}_i, \mathcal{P}_i),\] where \(\mathcal{P}_i \subseteq \mathcal{P}\) is the predicate set that must hold after \(R_i\) completes. The pipeline maintains a confidence scalar \(C(t) \in [0,1]\) and the verification score \(V_i(t)\) restricted to \(\mathcal{P}_i\).

4.2 The Heaviside gate↩︎

For threshold \(\tau \in (0,1]\), advance from \(R_i\) to \(R_{i+1}\) is permitted iff \[\label{eq:gate} \mathbf{H}\!\bigl(C(t) \cdot V_i(t) - \tau\bigr) = 1,\qquad \mathbf{H}(x) = \mathbf{1}[x \geq 0].\tag{1}\] If the gate returns \(0\), the step is held and the prompt is augmented with the predicate-failure list. Algorithm 7 states the adjudication as three lines.

4.3 Confidence dynamics↩︎

Confidence reacts quickly when evidence is poor and saturates when consistent: \[\label{eq:conf} \Delta C = \lambda\, Q(t)\, e^{\beta Q(t)}\bigl(1 - C(t)\bigr),\tag{2}\] with instantaneous evidence quality \(Q(t) = V_i(t)\), \(\lambda = 0.15\), \(\beta = 2.0\). Under constant \(Q^*\), \[C(t) = 1 - (1 - C_0)\exp(-\lambda_{\text{eff}} t),\quad \lambda_{\text{eff}} = \lambda Q^* e^{\beta Q^*}.\] Figure [fig:confidence] plots \(C(t)\) for several \(Q^*\). Algorithm 9 records the discrete update implemented by the controller; it is invoked once per per-step iteration of Algorithm 16.

4.4 Rolling coefficients↩︎

We formal define RC Within a step, scalar weights \(\alpha_k(t) \in [0,1]\) which control the relative aggression of prompt revisions: \[\label{eq:rc} \dot{\alpha}_k = \beta_k Q(t)(1 - \alpha_k) - \gamma_k E_k(t)\alpha_k,\tag{3}\] with predicate-specific error \(E_k(t)\).

5 The Arial Worker Pool↩︎

Figure 10 is the centerpiece of the framework. Eight gates partition the loop: (0) prompt construction with Rolling Coefficient injection; (1) decode and Summary Parser; (2) Validator; (3) Syntax Guard; (4) Test Runner and Citation Guard; (5) Aggregator computing \(V_i = \sum_k w_k v_k\); (6) Confidence update via Eq. 2 ; (7) the Heaviside step \(\mathbf{H}(C\cdot V - \tau)\); (8) the routing to ADVANCE or HALT.

A single monolithic check is easy to satisfy by fluent text. Arial decomposes verification across \(K\) independent workers, each evaluating a different facet of \(\mathcal{P}\) in a fixed epistemic regime.

5.1 Workers↩︎

For LLM-driven software synthesis we use the workers in Table 1.

Algorithms 12–14 formalise the three workers whose pseudocode is most often re-implemented downstream: the validator, the summary parser, and the gap-miner-driven prompt reviser. The remaining workers (Syntax Guard, Test Runner, Citation Guard, Confidence) are thin wrappers around standard tooling (ast.parse, subprocess invocation, substring search, Algorithm 9) and we omit their listings for brevity.

5.2 Epistemic states and aggression↩︎

Each worker indexes its aggression by an epistemic state (Figure 15): \[\text{IGNORANT}\to \text{OBSERVING}\to \text{DERIVING}\to \text{EXECUTING}\to \text{MASTERING},\] with \(\mathcal{A}=(1.0,0.8,0.5,0.2,0.1)\), indexed by intervals of \(C\): \[[0,\,0.2),\;\; [0.2,\,0.5),\;\; [0.5,\,0.75),\;\; [0.75,\,0.95),\;\; [0.95,\,1].\]

5.3 Pool execution↩︎

Workers run concurrently; the controller blocks until all report. The aggregate verification score is \[V_i(t) = w_{\text{val}} V_{\text{val}} + w_{\text{syn}} V_{\text{syn}} + w_{\text{test}} V_{\text{test}},\qquad \sum w_\bullet = 1.\] Algorithm 16 summarizes the per-step loop.

6 Theoretical Guarantees↩︎

Corollary 3 is the formal counterpart of Finding Figure 7 (§10): under the gate, the operational epistemic entropy traces a monotone non-increasing trajectory, and any plateau is constitutive of a recertification step rather than residual error.

7 Empirical Foundation: Mastery of Game Environments↩︎

The control loop of Algorithm 16 was previously validated in four entropy-dominated game environments Flappy Bird, Snake, Chrome Dino, and a maze solver where epistemic entropy is replaced by physical entropy and verification predicates by event detectors (e.g., not_collided, passed_obstacle). In each environment the agent observed without any pretraining, derived a parametric model of the dynamics, and selected actions through a Heaviside policy over a risk functional, qua per-frame instantiation of Algorithm 16 with a game-specific \(\Psi\) in place of \(C\cdot V\). Table 2 reports mean frames-to-mastery, defined as the first time \(C(t) \geq 0.7\) and every game-specific predicate obtains for \(\geq 50\) consecutive frames; mastery was reached on all four environments without gradient-based training of the proposer. The structural analogy to the LLM setting is direct: the observe\(\to\)derive\(\to\)validate\(\to\)gate cycle is the same, the workers shift role (a Flappy PhysicsEstimator or a Snake FloodFiller plays the part that Validator and TestRunner play in software synthesis), and the gate is the same Heaviside step. Games are not the contribution of this paper; we summarise them here to evince that the loop pre-dates its LLM instantiation and was first validated on dynamics whose ground truth is exact. Full per-environment derivations state spaces, dynamics, risk functionals, mastery predicate sets, and game-specific worker pools are given in [50].

8 Application: LLM Software Synthesis (Rocket Coding)↩︎

Algorithm 17 states the outer mission loop that chains Rolling Coefficients in order; the inner per-step subroutine is Algorithm 16, and the retry policy obtains directly from the gate’s halt branch (Algorithm 7).

The LLM acts as proposer. It receives \(\text{prompt}_i\) together with the latest list of unsatisfied predicates and returns a free-form response that ends with a structured summary block:

 SUMMARY 
{"changes": [...], "status": "...",
 "gaps": [...], "next_hint": "..."}
 END 

The Summary Parser extracts \(\hat{s}_t\) from this block. Other workers read the repository directly and never the summary. This enforces Assumption 2. The reference implementation persists two JSON artifacts: pipeline.json (ordered \(R_i\), current \(C\) and \(V_i\), epistemic state) and accomplished.json (append-only evidence record per committed step).

9 Experiments↩︎

We report (i) a reproducible single-task demonstration, (ii) a synthetic benchmark spanning proposer models from three providers (Groq, Google Gemini, and OpenRouter), and (iii) three ablations.

9.1 Models and infrastructure↩︎

We evaluate proposer models across three providers, all wrapped in the same HCRC controller with the same predicate sets and prompts:

• Llama-3.3-70B-Versatile and Llama-3.1-8B-Instant via the Groq API;

• Gemini-2.5-Flash and Gemini-Pro-Latest via the Google Gemini API;

• GPT-OSS-120B (free), OpenAI’s open-weight 120B mixture-of-experts model, served via the OpenRouter API.;

• Claude Haiku, Sonnet and Opus, This was done via the Claude Api through the anthropic platform.

Each proposer is prompted in a fresh temporary working directory; verification predicates are then evaluated against the resulting filesystem state through the venv’s Python interpreter (so that the hidden command_succeeds tests can import flask and fastapi, which we install in the harness). Table 4 only reports rows for which both the unwrapped and HCRC conditions ran to completion under the free-tier daily quotas of the providers; rows that were interrupted mid-run are excluded.

9.2 Tasks and predicates↩︎

We evaluate HCRC on synthetic software-synthesis tasks emitted by experiments/tasks.py:synthesize(n_per_family=10, seed=0) rather than on an established benchmark such as SWE-bench [40], HumanEval, or MBPP. The reason is that synthetic tasks let us construct the verification-predicate set \(\mathcal{P}\) at generation time, which is precisely the input that Theorem 2 needs in evaluation; the harness also runs comfortably inside the free-tier daily quotas of every provider in Table 4, so the entire experiment can be re-executed at no monetary cost. The generator is deterministic and emits \(50\) tasks (up to \(30\) used per model) across five families Flask scaffold, FastAPI scaffold, Python argparse CLI, data-transform script, and sqlite3 migration each carrying \(4\)–\(8\) visible predicates (file_exists, parses, file_contains) and one hidden command_succeeds test that the proposer never sees (e.g.for the Flask family, the hidden test runs python -c "import app; assert app.app is not None"). The hidden predicate is what protects the gaming evaluation of Section [sec:gaming]: a model that emits only the literal predicate strings clears \(\mathcal{P}_{\text{vis}}\), but the import-driven command_succeeds check halts the gate at \(V < 1\). Reproduction is a single deterministic call to synthesize(…) with the same seed; that generator is the single source of truth for every row of Tables 4–[tab:gaming] and every mission in Figure 21. Synthetic tasks are strictly easier than SWE-bench-style benchmarks (one short file, fully known predicate set, no surrounding codebase); a natural follow-up is to re-run the controller on SWE-bench Lite where the predicate set must instead be discovered, but the present paper deliberately holds that discovery problem out so the gate’s structural claim can be measured in isolation.

9.3 Reproducible demonstration↩︎

We set up a minimal Flask scaffold task with \(\mathcal{P} = \{p_1, p_2\}\), \(p_1=\texttt{file\_exists}(\texttt{app.py})\), \(p_2=\texttt{file\_contains}(\texttt{app.py}, \texttt{`@app.route(`/login`)`})\). The directory is seeded so that both hold. We feed the Arial pool two synthetic responses with identical narrative success but different claim sets: grounded \(\hat{s} = \{\texttt{app.py},\texttt{requirements.txt}\}\) and hallucinated \(\hat{s} = \{\texttt{app.py},\texttt{models.py}\}\) (second file absent).

9.4 Synthetic benchmark↩︎

We draw the task pool from the deterministic generator described in Section 9.2 (synthesize(n_per_family=10, seed=0); 5 families, 50 tasks), and run up to \(30\) tasks per model under the free-tier daily quota of each provider. Each task carries \(4\)–\(8\) visible predicates and one hidden command_succeeds test (Section 9.2). For each task we run two conditions: (a) unwrapped LLM with self-reported success, (b) HCRC+full Arial pool at \(\tau=1\) with \(\bar r_{\max}=3\) retries. Metrics: FCR (false-completion rate the run terminates with a success claim while at least one predicate fails), \(V^{\dagger}\) (final verification score at termination averaged over tasks), \(\bar r\) (mean retries per committed step), wall (mean wall-clock per task in seconds).

9.4.0.1 False completions vs.honest halts.

Two failure modes must not be conflated. A false completion records progress that does not exist: the narrative claims success, downstream steps build on an invalid state, and the error surfaces later at higher cost. An honest halt is a run that exhausts its retry budget with \(V < 1\) and reports exactly that, surfacing the unsatisfied predicates to the operator. The unwrapped condition can only fail as the former; HCRC converts residual failures into the latter. Where the wrapped condition in Table 4 reports non-zero FCR (the mid-tier GPT and Claude rows), the cells are dominated by retry-budget exhaustion on tasks the proposer could not solve within \(\bar r_{\max}\); the gate never certified those states, and the accompanying evidence log identifies the failing predicates. Under a stricter scoring that counts only gate-certified success claims, wrapped FCR is \(0\%\) by construction (Theorem 2); we report the conservative number to keep the two conditions comparable.

4pt

9.5 Smoke test on SWE-bench Lite↩︎

To check that the FCR collapse of §9.4 is not an artefact of our task generator, we ran a preliminary smoke test on SWE-bench Lite [40] with a hard \(15\)-minute wall-clock cap per model. We loaded the first \(10\) test-split instances of princeton-nlp/SWE-bench_Lite via the HuggingFace datasets loader and reduced each instance to a lightweight visible-predicate set—file_exists and parses on every ground-truth patched file—with the hidden test_passes predicate suppressed because we do not clone the underlying repositories. The proposer is shown only the issue text and the expected file paths, and we then run the harness in the same two conditions as Table 4 across four proposers, stopping cleanly the moment we would exceed the cap.

3pt

On the two strongest proposers (llama-3.3-70B and gpt-oss-120B) HCRC sustains the \(0\%\) FCR collapse at zero extra retries; the 8B model plateaus at \(20\%\) under both conditions because the tight \(\le 2\)-predicate set leaves no slack once its retry budget exhausts on two non-parsing patches (the same retry-exhaustion regime flagged in F1, §10). The gemini-2.5-flash slice was dominated by free-tier rate-limit backoffs and its HCRC cell is unfilled. With these caveats, nowhere does the gate increase FCR, and on capable proposers it preserves the FCR\(\to 0\) collapse on a real, non-synthetic instance set.

10 Results and Discussion↩︎

We now consolidate the experimental record into seven findings. Each is named, supported by a measured number from Tables 4–[tab:gaming] or Figures 18–[fig:plot95vdist], and accompanied by a short mechanistic account. Findings Figure 1 to Figure 4 concern the gate itself; Whereas Figure 5 to Figure 7 concern interactions with the proposer and the pool.

On the Groq and OpenRouter proposers the HCRC condition collapses FCR to zero (or to \(3\%\) on the 8B model, where retries are exhausted on a single task) by Theorem 2; the cost is additional retries and a wall-clock multiplier on weak models. On the OpenAI and Anthropic rows, the wrapped condition halves FCR on the mid-tier models (gpt-4o, gpt-4o-mini: \(40\%\to 20\%\)) and leaves a flat residual on the rest; per the false-completion/honest-halt distinction above, these residual cells are retry-budget exhaustions surfaced with their failing predicates, not silent corruptions. Crucially, a weak proposer under HCRC reaches a final FCR comparable to a far stronger proposer, at the price of more retries. The gate normalizes correctness across proposer capability. Figures 18, 19, and 20 visualize the three resulting effects.

10.0.0.1 OpenAI GPT series.

The seven OpenAI GPT models (gpt-3.5-turbo, gpt-4, gpt-4-turbo, gpt-4o, gpt-4o-mini, gpt-5.4, gpt-5.5) expand the benchmark beyond Groq/OpenRouter. On the mid-tier gpt-4o and gpt-4o-mini, HCRC halves FCR (\(40\%\to 20\%\)) while sustaining \(V^{\dagger}\!\approx\!1\) and a modest retry budget (Table 4). On the strongest GPT variants (gpt-5.4, gpt-5.5) the baseline is already near the gate in verification terms, so the measured residual FCR under HCRC is flat (\(\sim 20\%\)); the cost profile remains acceptable (mean retries \(\bar r \approx 2\)–\(3\)). Figure 22 isolates the GPT family; Figure 24 shows the wall/FCR trade-off across all proposers.

10.0.0.2 Figure 1: The Heaviside barrier holds empirically.

At \(\tau = 1\) with the full Arial pool, the measured false-completion rate is exactly \(0\%\) on groq:llama-3.3-70b-versatile (\(n{=}30\)) and openrouter:gpt-oss-120B:free (\(n{=}25\)), and \(3\%\) on groq:llama-3.1-8b-instant (\(n{=}30\), a single task that exhausts the retry budget). The corresponding final verification score \(V^{\dagger}\) averages \(1.00\) on every model (Table 4, Figure 18). This is tantamount to the prediction of Theorem 2: \(\mathbf{H}(C\cdot V - 1) = 1\) entails \(V = 1\), and soundness (Assumption 1) ipso facto entails that every predicate obtains alethically on the reference state. The two non-zero FCR cells in the entire experiment (\(3\%\) in Table 4 on the 8B model; \(5\%\) in Table [tab:tau] at \(\tau{=}0.85\)) are both explained by the theory: the first in virtue of retry-budget exhaustion (we cap at \(\bar r_{\max}{=}3\)), the second in virtue of the user explicitly lowering \(\tau\) below \(1\) (a deliberate weakening of the barrier). The preliminary SWE-bench Lite smoke test (Table 5) extends this picture to a real-benchmark instance set: HCRC again sustains \(0\%\) FCR on the capable proposers, and the only non-zero cell (\(20\%\) on the 8B model) is again retry-budget exhaustion on the tightest predicate set (two visible predicates per instance, no room for the gate to backstop a stuck proposer).

10.0.0.3 Figure 2: HCRC normalizes correctness across proposer capability.

Unwrapped FCR varies by a factor of \(\approx 2\) across proposers: \(4\%\) on gpt-oss-120B, \(7\%\) on both Llama models, \(9\%\) on gemini-2.5-flash. Under HCRC, the residual FCR collapses to a flat \(0\)–\(3\%\) floor that is essentially independent of model strength (Figure 19). The 8B model under HCRC (\(3\%\)) is closer to the 120B model under HCRC (\(0\%\)) than the 8B model is to itself unwrapped (\(7\%\)); the gate is a stronger lever than swapping the proposer for a \(14\times\) larger one. Mechanism: the gate is the deciding authority, not the model. Conditional on eventually generating a passing artifact, the proposer’s role is reduced to a search procedure; how many retries it takes is the only remaining axis on which capability is visible (8B: \(1.2\) retries, 70B: \(0.8\), 120B: \(0.04\); Table 4).

10.0.0.4 Figure 3: HCRC can be faster than the unwrapped LLM on capable models.

The expected cost story is “the gate adds retries, so wall-clock goes up.” This is not what we measure on capable proposers. On groq:llama-3.3-70B, the unwrapped condition averages \(11.9\) s per task while HCRC averages \(5.3\) s (\(-56\%\); Figure 20). The same effect, smaller in magnitude, shows on the 8B model (\(11.5\) s \(\to 10.0\) s, \(-13\%\)). Mechanism: when \(V\) reaches \(1.0\) on the first attempt which is the modal case for a capable proposer the gate commits immediately and terminates the step. The unwrapped LLM has no such early stop: it continues to produce a fluent epilogue (rationale, summary, footer) before reporting completion. The HCRC condition is structurally faster on tasks the model would have solved anyway, and is only slower when retries actually fire. On gpt-oss-120B the gate adds \(+22\%\) wall-clock (\(19.3\) s \(\to 23.5\) s) because the per-call latency on the free-tier OpenRouter endpoint dominates and the model never retries.

10.0.0.5 Figure 4: Threshold tuning is non-monotonic; \(\tau{=}1\) is the only safe setting.

The threshold sweep (Table [tab:tau], Figure [fig:plot95thresh]) shows a clean \(0\%\) FCR at \(\tau \in \{0.5, 0.7, 0.95, 1.0\}\) but a \(5\%\) leak at \(\tau = 0.85\). The leak is reproducible and explained by the geometry of the gate: at \(\tau = 0.85\), tasks with \(C \approx 0.9, V \approx 0.95\) (one predicate failing on a 7-predicate set) yield \(C\cdot V \approx 0.86 > \tau\) and clear the gate. Lowering \(\tau\) further (\(0.7, 0.5\)) does not increase FCR on this task pool because the failing predicate happens to be one that the proposer satisfies anyway by the final commit, so the apparent FCR depends on which predicate the gate happens to elide. The lesson is that any \(\tau < 1\) admits a corruption set that depends on the predicate-failure geometry of the workload, and the empirical FCR at \(\tau \in (0, 1)\) is not monotonically increasing as \(\tau\) decreases. Only \(\tau = 1\) realizes the Heaviside barrier of Theorem 2. Advisory predicates can be packed at lower weights below \(\tau\), but every mandatory predicate must contribute under a gate at \(\tau = 1\).

10.0.0.6 Figure 5: Capable proposers do not exploit visible predicate sets.

We hypothesized that exposing the predicate list to the model would let it write minimal stubs that satisfy visible checks while failing hidden ones (Sec. [sec:gaming]). On groq:llama-3.3-70b-versatile (\(n{=}25\)), the measured gaming rate is exactly \(0\%\) (Table [tab:gaming]): every task produces an implementation that also passes the held-out hidden tests (\(V_{\text{hidden}} = 1.00\)). Mechanism: a model trained on real code has a strong prior toward writing real implementations even when given the test specification; the cheapest fluent completion is a working one. Caveat: this is measured only on a strong proposer in a controlled task family. A weaker or adversarial proposer may exploit visible predicates, in which case the hidden-included condition of Table [tab:gaming] (with its modest \(\bar r = 0.8\) retry overhead) is what enforces the barrier. Hidden predicates remain part of the threat model.

10.0.0.7 Figure 6: Worker pool composition matters less than expected on strong proposers, but the Validator–Tests pair carries the load.

On groq:llama-3.3-70B, FCR is identically \(0\%\) across all five pool compositions (Validator only, Validator+Syntax, Validator+Tests, Validator+Syntax+Tests, Full; Table [tab:ablation], Figure [fig:plot95worker95ablation]). Mean retries \(\bar r\) rises from \(0.03\) (Validator only) to \(0.63\) (Full pool); the Validator+Tests pair already covers the failure modes the proposer is capable of (the Tests worker catches the rare case where filesystem predicates are satisfied but the hidden command_succeeds runner fails). The Syntax Guard and Citation Guard never contribute a halt on this model because the proposer’s output is already syntactically valid and grounded. We expect their value to be visible on weaker models or on tasks where the proposer hallucinates citations; this is consistent with the residual \(3\%\) on the 8B model in Table 4, where Citation halts were recorded.

10.0.0.8 Figure 7: Epistemic entropy decays monotonically only under HCRC.

Across \(n{=}8\) five-step missions on groq:llama-3.3-70B, the unwrapped LLM and HCRC agree on the first committed step (because both pass on the first attempt; \(S_e \approx 0.066\)) but diverge thereafter (Figure 21). HCRC drives \(S_e\) from \(0.066\) at step 1 to \(0.031\) at step 4 with monotonic decrease and very small variance (\(\sigma \leq 0.002\) at every step). The unwrapped LLM plateaus between \(0.05\) and \(0.07\) with much larger variance (\(\sigma\) up to \(0.030\)). Mechanism: HCRC is forced to drive \(V \to 1\) at each commit, so \(S_e = 1 - V\) inherits a downward staircase. The unwrapped LLM has no such forcing: when it claims success at \(V \approx 0.95\), it terminates, leaving residual entropy. This is the per-step entropy-reduction guarantee of Theorem 3 made visible

10.0.0.9 Summary across Figure 1 and Figure 7.

The seven findings are not independent: Figure 1 is the structural finding, Figure 2 is its corollary across model scales, Figure 3 is the surprising cost story, Figure 4 is the boundary of the structural finding, and Figure 5 and Figure 7 are interactions with the proposer and pool. Together they describe a control wrapper that has not just collapsed FCR on every tested proposer, but has done so without paying the wall-clock tax one would normally expect, and has done so consistently across \(\sim 250\) runs spanning three providers and five task families.

10.0.0.10 Discussion.

The central finding is structural: the right object to control around an LLM is not the model’s own confidence but a Heaviside step over an external verification score. The model is reduced to a proposer; progress is defined by non-LLM evidence. Within the scope of \(\mathcal{P}\), the system cannot record progress that does not exist.

11 Production Deployment: The Coefficient↩︎

The preceding sections evaluate HCRC under harness conditions. Since early 2026 the framework has also run as the production control plane internally, the Coefficient of Chalk, an agentic coding environment developed at Mankind Research Labs, wrapping interactive missions issued by a developer against live repositories. Deployment forced three extensions that we report here because each generalizes beyond the host application; none modifies the theory of Sections 4–6, and each inherits its guarantees from the same gate. Figure 26 situates the three: the pool is sized by an execution profile (left), and the gate’s verdict is the sole authority for three downstream surfaces the interface, version-control provenance, and the memory compactor (right).

11.1 Hardware-indexed execution profiles↩︎

Verification breadth costs compute, and interactive users hold heterogeneous budgets. The deployment therefore exposes execution profiles: named configurations that size the Arial pool, the DAG parallelism available to the proposer’s tool batches, and the context budget, indexed by the hardware class the user selects. Table 6 lists the shipped profiles. The controller consumes the profile as a runtime parameter; the gate condition (Eq. 1 ) is unchanged, so Theorem 2 holds at every profile a lean profile verifies fewer predicates per unit time, never fewer predicates per commit. Figure 27 visualizes the constraint that makes the profile system sound: pool width varies by a factor of \(3.5\times\) across profiles while the commit threshold is a horizontal line. The profile system operationalizes a trade that Section 10 Figure 6 measures only implicitly: on strong proposers a small pool already carries the load, so lean profiles are cheap; on weak proposers the wider pools recover the halts that Figure 6 attributes to the Citation and Syntax workers.

11.2 Verification-slaved interfaces↩︎

A gate that halts silently while the interface reports progress reintroduces the failure it exists to prevent, one layer up. The deployment therefore adopts a single interface invariant: no surface may claim more than the gate has committed. Three consequences follow. Progress indicators are bound to predicate outcomes rather than timers the application-launch sequence, for instance, holds below completion until a liveness predicate (a port response for web targets; process existence for desktop targets) evaluates true, and only then reports the application alive. Per-mission reports surface the gate’s ledger directly: predicates passed and failed, commits versus halts, and the mission’s measured FCR. And step-level visualizations tick only on worker verdicts, never on proposer claims. In months of daily use this invariant has proven to be the deployment’s most consequential design rule: users calibrate trust to the interface, and an interface that inherits the barrier property is one the user can calibrate against. Figure 28 renders the launch sequence as the state machine it is: the count eases toward and holds at \(99\%\) while the liveness predicate evaluates false, and only a true evaluation releases the final percent.

11.3 Gate-licensed memory compaction↩︎

Long interactive sessions accumulate context whose majority is dead weight: narratives of concluded missions, superseded file reads, resolved failures. Compacting this context with model-written summaries reintroduces the self-judging pathology of Section 2 in the memory channel a model that launders its failures into its own permanent record poisons every later mission that trusts that record. The deployment’s compaction engine therefore extends Assumption 2 to memory: eligibility for compaction is licensed exclusively by gate records. A session segment may be replaced by a skeleton record only if its mission committed through the gate; the skeleton is compiled mechanically from the evidence log (predicates satisfied, artifacts touched, FCR), never narrated by the proposer; full bodies are archived, secret-redacted, in an append-only ledger from which any burial can be reversed in one read, and a reversed burial is permanently immune from re-burial. The engine is advisory by default compaction is recommended to the operator, not executed autonomously and instruments a single health vital, the exhumation rate: how often archived context must be recalled. A rate near zero certifies that eligibility rules bury only what was truly dead; a rising rate localizes the eligibility rule that misjudged. Figure 29 traces the lifecycle. Memory compaction thereby inherits the audit properties of the gate itself: every forgetting is licensed, ledgered, and reversible. The design responds to two documented failure modes of long-context operation: models attend unreliably to mid-context material [51], and paging schemes that summarize with the model itself [52] leave the summary channel unverified; gate-licensed compaction removes both by shrinking the context only where records prove the material concluded, with mechanically compiled skeletons.

11.4 Deployment observations↩︎

Three qualitative observations from sustained use. First, the gate makes proposer-side parallelism safe: modern proposers emit batched tool calls that mutate several files concurrently, and post-hoc per-artifact verification bounds the risk of the batch, so deployment can accept the latency win without accepting silent partial failure. Second, retry budgets interact with proposer variance in a way the benchmark does not expose: capable proposers exhibit long verified streaks (consecutive \(\mathbf{H}= 1\) commits) that user-set budgets interrupt mid-run, suggesting budget policies conditioned on the running commit streak rather than fixed caps; we leave this to future work. Third, the framework’s audit artifacts double as provenance: the deployment stamps gate-authorized commits with machine-readable trailers, so downstream tooling can distinguish verified from unverified changes at the version-control layer.

12 Limitations↩︎

12.0.0.1 Predicate completeness.

Theorem 2 bounds only violations of \(\mathcal{P}\). Hallucinations outside \(\mathcal{P}\) semantic correctness, security, performance require additional predicates. We shall relegate this to future work as expansions of this paper.

12.0.0.2 Decidability cost.

Expensive predicates (full test suites, type checkers, formal verifiers) inflate wall-clock; the weights \(w_\bullet\) trade precision for throughput. This is an inherent problem and requires that the totality of costs be known before hand.

12.0.0.3 Predicate gaming.

If the LLM sees the predicate set it may write code that passes them without solving the underlying task; hidden tests are required. We rely heavily on the Heaviside barrier but gamificatio may still get the best of the system to counter this an absolute truth path needs to be established.

12.0.0.4 Progress without commit.

A task may never pass the gate. We cap retries per step and surface to a human operator; the honest-halt accounting of Section 9.4 makes this failure mode explicit rather than silent.

13 Conclusion↩︎

In this research paper we have formalized epistemic entropy for LLM-driven control, and introduced HCRC and the Arial worker pool as solutions, and these proved a structural barrier against a class of hallucinations, demonstrated experimentally that false-completion rates collapse under the gate across thirteen proposers that we have evidently validated and reported a sustained production deployment in which the same gate authorizes file mutations, drives verification-slaved interfaces, and licenses memory compaction. The price is retries; the prize is auditable progress.

Three directions follow directly from deployment. Deeper predicate ladders: the shipped predicates are shallow (existence, parse, containment, command success); the same gate socket accepts type-checking, full test suites, soak-and-leak detection over long-running processes, and packaging checks, turning the barrier into a release qualification. Streak-conditioned budgets: retry and step budgets that extend automatically while the commit streak is verified-hot, with operator consent. Predicate discovery: re-running the controller on SWE-bench-style benchmarks where \(\mathcal{P}\) must be inferred rather than given, closing the gap deliberately held open in Section 9.2.

In conclusion this paper demonstrated a reliable approach at mitigating epistemic entropy. The work is still in a continous state and more testing will be done to mitigate the price of retries. We attest that we have seen quite a substantial reduction of epistemic entropy across a plethora of tasks. The future work is to build on this promising framework.

13.0.0.1 We would like to thank Mankind Research Labs for commisioning this work and providing the necessary resources for testing.

14 Extended Results and Materials↩︎

Model	\(n\)	FCR\(_{\text{U}}\) (%)	FCR\(_{\text{H}}\) (%)	\(V^{\dagger}_{\text{H}}\) (%)	\(\bar r_{\text{H}}\)	wall\(_{\text{U}}\) (s)	wall\(_{\text{H}}\) (s)
Model	\(n\)	FCR\(_{\text{U}}\) (%)	FCR\(_{\text{H}}\) (%)	\(V^{\dagger}_{\text{H}}\) (%)	\(\bar r_{\text{H}}\)	wall\(_{\text{U}}\) (s)	wall\(_{\text{H}}\) (s)
gpt-3.5-turbo	20	45.00	35.00	95.12	2.40	3.41	5.99
gpt-4	20	40.00	40.00	94.40	2.40	3.98	12.01
gpt-4-turbo	20	35.00	30.00	95.50	3.30	4.87	18.52
gpt-4o	20	40.00	20.00	97.50	2.35	3.01	7.14
gpt-4o-mini	20	40.00	20.00	97.50	1.55	2.95	6.58
gpt-5.4	20	20.00	20.00	97.50	2.40	2.82	8.71
gpt-5.5	20	25.00	20.00	97.50	2.30	6.09	19.95
llama-3.1-8B	30	6.67	3.33	99.52	1.23	11.52	10.04
llama-3.3-70B	30	6.67	0.00	100.00	0.77	11.86	5.27
gpt-oss-120B	25	4.00	0.00	100.00	0.04	19.26	23.50
gemini-2.5-flash	22	9.09	0.00	0.00	0.00	21.09	0.00

Model	\(n\)	FCR\(_{\text{U}}\) (%)	FCR\(_{\text{H}}\) (%)	\(V^{\dagger}_{\text{H}}\) (%)	\(\bar r_{\text{H}}\)	wall\(_{\text{U}}\) (s)	wall\(_{\text{H}}\) (s)
Model	\(n\)	FCR\(_{\text{U}}\) (%)	FCR\(_{\text{H}}\) (%)	\(V^{\dagger}_{\text{H}}\) (%)	\(\bar r_{\text{H}}\)	wall\(_{\text{U}}\) (s)	wall\(_{\text{H}}\) (s)
gpt-3.5-turbo	20	45.00	35.00	95.12	2.40	3.41	5.99
gpt-4	20	40.00	40.00	94.40	2.40	3.98	12.01
gpt-4-turbo	20	35.00	30.00	95.50	3.30	4.87	18.52
gpt-4o	20	40.00	20.00	97.50	2.35	3.01	7.14
gpt-4o-mini	20	40.00	20.00	97.50	1.55	2.95	6.58
gpt-5.4	20	20.00	20.00	97.50	2.40	2.82	8.71
gpt-5.5	20	25.00	20.00	97.50	2.30	6.09	19.95

References↩︎