Separate pure plans from released effects

Let planning describe work while effect admission checks exact releases separately.

An agent produces a good deployment plan and immediately begins carrying it out because the steps are already structured. The plan's quality has been mistaken for permission. The technique is to give planning and execution different modes: planning may describe effects purely, while execution requires an exact release for every effect-and-target pair.

01 / State the predicate

Glossary: plan is a value describing proposed work; effect is a world-changing operation; target bounds what the effect may touch; release is an exact effect-target pair; admission is the decision to permit execution. Assumptions: identifiers are canonical and exact, every step is well formed, and release currentness was checked elsewhere. In prose, producing a plan never needs authority to perform its contents, but switching to execution requires coverage for every individual step. Similar effect names or neighboring targets do not count. This formulation does not execute steps, authenticate releases, order dependencies, or roll back effects.

02 / Give the agent a bounded task

Provide a mode, a finite step list, and a finite release list. Ask the agent to classify admission without calling adapters. In plan mode, each check returns planned-only; this is a positive result about purity, not a statement that execution is authorized. In execute mode, every step must find an exact matching release.

Keep the plan as data. A later effect port can receive only the admitted descriptor, while the planner remains deterministic and safe to run during review.

03 / Run the independent check

export function evaluate(input) {
  const validStep = step => step && typeof step.effect === "string" && typeof step.target === "string";
  const valid = input !== null && typeof input === "object" && ["plan", "execute"].includes(input.mode) &&
    Array.isArray(input.steps) && input.steps.every(validStep) &&
    Array.isArray(input.releases) && input.releases.every(validStep);
  if (!valid) {
    return { pass: false, summary: "Invalid plan input.", checks: [
      { name: "input-shape", pass: false, detail: "Expected mode, steps, and releases." }
    ] };
  }
  const released = step => input.releases.some(release =>
    release.effect === step.effect && release.target === step.target);
  const checks = input.steps.map(step => ({
    name: `${step.effect}@${step.target}`,
    pass: input.mode === "plan" || released(step),
    detail: input.mode === "plan" ? "planned-only" : released(step) ? "exact-release" : "release-missing"
  }));
  const pass = checks.every(check => check.pass);
  return {
    pass,
    summary: input.mode === "plan" ? "Pure plan produced; no effects admitted." :
      pass ? "Every effect has an exact release." : "Execution held; at least one exact release is missing.",
    checks
  };
}

Save the module as separate-pure-plans-from-released-effects.mjs, then run:

node --input-type=module -e 'import {evaluate} from "./separate-pure-plans-from-released-effects.mjs"; console.log(JSON.stringify(evaluate({"mode":"plan","steps":[{"effect":"publish","target":"draft-7"}],"releases":[]})))'

Expected result:

{"pass":true,"summary":"Pure plan produced; no effects admitted.","checks":[{"name":"publish@draft-7","pass":true,"detail":"planned-only"}]}

04 / Try the counterexample

Change mode to execute without adding a release. The same descriptive step now fails admission. Add publish@draft-8; it still fails because an adjacent target does not cover draft-7. Only the exact pair passes.

05 / Keep the claim bounded

A planning pass establishes that this function admitted no effect. An execution pass establishes only exact membership in the supplied release list. Neither result proves grant authenticity, expiry, target existence, sequencing, successful execution, or semantic value. Production systems should separate a pure planner, an authority-aware admission boundary, an effect adapter, and attempt receipts.

Source and formulation note

The separation between plans, gates, and effect ports adapts the cited ESS candidate and Exocore architecture sources. The two-mode set-inclusion predicate and JavaScript module are original pedagogical constructions. This article creates no release and claims no current Exocore runtime adoption.