JExec

JExec / Execution Admissibility Ontology / EAF-7

Admissibility failure class

EAF-7 — Stale Evidence

Evidence exists — but it describes a system, artifact, or moment that no longer exists.

ESCALATE stale evidence behind an irreversible mutation
WARN stale evidence behind a reversible mutation

Definition

The execution carries evidence that was valid once and is treated as valid forever: last week’s approval for today’s changed diff, test results from a different artifact hash, a review of a plan that has since been revised.

Stale evidence is more dangerous than missing evidence because it looks like diligence. The record is populated; every field passes a presence check; and none of it describes the execution that is about to run.

How it appears

Across actors

Agent

A human approves an agent’s five-step plan. By step four, earlier steps have changed the environment; the approval now describes a world that no longer exists, and step five mutates the new one.

CI / pipeline

A deployment reuses the green test run from build 4112 while shipping build 4127.

Human operator

A change board approves a migration for Saturday; it runs the following Thursday against a database three schema versions later.

Why it defeats admissibility

An admissibility decision is about a specific execution at a specific time. Evidence decays as the diff, the artifact, or the environment changes — and it decays silently, because nothing in most systems invalidates it. The boundary must therefore ask not “is evidence present?” but “does this evidence still describe this execution?”

Remediation

In the JExec Record

Primarily affects: evidence. The JExec Protocol maps EAF-7 to the consequences above; JExec Check detects it deterministically and links back to this page.

Related classes

EAF-6 Missing Evidence · EAF-10 Unrecorded Decision