Inside the Epistemic Protocol Machine

The Epistemic Protocol Machine (EPM) bounds what an AI assistant may claim from a simulation on a person's behalf. It certifies that a claim does not reach beyond what its method and verified inputs license. It does not certify that a model is right about the world. This reference sets out the labels, the rules that assign them, what an assistant receives when a request is refused, and the limits of the approach.

Why it exists

A person asks an AI assistant what would happen in a place they care about. The assistant sets up a simulation, runs it and interprets the result. The person usually cannot judge the model, its inputs or its output. Whatever the assistant says is, in practice, what the person learns.

That makes the assistant the weakest point in the chain. A fluent summary sounds like a confident one. The EPM decides what a result entitles the assistant to say. It does not make any model more accurate.

The failure it guards against is epistemic laundering: a weak result passes through several steps and comes out strong. A simulated scenario is compared with a baseline, the comparison is summarized, and the summary is offered as a recommendation. Each step adds confidence; none adds evidence.

The mechanism resembles security labeling, where a label travels with the data and forbids certain operations on it. Here the label describes evidence rather than sensitivity, and it forbids claims the evidence cannot carry.

What the EPM certifies

The EPM does three things.

1. It labels every result that makes a claim with the kind of act that produced it and the strongest claim that act can support.
2. It refuses, with a typed code, any step that would make a stronger claim than its inputs warrant.
3. It ties each label to a content-addressed record of exactly what was used, which a review or a re-run needs.

It does not certify that a model is accurate, that its inputs describe the world correctly, or that an assistant's own sentences are faithful to the result. The EPM labels what the platform returns. The assistant receives the words and limits to use, and the saved record lets a person check what was actually returned.

Where it acts

An assistant reaches the platform only through the Model Context Protocol (MCP). A call that produces a claim passes through the EPM twice.

Before the domain logic runs, the EPM checks that the operations compose, that the method's support is established and that each cited input is valid. The operation then checks its own required inputs. Any failure refuses the call, and no computation starts.

After the domain logic runs, the EPM sets the result's label from the method's fixed entry. A result is published only when every check has passed. Publication is atomic. A result identifies unfinished or failed members and the evidence included in each summary; incomplete work is never presented as a completed experiment.

Grades

A grade names the kind of epistemic act that produced a result. The word is used in the sense of a graded type system, not a quality score.

The grades are partially ordered. OBS is below INT, and INT is below RSN. ACT and LRN both sit above RSN, but neither is above the other.

Two grades therefore have no join: a recommendation and a revision. Any step that would combine them is a type error and is refused before anything runs.

Claim strength

Claim strength is a ladder from CS0 to CS4. Each level carries the verb the assistant is told to use, and the browser shows the same words.

The levels are ordered qualifications. They are not probabilities and not error bounds.

Labels

A label pairs a grade with a claim strength. Each grade admits only a window of strengths.

That gives twelve labels, written as grade and strength together, such as INT:CS1. A pair outside its grade's window cannot be constructed.

Labels are ordered by both parts. One label sits below another when its grade and its strength are each at or below the other's. A label is fixed once a result is published.

The ten operations

Each operation declares the grades it accepts as input, a ceiling on the label it can produce, and the lower labels it may produce instead. A ceiling is an upper bound, not the label results receive.

Each operation also states what it does not establish.

Composition

One operation's result can be cited as input to another. A result of one operation may feed a second only when two conditions hold. Every grade the first can produce must be accepted by the second. Each of those grades must also join with the grade of the second operation's ceiling.

Ten operations give a hundred ordered pairs, self-pairs included. Fifteen fail the check. A call along one of them is refused before anything runs, with one narrow exception described below. The graph and matrix below show every pair, and group the refused pairs by the reason they fail. The figure also works through three permitted example chains and one refused shortcut, from a single run straight to CHOOSE, and each can be played on the graph.

All 100 pairs15 blocked85 permitted

permittedblockedarrows run from producer to consumer

Hover over or select a primitive to see what it can feed, then hover over a line for the reason.

EXAMPLE CHAINS

Compare designs, then recommend one

A person wants to know which of several designs for a street works best for them.

