Planning invariant

A proposed reproducibility contract: every official plan remains attached to the declared decision context, calculation method, and authority path that produced it.

Operator definition

A plan is not only a set of quantities and dates. It is the result of a particular view of reality, a particular set of rules, and a particular calculation. Remove that context and the plan becomes an orphaned answer.

The planning invariant is Vista's proposed name for the dependency that should never be broken. An official plan must be reconstructable from the accepted state, demand, candidate and usable supply, policies, constraints, lead times, commitments, objective choices, horizon, uncertainty controls, overrides, and versioned calculation engine that produced it.

It must also show how a recommendation became an approved or published plan.

The plan itself is allowed to change. In fact, it should change when reality or policy changes. What must remain invariant is the evidence relationship between the result and its causes.

Why it matters

When two plan runs disagree, the organization needs a better answer than "the system changed it." The planning invariant turns disagreement into diagnosis:

Did on-hand or open-order state change?
Did demand change?
Was a receipt excluded or a substitute approved?
Did a policy, priority, service target, or time fence change?
Was a new commitment recorded?
Did the engine, solver, model, or configuration change?
Did a human accept an override?

That decomposition builds confidence without pretending the future is certain. It also gives AI a safer operating surface. An agent may investigate, explain, or propose a scenario, but the official result still has a named context, engine, and authority trail.

The planning physics

Epistemic status: Vista interpretation and proposed architecture standard, built from established planning and provenance practices. The phrase is not presented as settled supply-chain nomenclature.

The review standard for this entry is semantic, not keyword-based. The public evidence should support the concepts underneath the term: provenance of a generated result, computational reproducibility, run lineage, baseline and change control, decision-dependency modeling, planning inputs, and authority. The absence of the exact phrase in existing sources is part of the claim boundary.

Planning invariant recipeannotated formula

Plan = f(state, demand, supply, policies, constraints, lead_times, commitments, engine_version)
C = (X, D, S, Π, K, L, M, O, H, U)
R = Calculate(E_v, C)
P = Publish(G_a, R, C)

ContextAccepted state, demand, supply, policy, constraints, lead times, commitments, objective, horizon, and uncertainty.EngineThe versioned calculation method: solver, model, configuration, and tolerances where relevant.ResultThe recommendation or plan output generated from the declared context.AuthorityThe publication path that turns a result into an official or consequential plan.

A stronger implementation form gives each ingredient a durable identity:

C declared decision context
X accepted state
D governed demand
S candidate and usable supply
Π policy
K constraint set
L lead-time and calendar logic
M existing commitments
O objective and risk posture
H horizon and time structure
U uncertainty representation, scenario set, seed, and tolerance where relevant
E_v calculation engine and version
G_a authority process that publishes the result

Reproduction does not always mean bit-for-bit identity. Deterministic rules may support exact replay. Optimization may require equality within a declared numerical tolerance. Stochastic methods may require the same scenario set or random seed. Multiple-optimum or parallel methods may require equivalent feasibility and objective performance plus preservation of the accepted solution.

Simple example - invariant difference view

Run A recommends releasing 600 units on June 22. Run B, calculated the next morning, recommends 840 units on June 20.

Release recommendation changeplan-recipe explorer

All inputs

The changed action is attributable, not mysterious.

The release grows by 240 units and moves earlier because demand, supply timing, and lead time changed. Policy, capacity, and engine configuration did not explain the change.

Invariant input	Run A	Run B	Effect on plan
Demand D	No new firm customer order in the accepted cut.	New firm customer order accepted overnight.	+120 units of release quantity is attributable to governed demand.
Supply timing S	Supplier receipt available before the release need.	Supplier receipt moved five days late.	+120 units must be released because usable supply moved out of reach.
Policy and capacity Π / K	Policy and capacity assumptions are active.	Policy and capacity assumptions are unchanged.	0 units attributed to policy or capacity drift.
Lead time L	Prior lead-time parameter supports June 22 release.	Lead-time parameter increased by two days.	Date moved earlier from June 22 to June 20.
Engine and configuration E_v	Engine and configuration version recorded.	Engine and configuration unchanged.	Same method; the engine did not silently explain the difference.
Publication state G_a	Prior recommendation remains a comparison parent.	Planning manager approved Run B.	Authority recorded; the result became the official plan through a named path.

