Simulation Assumption Identification Module (SAIM)

OOF™ Origin Open Foundation™

Independent Methodological Authority

Architecture Ecosystem: Structured Reality Standards™
Architecture Family: SIMULOS® — Simulation Governance Architecture
Parent Standard: Simulation Assumption Standard (SAS)
Operational Layer: Simulation Assumption Governance Layer
Category: Governance & Enforcement
Subcategory: Simulation Governance
Type: Parent Standard Module
Governed Space: Simulation Assumption Identification
Version: 1.0
Status: Canonical · Open Module
Effective Date: 17 August 2026
Compatibility: OOF® Methodology OS™ · GOA™ · ORA™ · VALIDOS® · INTEGROS® · ADIT® · AGA™ ·
AIG® · CLIA® · MGIA™ · ASGA™ · RIS™
AI-Readable: Yes
Authority: OOF®
Protection: MIP® — Methodological Intellectual Property
Canonical Language: English (UCL™)


Governed Space

Simulation Assumption Identification

Module Function

SAIM applies after the relevant reality representation has been sufficiently
established.


Its primary function is to prevent assumptions from becoming invisible
components of the simulation.


A simulation may contain sophisticated models, extensive data, realistic
environments, and technically correct execution while still depending upon
premises that were never formally identified.


SAIM therefore establishes a controlled distinction between:

what is represented,

what is known,

what is supplied as input,

and:

what must be assumed.

Simulation Assumption

A Simulation Assumption is a premise accepted for the purpose of constructing,
configuring, executing, or interpreting a simulation where the relevant
condition is not established as a complete governed fact within the simulation
basis.


An assumption may concern: reality, system behavior, human behavior,
environmental conditions, physical conditions, relationships, dependencies,
timing, availability, future states, operating conditions, boundary behavior,
parameter behavior, failure behavior, or another condition required by the
simulation.


Assumption Identification Principle

SIMULOS® establishes:

A premise that materially influences simulation behavior should not remain
methodologically invisible merely because it is embedded inside a model,
configuration, parameter, scenario, or technical implementation.


Identification makes the assumption governable.

It does not establish that the assumption is correct.

Explicit Assumptions

An Explicit Simulation Assumption is intentionally declared as an assumption.

For example:

Average human response time is assumed to remain within the defined operating
range.


Because the premise is explicit, it can be examined, challenged, changed,
tested, or bounded.


Implicit Assumptions

An Implicit Simulation Assumption exists where the simulation depends upon a
premise that has not been formally declared.


Implicit assumptions may arise through: default values, model architecture,
omitted variables, simplified relationships, expected behavior, inherited
engineering practice, software defaults, scenario construction, or
interpretation conventions.


SAIM seeks to convert materially relevant implicit assumptions into explicit
governed assumptions.


Embedded Assumptions

Some assumptions are embedded directly inside simulation components.

For example, a model may mathematically encode that:

a relationship remains linear within a particular operating range.

Even where no human explicitly labels this as an assumption, the simulation
depends upon it.


SAIM therefore treats materially consequential embedded premises as
governance-relevant assumptions.


Inherited Assumptions

A simulation may inherit assumptions from: previous simulations, external
models, datasets, engineering models, scientific literature, digital twins,
third-party components, vendor models, standard operating models, or reused
simulation environments.


Inherited assumptions should not automatically receive governance acceptance
merely because the originating component was previously used.


Their role in the current simulation must remain identifiable.

Assumption Versus Fact

SAIM requires a clear methodological distinction between:

Established Condition

and:

Assumed Condition

An assumption must not be silently converted into a fact merely because: it
has been used repeatedly, it appears plausible, it originates from an
authoritative source, it is embedded in software, it reflects common practice,
or previous simulation results were consistent with it.


Assumption Versus Input

Not every simulation input is an assumption.

For example:

Measured temperature = 22°C

may be a governed simulation input.

But:

temperature will remain approximately 22°C throughout the simulated period

may be an assumption.

SAIM preserves this distinction because inputs and assumptions create
different governance questions.


Assumption Versus Representation
Limitation

A representation limitation identifies something that the simulation does not
fully represent.


An assumption identifies a premise accepted so that the simulation can
nevertheless proceed.


These may be connected but should remain distinguishable.

For example:

Wind turbulence is represented at reduced
resolution

may be a Representation Limitation.

Reduced-resolution turbulence remains sufficient for the simulated flight
condition


may be a Simulation Assumption.

