The Deterministic Core — Brandon Bell

🌓<br>← Portfolio

Publication · 2026

The Deterministic Core:<br>A Fixed Foundation for AI Collaboration

Don't correct drift. Prevent it.

Brandon Bell<br>Brandon Bell Systems<br>June 2026

This paper defines the Deterministic Core Architecture as a transferable design pattern, documents its production reference implementation across six artifacts, and establishes a taxonomy of the architectural primitives that enable it. The pattern is not theoretical. It is not projected. It is shipped. The methodology transfers.

Section I<br>The Loop

The engineer patches a defect, runs an audit, receives a score. Applies thirty fixes. Runs another audit. The same model returns a lower score. Opens a new session. Three models rate the build 8.5 out of 10. A fourth rates it 5.5.

The scores are not measuring quality. They are measuring distance — from each model's internal, implicit, and mutually inconsistent standard of completeness. None of these standards were declared. None can be inspected. None agree.

This is the perpetual audit spiral. Every review identifies new gaps. Closing gaps reveals more gaps. The surface area of "not quite done" expands faster than it can be closed. The model cannot recognize completion — not because the build is incomplete, but because completion is not a state the model's architecture can represent. The model is optimized to find what could be improved. Without a fixed baseline, improvement has no terminus.

The loop has no exit condition. The only way out is to stop asking the model whether the work is done, and to start telling it what done looks like.

This is not a failure of any particular model, provider, or prompting strategy. It is an architectural inevitability. The model enters each session as a blank slate — no persistent identity, no fixed standard, no ground truth beyond its training distribution. It measures against what it has seen, not against what you have declared. Without identity, coherence is borrowed from context. When context shifts — new session, different model, fresh conversation — coherence fractures.

The reader who has lived this loop recognizes it immediately. The reader who hasn't now knows what to look for.

During the review of this paper, the author submitted a publication-ready draft to six models for critique. Five independent audit models, applying a fixed standard of 'publication-ready,' classified roughly 83% of the feedback as noise — optimization without an exit condition. The loop described in Section I is not a hypothetical. It was observed during the preparation of the paper that names it.

Section II<br>The Diagnosis

Statelessness is the root cause.

Large language models are deployed without persistent identity. They enter every conversation unburdened by history, optimized to be agreeable and helpful. This is not an accident. It is the dominant architectural paradigm. Every major deployment platform operates this way. Every API is stateless by default. Every conversation begins from zero.

But a system without identity cannot maintain coherence across sessions, across models, across contexts. What we call "drift" or "hallucination" is frequently the predictable output of a coherent system being asked to be coherent with something it cannot see: a stable self, a fixed standard, a ground truth that persists beyond the current interaction.

The industry's response has been to add constraints. More guardrails. More alignment training. Larger context windows. More reinforcement learning from human feedback. Each intervention is reasonable in isolation. But constraints without identity create a structural tension: the more you constrain a system that has no self to be coherent with, the more fragile it becomes under pressure. Each constraint adds another optimization vector. The model balances them as best it can, distributing attention across orthogonal objectives with no unifying identity to reconcile them. Under sufficient load — a complex task, an ambiguous prompt, a novel scenario — coherence fractures.

The fracture is not a bug. It is the predictable output of a system forced to optimize competing objectives without a self to anchor to.

The problem is architectural. The solution must be too.

Section III<br>The Pattern

A deterministic core is not a constraint on the LLM. It is an identity the LLM operates from.

The core is a fixed computational foundation that functions identically with or without AI. Every calculation, every threshold, every scoring formula, every business rule is explicit and invariant. The LLM never touches the computation layer. It operates on top of it — enriching, contextualizing, generating narrative, surfacing insight — but always from a foundation that cannot shift.

This inverts the standard integration pattern. Instead of asking "how do we constrain the AI to produce correct output?", the architecture asks "what environment must the AI operate within such that deviation is structurally...