Make Simulation Possible

Every simulation depends on assumptions.

Some are obvious.

Others are embedded inside: models, default settings, environmental
conditions, parameter choices, behavioral rules, dependencies, failure
conditions, or expected future states.

A simulation may appear technically complete while materially depending on
premises that were never explicitly identified.

Simulation Assumption Standard (SAS) governs those premises.

Canonical Definition

Simulation Assumption Standard (SAS) defines the governance conditions under
which assumptions necessary to construct, configure, execute, or interpret a
simulation are explicitly identified, justified, bounded, connected to their
supporting basis and dependencies, assessed for uncertainty and limitations,
and preserved as traceable components of the simulation lifecycle.

Why SAS Exists

Assumptions are not inherently a weakness.

Simulation would often be impossible without them.

The governance problem begins when assumptions become: hidden, unsupported,
overgeneralized, mutually inconsistent, treated as facts, reused outside their
original context, or disconnected from the outputs that materially depend upon
them.

SAS makes assumptions visible before they become invisible inside model
behavior.

Governed Space

Simulation Assumptions

SAS governs the methodological layer between:

Reality Representation

and:

Simulation Model & Environment construction.

The preceding Reality Representation Standard establishes what reality must be
represented and how.

SAS then establishes what must still be presumed in order to make that
representation operational inside the simulation.

Governance Flow

Reality Representation Basis → Assumption Need → Assumption Identification →
Assumption Basis → Assumption Dependency → Assumption Uncertainty → Assumption
Limitation → Assumption Consequence → Governed Simulation Assumption Basis

This governed basis then supports:

Simulation Model & Environment → Inputs & Data → Scenario Design → Simulation
Execution What SAS Establishes

SAS helps an organization establish:

Assumption Identification — which premises materially affect the simulation.

Assumption Basis — why those assumptions are being used and what supports
them.

Assumption Dependencies — which assumptions depend on other conditions,
systems, evidence, or assumptions.

Assumption Uncertainty — how uncertain the assumed condition remains.

Assumption Limitations — where the assumption stops being suitable.

Assumption Consequences — what happens if the assumption is materially wrong.

Assumption Traceability — which model elements, scenarios, executions,
outputs, or conclusions depend upon it.

Assumption Is Not Fact

One of the most important SAS distinctions is:

Assumption ≠ Established Fact

Repeatedly using an assumption does not make it true.

Embedding an assumption in software does not make it true.

Producing successful simulation outputs does not independently prove the
assumption.

This distinction protects simulation from circular reasoning.

Assumptions Must Remain Connected to Their
Basis

An assumption may be based on: operational observations, scientific evidence,
engineering knowledge, historical data, expert judgment, design
specifications, domain conventions, prior simulation, or conservative
estimation.

But not all assumption bases have equal strength.

SAS therefore allows organizations to distinguish between assumptions that
are:

Strongly Supported

Conditionally Supported

Weakly Supported

or:

Necessary but Uncertain

This creates a much clearer picture of where the simulation is structurally
strong and where it remains dependent on uncertainty.

Assumption Dependencies Matter

Assumptions rarely exist in isolation.

A simulation may depend on:

Network availability

which affects:

sensor access

which affects:

autonomous decision behavior

which affects:

system output.

SAS makes these relationships governable.

This matters because one weak upstream assumption can influence many
downstream simulation outcomes.

Assumption Interaction

Two reasonable assumptions may become problematic when combined.

For example:

Human response remains within expected
range

and:

network latency remains within expected range

may each appear acceptable.

But if both move toward adverse conditions simultaneously, system behavior may
materially change.

SAS therefore governs not only individual assumptions but also material
assumption interaction and accumulation.

Uncertainty Must Remain Visible

Not every assumption can be verified completely before simulation.

SAS does not force artificial certainty.

It allows assumptions to be represented through: ranges, probability
distributions, conditional states, scenario-specific premises, uncertainty
bands, or explicit unresolved status.

This is often methodologically stronger than pretending one uncertain value is
exact.

Business Value

For organizations using simulation in engineering, AI, autonomous systems,
aerospace, infrastructure, healthcare, finance, safety, or decision support,
SAS provides a direct way to answer:

What are we assuming, and how much of the result depends on those assumptions?

This helps organizations identify: hidden model dependencies, weak premises,
brittle conclusions, unrealistic defaults, untested environmental
expectations, critical assumptions, sensitivity to assumption failure, and
situations where apparently strong outputs are actually assumption-dependent.

It also makes simulations easier to: audit, compare, update, explain,
challenge, re-run, and validate.

Critical Assumptions

Some assumptions matter much more than others.

SAS allows a Critical Simulation Assumption to be identified where its failure
could materially change a major simulation conclusion.

This enables organizations to focus attention on the assumptions capable of
creating the largest methodological consequences.

Critical assumptions may require stronger: evidence, sensitivity analysis,
scenario testing, monitoring, or downstream validation.

Assumption Sensitivity

A useful simulation-governance question is:

If this assumption changes within a plausible range, does the simulation
conclusion change?

If the answer is no, the result may be relatively robust to that assumption.

If the answer is yes, the assumption becomes materially important to
interpretation.

SAS therefore helps distinguish:

assumption-dependent results

from:

more robust simulation results.

Assumption Failure

An assumption may later prove wrong.

That does not automatically mean the entire simulation becomes useless.

The relevant question is:

What depended upon that assumption?

The effect may be: local, scenario-specific, output-specific, model-wide, or
critical.

SAS preserves this dependency so that affected simulation elements can be
reassessed instead of automatically discarding or blindly retaining the entire
simulation.

Relationship to Validation

SAS governs assumptions inside the simulation.

It does not universally determine whether those assumptions are valid.

That is a separate validation question.

Where formal validation is required:

VALIDOS® may validate: the assumption, its evidence basis, the simulation, the
resulting output, or a claim based upon it.

The boundary is therefore clear:

SIMULOS® governs the role of assumptions in simulation.

VALIDOS® governs formal validation of the relevant Validation Object.

Relationship to Operational Reality

ORA™ governs actual Operational Reality.

SAS governs what the simulation presumes about conditions that may be
incomplete, uncertain, expected, or simplified relative to that reality.

A later mismatch between an assumption and operational reality may become a
trigger for reassessment or resimulation.

Relationship to Integrity

INTEGROS® may govern the integrity of: assumption records, source records,
change history, traceability, or related artifacts.

SAS governs the specific simulation methodology surrounding assumption
identification, basis, dependency, uncertainty, limitation, and consequence.

Practical Governance Test

Before model construction proceeds, an organization should be able to answer:

What are we assuming?

Why are we assuming it?

What supports the assumption?

What depends upon it?

How uncertain is it?

What happens if it is wrong?

Where does the assumption stop applying?

Which simulation outputs materially depend upon it?

If these questions cannot be answered for material assumptions, the simulation
contains hidden methodological dependencies.

Architectural Position

SAS is the fourth Parent Standard of SIMULOS® — Simulation Governance
Architecture.

The architectural progression is:

Simulation Object

↓

Simulation Purpose & Scope

↓

Reality Representation

↓

Simulation Assumptions

SOS establishes:

What exactly is being simulated?

SPSS establishes:

Why is it being simulated and what must it cover?

RRS establishes:

Which parts of reality must be represented and how?

SAS establishes:

Which premises are required to make that representation usable as a
simulation, and what uncertainty, dependency, and limitation do those premises
introduce?

The next governance question becomes:

How must the simulation model and simulation environment be constructed,
configured, bounded, parameterized, and version-controlled?

Foundational Principle

A simulation may rely upon assumptions, but no material simulation conclusion
should become stronger than the assumptions upon which that conclusion
materially depends.

Canonical Closing Statement

Simulation Assumption Standard (SAS) governs the premises that make simulation
possible by ensuring that material assumptions remain explicit, supported
where possible, dependency-aware, uncertainty-aware, bounded, and traceable
throughout the simulation lifecycle. By separating assumptions from facts,
exposing hidden premises, governing assumption interaction and sensitivity,
and preserving the consequences of assumption failure, SAS prevents simulation
outputs from appearing stronger than the assumptions that materially shape
them and provides the governed assumption basis required for construction of
the Simulation Model & Environment.