Assumption Discovery

Assumption discovery should examine the simulation from multiple directions.

Relevant questions include:

What must be true for this simulation model to behave as intended?

What conditions are being treated as stable?

Which variables have been simplified or held constant?

Which relationships are presumed rather than directly established?

Which external dependencies are expected to behave in a particular way?

Which future conditions are presumed?

Which model defaults contain substantive premises?

Which omitted elements require compensating assumptions?

Assumption Sources

Assumptions may originate from: simulation designers, engineers, scientists,
domain experts, model developers, operators, datasets, external models,
technical specifications, historical experience, organizational practice,
prior simulations, automated model-generation systems, AI systems, or
inherited technical components.


SAIM identifies the assumption and its origin where available.

The strength of the supporting basis is governed subsequently by SABM —
Simulation Assumption Basis Module.


Assumption Classification

Identified assumptions may be classified according to their role.

Possible classes include:

Reality Assumption

A premise concerning the represented reality.

Model Assumption

A premise required by the simulation model.

Environment Assumption

A premise concerning the simulated environment.

Behavioral Assumption

A premise concerning expected behavior of humans, systems, agents, or other
actors.


Parameter Assumption

A premise concerning a parameter or parameter range.

Temporal Assumption

A premise concerning time, sequence, duration, or persistence.

Dependency Assumption

A premise concerning an external or internal dependency.

Scenario Assumption

A premise specific to a particular simulation scenario.

Boundary Assumption

A premise concerning behavior at or beyond a simulation boundary.

Other classifications may be established where required by the simulation
domain.


Assumption Materiality

Not every assumption requires the same governance attention.

SAIM distinguishes assumptions according to whether they can materially
influence: model behavior, scenario behavior, execution, outputs, output
interpretation, operational conclusions, downstream validation, or reliance.


A Material Simulation Assumption is an assumption whose change or failure
could materially alter a relevant simulation behavior, output, conclusion, or
subsequent decision basis.


Critical Simulation Assumption

A Critical Simulation Assumption is a material assumption whose failure could
fundamentally alter: a principal simulation outcome, a high-consequence
conclusion, safety-relevant behavior, operational feasibility, or the
legitimacy of downstream reliance.


Critical classification does not itself determine whether the assumption is
acceptable.


It determines that the assumption requires stronger visibility and downstream
governance.


Assumption Materiality Test

A practical materiality test asks:

If this assumption were materially wrong, could the simulation behave
differently in a way relevant to its purpose?


If yes, the assumption should normally enter the governed Simulation
Assumption Set.


Assumption-to-Simulation Binding

Every material assumption should be connected to the simulation context in
which it applies.


The binding may identify:

Simulation Object

Simulation Version

Applicable Model

Applicable Environment

Applicable Scenario

Applicable Parameter

Applicable Execution Condition

or:

Applicable Output Domain

This prevents an assumption from being interpreted as universally applicable
when it belongs only to a bounded simulation context.


Assumption Identifier

A governed assumption should receive a sufficiently stable identifier where
traceability requires one.


Conceptually:

SA-001 — Network Availability Assumption

SA-002 — Human Response-Time Assumption

SA-003 — Environmental Stability
Assumption

The identifier allows downstream simulation artifacts to reference the exact
assumption upon which they depend.


Assumption Status

An identified assumption may carry a current governance status such as:

Identified

Under Review

Accepted for Simulation Use

Conditional

Challenged

Superseded

Withdrawn

or:

Unresolved

The status does not substitute for validation.

It communicates the assumption's current role within the simulation governance
process.


Assumption Duplication

The same underlying assumption may appear in several parts of a simulation.

SAIM should distinguish between:

multiple references to one assumption

and:

multiple materially different assumptions expressed similarly.

This prevents artificial multiplication of assumption records while preserving
real differences.


Assumption Interaction Visibility

Identification should also expose where multiple assumptions may jointly
influence the same simulation component or outcome.


Detailed dependency governance belongs to SADM — Simulation Assumption
Dependency Module.


SAIM establishes the visibility required for that later analysis.

Assumption Change

An assumption may change because: new evidence appears, operational reality
changes, model design changes, simulation scope changes, parameters change,
external dependencies change, or the assumption is challenged.


Material changes should preserve continuity between the previous and successor
assumption states.


No Hidden Assumption Principle

SIMULOS® establishes:

A material assumption must not remain hidden merely because exposing it would
weaken confidence in the simulation.


Simulation governance requires methodological visibility, not presentation
convenience.