A user does not have to trust a mysterious recalculation. The changed action is tied to changed demand, changed supply timing, changed lead time, unchanged method, and a recorded publication decision.

What goes wrong without it

Teams compare outputs without comparing the contexts that produced them.
Engine upgrades silently change quantities, dates, or allocations.
A scenario is mistaken for the baseline.
A manual override disappears into a spreadsheet or meeting note.
Archived output is mistaken for replayable evidence.
An AI explanation invents a plausible cause because the causal record was never stored.
Users lose trust and recreate the plan outside the system.

How it shows up in high-consequence supply chains

A medicine allocation, named-patient treatment slot, strategic-stockpile release, grid-spare reservation, or defense readiness decision may need to survive audit, incident review, or public scrutiny. The planning invariant does not guarantee that the decision was wise. It guarantees that reviewers can reconstruct what was known, what logic was applied, which constraints were binding, which alternatives existed, and who authorized the consequential state change.

Common confusion

The invariant is not a claim that the world is deterministic, that one plan is objectively correct, or that human judgment should disappear. Judgment enters through policy, objective, risk tolerance, exception, and authority. The requirement is to preserve that judgment as part of the decision context rather than letting it masquerade as neutral computation.

Planning invariant	A proposed planning-specific trust contract tying an official result to context, method, and authority.
Determinism	A property of some methods, not a promise that the world is certain or the plan is correct.
Archive	A preserved output or package. An archive may not contain enough context for replay.
Replay package	Inputs, transformation, model, version, and authority evidence sufficient to reconstruct or forensically explain the result.
Human judgment	A governed part of the context: policy, objective, risk tolerance, exception, and authority.

Because Vista is coining the term, the citation question is not "who else says planning invariant?" The question is whether the related semantic requirements are already credible. Provenance, reproducibility, lineage, configuration control, decision dependency, and planning-input integrity are established ideas. Vista's contribution is to assemble them into a planning-specific trust contract.

Vista interpretation

Vista point of view

Vista's view is that the planning invariant should be part of the operator experience, not an internal architecture slogan. Every official plan should have a run ID, snapshot, configuration, evidence graph, publication state, and difference trace. Confidence is earned when the system can answer not only "What is the plan?" but "Why is this the plan, under which assumptions, and what changed?"

That matters because fast planning and agent-assisted planning create more candidate answers. Without semantic identity, speed produces more mystery. With it, teams can learn which assumptions changed outcomes, which policies created repeated exceptions, which inputs were unreliable, and which authority path turned a recommendation into a consequential plan.

Sources Reviewed 22 June 2026

"Planning invariant" is a proposed Vista term. These sources support the semantic components of the concept, not established use of the exact phrase.
W3C PROV defines provenance with entities, activities, agents, usage, generation, derivation, association, and plans, supporting the evidence-graph structure behind a governed planning result: PROV-DM: The PROV Data Model.
The National Academies define computational reproducibility as obtaining consistent results using the same input data, computational steps, methods, code, and analysis conditions, while noting that exact reproduction does not prove correctness: Reproducibility and Replicability in Science.
OpenLineage defines runtime and design lineage around jobs, runs, datasets, run identifiers, and extensible facets, supporting the distinction between static design context and an observed execution instance: OpenLineage Object Model.
NASA systems-engineering configuration-management guidance supports baseline visibility, change control, configuration status accounting, verification, version distinction, and consistency between a product and its information: NASA Systems Engineering Handbook, 6.5 Configuration Management.
ASCM/APICS CPIM v9 treats master-schedule integrity, MRP inputs and parameters, time-phased records, action messages, replanning, and supply/demand disruptions as core planning competence, supporting the planning-context side of the invariant: CPIM Exam Content Manual.
The term, exact manifest, replay level, authority workflow, and agent permissions are Vista interpretation and implementation-dependent.