1. CHECKOBS reads current conditions in the place, such as traffic on the street today.
2. IMAGINEINT specifies each design as a counterfactual scenario.
3. EXPLOREINT runs each scenario over a stated horizon. A run suggests; it does not show what will happen.
4. COMPARERSN computes the differences between the runs, within the model.
5. CHOOSEACT ranks the designs under the objectives and constraints the person declared. The ranking is a recommendation, not a decision.

Play on the graph

Attribute a difference

A person wants to know what a change does to journey times, and why.

1. IMAGINEINT specifies the change, for example closing one street.
2. EXPLOREINT runs the scenario with and without the change.
3. COMPARERSN computes the difference in journey times between the runs.
4. EXPLAINRSN attributes that difference under stated identification assumptions. The attribution holds only under the causal structure it was given.

Play on the graph

Check variation, then propose a revision

A person wants to know how much a result depends on chance within the model.

1. EXPLOREINT runs the scenario many times.
2. GAUGERSN assesses how much the results vary within the method. That spread is evidence about the model, not a confidence interval.
3. ADAPTLRN proposes a revision bound to that evidence. It does not apply the change.

Play on the graph

A shortcut the check refuses

EXPLORE → CHOOSE

A single simulation run cannot be turned straight into a recommendation. CHOOSE does not accept interpretation-grade input, so the runs must be compared first. The call is refused before anything runs.

Show on the graph

producer, then consumer	CHECK	SEEK	MONITOR	IMAGINE	EXPLORE	COMPARE	EXPLAIN	GAUGE	CHOOSE	ADAPT
CHECK
SEEK
MONITOR
IMAGINE
EXPLORE
COMPARE
EXPLAIN
GAUGE
CHOOSE
ADAPT

WHY CONNECTIONS FAIL

09

OBS → EXPLORE / EXPLAIN / CHOOSEThe consumer excludes observational inputs.

04

INT → EXPLAIN / CHOOSEInterpretation-grade output is not an accepted input grade.

01

CHOOSE → ADAPTACT and LRN have no defined grade join.

01

ADAPT → CHOOSECHOOSE excludes the learning/revision grade.

These rules govern direct connections between operations. They do not rule out observations within a causal analysis. The one exception is that some EXPLAIN methods accept CHECK readings, but only readings that the method's own verification qualifies exactly.

When a call cites several results, the method making the call checks each one against its own requirements. Grades are never flattened into a ranking: a recommendation and a revision have no combined grade, and no step treats either as the higher.

The check covers one connection at a time. A chain of permitted pairs does not, by itself, establish that the whole chain is relevant or that its evidence is independent.

How a result receives its label

Every result names the method that produced it. Each method carries a fixed label within its operation's ceiling. Each label is recorded with a written rationale: the proposition the label licenses, what must hold for it, and what it does not establish.

The method's label is granted only when its support is established. Support means the inputs the method requires are present, verified and usable for this purpose. If support is not established, the request is refused; a simulation run is the one exception, described below. Stronger support never raises the label. Repeating, rearranging or re-citing the same inputs cannot raise it either.

A later step can carry a different claim strength from its inputs, because it makes a different claim. A comparison of two runs, for example, states a difference between them within the model. Its label is fixed for that method in advance. It is not the earlier claim made stronger, and the earlier result keeps its own label.

A qualified simulation method whose declared label is INT:CS1 returns “suggests” when its evidence requirements hold. An unreviewed authored model retains its calculations with no claim; successful numerical checks and approval to run do not supply scientific review. A run in which any step did not establish that its method applied completes and keeps its numbers, but carries no claim label and says why.

No method reaches CS4. A recommendation from CHOOSE carries CS3, because the recommendation grade admits only CS3 and CS4. Its "strongly indicates" reflects that window, not stronger evidence than a comparison has.

What a label rests on

A label rests on three things: the method that produced the result, the provenance of its inputs, and checks that the method applied to them. Other qualities matter but do not enter the label.

Applicability, for a simulation run, is execution integrity. It shows that the declared model ran as declared. It does not show that the model's physics holds in the place being simulated.

So INT:CS1 on a run reads as "this declared model, run as declared on these inputs, suggests X". Every result states its basis: a model's output, or values read from a named source. It also lists what it does not establish, such as real-world observation, prediction accuracy or quantitative uncertainty.

The same holds further along a chain. A reading of a run's output stays a reading of a model when it is cited later. It cannot re-enter a chain as an observation of the world. An EXPLAIN result about a simulated effect describes the model's response to an intervention. Whether the same mechanism operates in the place is a question the label does not answer.