No Assumption Inflation Principle

An assumption should not gradually become represented as:

known, demonstrated, verified, validated, or factual

without a separate governed basis supporting that transition.

No Assumption Laundering Principle

A premise should not escape assumption governance by being embedded into: a
parameter, a model constant, a default configuration, a reused component, a
scenario, or a third-party simulation asset.


Its methodological role determines whether it is an assumption.

Assumption Register

SAIM may establish a Simulation Assumption Register containing material
assumptions associated with the simulation.


The register may include: Assumption ID, Assumption Statement, Assumption
Class, Simulation Object, applicable model or environment, applicable
scenario, origin, materiality, criticality, current status, affected
simulation elements, and traceability references.


The register provides the structured basis for subsequent SAS modules.

Assumption Set Completeness

SAIM does not require the impossible claim that every conceivable assumption
has been discovered.


Instead, it asks whether materially relevant assumptions have been identified
with sufficient rigor for the simulation purpose and scope.


Possible states may include:

Assumption Set Sufficiently Identified

Assumption Set Conditionally Identified

Material Assumption Gap Detected

or:

Assumption Identification Undetermined
Assumption Gap

A Simulation Assumption Gap exists where a materially relevant premise appears
necessary to the simulation but has not been sufficiently identified or
governed.


An assumption gap may require: further model examination, expert review,
scenario analysis, technical inspection, documentation review, or simulation
redesign.


Assumption Identification Traceability

SAIM should preserve:

Simulation Requirement / Representation

↓

Assumption Need

↓

Identified Assumption

↓

Assumption Classification

↓

Materiality

↓

Affected Simulation Element

↓

Assumption Record

This creates a traceable bridge between reality representation and assumption
governance.


Governance Outputs

SAIM may produce: Simulation Assumption Identification Record, Simulation
Assumption Register, Explicit Assumption Record, Implicit Assumption Record,
Embedded Assumption Record, Inherited Assumption Record, Simulation Assumption
Classification, Assumption Materiality Assessment, Critical Simulation
Assumption Record, Assumption-to-Simulation Binding Record, Assumption Origin
Record, Assumption Status Record, Assumption Interaction Reference, Assumption
Change Record, Simulation Assumption Gap Record, Assumption Identification
Sufficiency Assessment, Simulation Assumption Traceability Map, and Governed
Simulation Assumption Set.


Use Case 1 — Autonomous Vehicle Simulation

Scenario

An autonomous vehicle simulation models urban operation.

The simulation explicitly defines road geometry and traffic signals but
implicitly assumes that surrounding human drivers generally remain within
modeled behavioral ranges. Application


SAIM identifies:

Human Driver Behavioral Range

as a material Behavioral Assumption.

The assumption is bound to the relevant traffic scenarios and identified as
potentially critical where collision-avoidance behavior depends upon it.
Result


The premise can no longer remain hidden inside the traffic model.

It enters the Simulation Assumption Register and proceeds to basis,
dependency, uncertainty, and limitation governance. Use Case 2 — Spacecraft
Mission Simulation


Scenario

A spacecraft mission simulation depends upon expected communication
availability during several mission phases.


Communication availability is represented through predefined environmental and
infrastructure conditions. Application


SAIM identifies:

Expected Communication Availability

as a material Dependency Assumption.

The assumption is bound to the relevant mission phases and to simulation
outputs that depend upon command availability. Result


The simulation can explicitly distinguish outcomes that remain robust from
outcomes materially dependent upon the communication assumption.


Architectural Position

Simulation Assumption Identification is the first internal governance space of
the Simulation Assumption Standard (SAS).


The complete SAS progression is:

Simulation Assumption Identification → Simulation Assumption Basis →
Simulation Assumption Dependency → Simulation Assumption Uncertainty →
Simulation Assumption Limitation


SAIM establishes:

Which assumptions exist and which are material?

SABM then establishes:

What basis supports each assumption?

SADM establishes:

What depends upon each assumption and how do assumptions depend upon one
another?


SAUM establishes:

How uncertain is the assumption and how must that uncertainty remain
represented?


SALM establishes:

Where does the assumption cease to apply and what limitations follow from it?

Together, these modules transform simulation assumptions from hidden premises
into explicit, bounded, traceable governance objects.


Foundational Principle

A simulation assumption becomes governable only when the premise upon which
the simulation materially depends is made explicit, distinguishable, bounded,
and traceable to the simulation elements it can influence.