JExec

Pre-Execution Admissibility

JExec makes execution answerable
before it becomes irreversible.

JExec defines whether an intended execution is admissible before it mutates state — for AI agents, CI jobs, scripts, workflows, and infrastructure actions that change real systems.

The thesis

Modern automation has invested enormously in what happens after execution: logs, traces, alerts, postmortems. All of it describes mutations that already happened. The volume and autonomy of execution — especially agentic execution — has made the older question urgent again:

Is this execution admissible before it mutates state?

Not “can it run” — credentials answer that. Not “did it run” — logs answer that. Should this specific execution, by this actor, under this authority, at this scope, with this evidence, at this risk, be allowed to change the world? JExec names that decision boundary, structures the decision, and defines the record it must leave behind.

The seven questions

Every JExec decision evaluates an intended execution against seven questions. Together they are the JExec model; each maps to fields of the JExec Record and to failure classes in the ontology.

#QuestionAsksFailure classes
1IntentWhat is this execution trying to do?EAF-1
2ActorWho or what is requesting it?EAF-2
3AuthorityIs the actor authorized — verifiably, for this?EAF-3, EAF-4
4ScopeWhere will it apply, and where will it stop?EAF-5
5EvidenceWhat supports admissibility, and is it current?EAF-6, EAF-7
6RiskWhat can it change or damage — and can that be undone?EAF-8, EAF-9
7DecisionWhat is the verdict — and will a record of it exist?EAF-10

The system

JExec is one system with five governed parts. Each part exists because removing it re-opens a failure class.

PartWhat it fixes in place
Ontology (EAO)The ten ways an execution fails to be admissible. The language of the category.
Standard (JAS)Four levels, A0–A3, grading how governed a system’s executions are. The measure of the category.
ProtocolThe decision sequence and the explicit rules mapping failures to verdicts. The procedure of the category.
RecordThe structured artifact every decision must leave behind. The memory of the category.
CheckA deterministic engine that runs the protocol against an intended execution and emits a record. The proof that the system operates.

Why now: agents changed the boundary

When every execution originated with a human, the admissibility decision lived implicitly in that human. Agentic systems break the assumption: an AI agent can form intent, select tools, and mutate state faster than any review process built for humans. The answer is not slower agents. The answer is a decision boundary that is explicit, structural, and recorded — one that treats a human operator, a CI job, and an autonomous agent as the same kind of subject: an actor whose intended execution must be admissible before it runs.

JExec is deliberately positioned between existing systems, not over them. Use SLSA for provenance, Sigstore for signing, OPA for policy evaluation. JExec defines the admissibility decision those systems can inform — and the record it must produce.

What “to JExec” means

To JExec an intended execution: to test whether it is admissible before it runs.

Start here

Read the ten failure classes. Grade your own pipeline against the Standard. Then take one real, intended execution — today’s riskiest deploy, your agent’s most destructive tool — and run it through JExec Check. The verdict takes two minutes. The record is yours to keep.

JExec is an early, governed specification (draft v0.1). It claims no adoption, no certification authority, and no enforcement role — see the claims policy. What it claims is smaller and harder: a precise definition of a decision most systems currently make by accident.