Plan run

A named execution of a planning method against a declared snapshot, horizon, policy, constraint set, configuration, and engine version that produces recommendations, exceptions, pegging, and plan measures.

Operator definition

"The plan" is too vague to govern. A plan run gives the calculation an identity.

It says which data cut the engine used, which horizon and calendars applied, which policies and constraints were active, and which scenario or baseline was calculated. It also records which engine and configuration executed, when the run started and ended, and which outputs it produced.

A plan run can be batch, interactive, scheduled, event-triggered, or invoked by an agent. The execution mode matters less than the record: users need to know exactly which run they are viewing, comparing, approving, or releasing.

Why it matters

Without run identity, teams compare numbers that were never calculated from the same context. One user may be looking at yesterday's data, another at a scenario, and a third at a baseline recalculated after a supplier change.

A plan run anchors comparison, review, and publication. It also lets operators separate a calculated result from an official plan. Many runs may exist. Only one may be approved for a particular horizon or purpose.

The planning physics

Epistemic status: established planning-system implementation practice; exact run controls vary by product and architecture.

A minimum run manifest includes:

plan_run_id
plan type and scenario/baseline state
input snapshot and data-as-of timestamps
horizon, time buckets, and calendars
policy, constraint, and objective versions
engine / solver / model / configuration version
scenario set, seed, and tolerance where relevant
initiating user, service, schedule, or agent
start/end time and run status
output recommendations, pegging, exceptions, infeasibilities
comparison parent and publication state

The run should be immutable as a historical object. Corrections create a new run or an explicitly versioned rerun, not a silent overwrite.

The manifest is a provenance record, not a screenshot. It should identify the activity that ran, the input entities used, the user, service, schedule, or agent responsible for initiating it, and the outputs generated. If an output later becomes official, the publication event should point back to the run rather than rewriting it.

Archive, reconstruction, and replay are different levels. An archive may preserve selected outputs. A forensic reconstruction preserves enough context to explain why outputs changed. Computational reproduction tries to recompute consistent results under declared data, methods, code, and conditions. Bit-for-bit replay is valuable when feasible, but some optimization or stochastic runs require equivalence within a declared tolerance.

Simple example - run comparator

A weekly supply plan is executed twice. The demand baseline, engine, and policy are unchanged, but the accepted data cut changes overnight.

Weekly supply planrun comparator

All layers

The run identity explains what changed and what stayed controlled.

PR-1042 and PR-1043 used the same demand, engine, and policy. The material difference was the accepted supply-confirmation cut, which reduced expedite recommendations from 42 to 27.

Layer	Run PR-1042	Run PR-1043	Classification
Accepted data cut snapshot	Data as of Friday 18:00; supplier confirmations through Friday 16:00.	Data as of Saturday 08:00; supplier confirmations through Saturday 07:30.	Changed - a new receipt confirmation entered the accepted state.
Demand baseline D-77	Baseline demand version D-77.	Baseline demand version D-77.	Same - demand did not explain the output change.
Engine and policy 4.8.2 / P-14	Engine 4.8.2, policy bundle P-14.	Engine 4.8.2, policy bundle P-14.	Same - method and policy remained controlled.
Result expedites	42 expedite recommendations.	27 expedite recommendations.	Changed - fewer shortages require action.
Material cause receipt	The large receipt was not yet confirmed inside the accepted cut.	One large receipt was confirmed overnight.	Causal - the comparison points to data timing, not engine drift.
Publication state authority	Prior comparison parent. Not automatically replaced unless superseded.	Candidate successor. Not official unless approved or published for the purpose.	Separate transition - calculation is not approval or release.

The comparator makes the overnight receipt visible without forcing users to guess whether demand, policy, engine, or timing changed.

What goes wrong without it

"Latest plan" means different things to different users.
Scheduled and interactive calculations overwrite each other.
A scenario result is released accidentally.
Run failure or partial completion is hidden.
Users cannot tell whether a number changed because of data, policy, engine, or timing.
Archived output lacks the manifest needed for meaningful comparison.
An agent invokes a calculation but leaves no durable record of the tool, context, or result.
Recurring exceptions cannot be studied because the organization preserved answers but not the recipe that produced them.

How it shows up in high-consequence supply chains

A run supporting medicine allocation, patient scheduling, emergency stockpile deployment, or infrastructure restoration may need a stronger publication and evidence standard than a long-range exploratory scenario. The run should preserve unresolved data defects, constraint violations, uncertainty assumptions, and approval state rather than displaying a clean answer that conceals risk.

Different calculations may require different replay levels. A deterministic netting run may support exact replay. A stochastic resilience scenario may require the scenario set and tolerance. A high-impact published run should preserve the accepted solution and authority even when multiple equivalent solutions exist.

Common confusion

A plan run is not necessarily the official plan. It is a calculation event and its result set. Publication, approval, release, reservation, allocation, and promise are separate transitions.

A run is also not the same as a data refresh. Some systems refresh state continuously and calculate selectively; others copy data into a plan before execution. The record should identify both the accepted data cut and the calculation event.

Plan run	A calculation event and result set tied to a declared manifest.
Official plan	A published or approved planning state for a purpose, horizon, or authority boundary.
Data refresh	A change in accepted input state. It may precede a run, but it is not the run itself.
Archive	A preserved output or package. Archive is not replay.
Replay	A recomputation attempt under declared data, methods, code, and conditions. Replay is not approval.
Approval	An authority transition that accepts a result. Approval is not release.

Archive is not replay. Replay is not approval. Approval is not release. A strong planning system keeps those transitions linked, but separate.

Vista interpretation

Vista point of view

Vista's view is that plan-run identity belongs in the operator experience, not only in a backend log. Every number shown as plan truth should carry a run identity. The user should be able to open the run recipe, compare it with prior runs, inspect exceptions and pegging, and see whether the result is exploratory, proposed, approved, or commitment-bearing.

The payoff is not just auditability. Run identity lets teams learn over time: which data cuts created noise, which policies caused repeated expedites, which constraints made the plan infeasible, and which agent-initiated calculations became trusted enough to publish. Fast planning is useful only when frequent answers remain governable.

Sources Reviewed 22 June 2026

W3C PROV defines provenance around entities, activities, agents, usage, generation, start/end time, and responsibility; this supports treating a plan run as a governed computational activity with inputs, outputs, and an accountable initiator: PROV-DM: The PROV Data Model.
The National Academies define computational reproducibility around consistent results using the same input data, computational steps, methods, code, and analysis conditions, while warning that exact reproduction does not guarantee correctness: Reproducibility and Replicability in Science.
FAIR computational-workflow guidance defines a workflow run as an executed instantiation with input datasets, parameter files, output data, provenance execution log, and data-product lineage: Applying the FAIR Principles to computational workflows.
Oracle's Supply Planning documentation is retained as implementation evidence for plan execution options, data refresh choices, batch/background scheduling, review, approval, release, and archiving: Oracle Fusion Cloud Supply Planning.
Run-control fields, archival scope, replayability, publication workflow, and agent invocation records are implementation-dependent.