Refusals and typed codes

A refusal is a decision, not a fault. It records why a request cannot proceed under the evidence and authority rules. An execution error records a computation that failed. The two are reported differently.

Every refusal carries a typed code, such as COMPOSITION_CHAIN_REFUSED, GUARD_REFUSED or EVIDENCE_PROPOSITION_INVALID. Over MCP the assistant receives the code, a fixed sentence and a structured explanation. The explanation names:

• the operation that refused;
• the conditions that failed, drawn from a fixed vocabulary;
• a short account of the limit, and the steps that would remedy it;
• where they are known, the label requested and the label the cited evidence supports.

Some things are withheld. Identities of cited evidence never appear in a refusal. Evidence that does not exist cannot be told apart from evidence the caller may not see. A failure that publication checks catch is reported only as a result that did not pass evidence checks.

A refusal can be examined, but it never counts as evidence. A call that cites a refusal in support of a new claim is itself refused.

Results without a claim

A call can succeed without making a claim. A simulation run in which some step did not establish method applicability completes and keeps its numbers. In place of a label, it states that no claim is established, the reasons, and each affected step with its own reasons.

The assistant reads this status when it opens the run. The person's browser shows it as a sentence in place of the claim. The standing instructions every assistant receives say to honor grades and limits, and that a successful run proves no predictive accuracy.

Provenance and evidence validity

A label is only as good as the claim that its inputs are the ones that were checked. Every result is a content-addressed record, and its inputs are bound by content digest. A new claim can rest only on inputs that are valid as evidence and that the person may use. Revoked access to a source refuses any new claim that would rest on it.

A published result never changes, but its usability as evidence can be withdrawn. Every retained proposition carries one of four statuses: current, superseded, invalid_for_composition or unverifiable. When a method is found to be flawed, its results stay readable, but the affected propositions are marked invalid_for_composition. No new claim can cite them.

Validation: a separate track

Comparison with observed data is recorded on a separate track, called empirical reliability. It never changes a label, in either direction. A passing comparison does not raise one, and a failing comparison does not lower one.

An assistant can request a comparison of a prediction with an observation. The person reviews it in the browser before its outcome is shown. Approval publishes the comparison whatever the outcome.

Comparisons use thresholds from the published literature. Two examples:

• Traffic counts use the GEH statistic. Each count passes at GEH of 5 or less, and a set needs a pass rate of at least 85%. Both thresholds follow the FHWA Traffic Analysis Toolbox, Volume III.
• Flood extent uses the critical success index, which must reach at least 0.5, after Bates and De Roo (2000).

The owner of a dataset can withdraw or correct an exact version of it. Comparisons that used that version stop counting. The version's bytes and the earlier assessments are kept.

Limits of the approach

The EPM bounds claims on an ordinal scale. It is not a theory of model error.

• Labels are ordinal. No claim strength is tied to an error bound. A label says how far a claim reaches beyond its method and inputs, not how close a model is to the world.
• Validation is reported alongside the method’s claim label. Passing a comparison does not automatically raise that label; scientific review remains bound to its stated model and use.
• Each fixed label is a judgment. Its rationale is written down, but no formal criterion fixes which label a method receives.
• Applicability is execution integrity. A label does not establish that a place lies inside a model's region of validity.
• The operation-type rules do not guarantee convergence of iterative reasoning. Feedback experiments separately declare their exchange scheme and assess its numerical behavior.
• The EPM labels what the platform returns. It cannot check every sentence an assistant writes about a result.

Read the public EPM explanation · Return to the technical reference

Evidence through a coupled experiment

An experiment retains the exact approved scope, child-run identities, dependencies and transformations between components. Derived inputs remain within that authority. Retried or resumed work keeps completed source evidence and cannot publish an inconsistent combination of component states.

Parameter samples, initial conditions, stochastic seeds and declared dependencies travel with composed ensemble members. Failure accounting states which members entered each summary. Numerical, parameter, stochastic and structural uncertainty remain distinct; no downstream operation inherits a stronger scientific standing merely because its inputs were combined.

An assistant prepares a scientific review and an authorized human reviewer approves it. The decision binds an identified structure, parameters, applicability and current reviewer authority. A review of a component is separate from review of the mapping or exchange rule. The claim ceiling remains constrained by the actual evidence and every participating operation.