ZeroModel
ZeroModel is a working system for building AI decision flows that preserve enough structure to inspect what was claimed, what evidence supported it, what policy allowed it and what actually happened.
The problem
A model response is not the same thing as a justified decision, and a successful action is not proof that the reasoning that produced it was sound.
Production AI systems often collapse several distinct things into one prompt-response trace:
- what the model claimed;
- what evidence was available;
- what the application inferred from that evidence;
- which policy allowed an action;
- what state actually crossed the action boundary;
- what failed, was rejected or remained uncertain.
That compression makes a demo easy to build and a real system difficult to inspect.
The solution
ZeroModel treats evidence, claims, decisions and bounded actions as explicit artifacts rather than incidental text inside a model conversation.
The important distinction is not simply AI versus deterministic code. It is between a system that can explain its own decision boundary and one that cannot.
A useful operating model is:
observation
↓
evidence
↓
claim
↓
policy / authority
↓
decision
↓
action
↓
recorded outcome
Each transition can preserve enough information to answer a different question later.
What it preserves
A mature evidence-first flow should make it possible to distinguish:
- an exact state from a merely action-equivalent state;
- a supported claim from an unsupported one;
- a proposed action from an authorized action;
- a rejected outcome from an absent outcome;
- deterministic policy from nondeterministic generation;
- replay of a decision from regeneration of a model answer.
Those distinctions are the basis for debugging, evaluation and safe automation.
Why this matters
Without explicit boundaries, failures become difficult to localize. A bad outcome may have come from retrieval, interpretation, policy, authority, execution or stale state, yet the application exposes only the final model text.
ZeroModel makes those layers inspectable so that reliability work can target the mechanism that actually failed.
Evidence and validation
The system is designed around replayable state, explicit decision artifacts and preserved failure information. The relevant test is therefore not whether the model sounds confident. It is whether the application can reconstruct the decision path and determine which evidence and policy were load-bearing.
This is also the standard future book-backed solutions should meet: the implementation should expose enough evidence to tell whether the proposed mechanism actually improved the system.
Relationship to the books
ZeroModel predates the new book → capstone → solution publishing contract, but it demonstrates the destination.
Ideas developed in the reliability, hallucination, agent and architecture books can feed into ZeroModel when they survive experimentation. Conversely, concrete failures discovered while building ZeroModel can become research questions for future books.
That creates the same loop from the opposite direction:
working system
↓
real failure
↓
research question
↓
book / experiment
↓
improved system
Use it
The live project is available at zeromodel.org. The solution page on Programmer.ie is the durable explanation of the problem and architecture; the project itself is where the ideas become operational.
What comes next
As the solution library grows, this page can absorb focused articles on decision artifacts, evidence boundaries, replay, policy separation and failure provenance. Those posts should deepen individual mechanisms without fragmenting the canonical solution.