Simulation Data Transformation Module (SDTM)
OOF™ Origin Open Foundation™
Independent Methodological Authority
Architecture Ecosystem: Structured Reality Standards™
Architecture Family: SIMULOS® — Simulation Governance Architecture
Parent Standard: Simulation Input & Data Standard (SIDS)
Operational Layer: Simulation Input & Data Governance Layer
Category: Governance & Enforcement
Subcategory: Simulation Governance
Type: Parent Standard Module
Governed Space: Simulation Data Transformation
Version: 1.0
Status: Canonical · Open Module
Effective Date: 18 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 Data Transformation
Canonical Definition
Simulation Data Transformation Module (SDTM) defines the governance frameworkthrough which identified Simulation Inputs may be cleaned, filtered,
normalized, converted, aggregated, disaggregated, interpolated, extrapolated,
encoded, imputed, derived, synthesized, resampled, aligned, or otherwise
transformed before or during simulation use while preserving the traceability,
meaning, limitations, uncertainty, provenance, and material consequences of
those transformations.
SDTM establishes the transformation layer of SIDS by governing the transition:
Source Information → Transformation →
Simulation-Usable Input
so that transformed information cannot silently acquire properties, precision,representativeness, certainty, or observational status that the transformation
process did not legitimately establish.
Operational Role
SDTM serves as the third internal governance space of the Simulation Input &Data Standard (SIDS).
The preceding modules establish:
SIIM — What information is entering the simulation?
SDRM — What reality can that information legitimately represent?
SDTM asks:
What has been done to that information before the simulation consumes it, why
was the transformation necessary, and what did the transformation materially
change?
The governed progression is:
Identified Input → Transformation Need → Transformation Method →
Transformation Execution → Transformed Input → Transformation Effect
Assessment → Transformation Status → Simulation-Usable Input
Module Function
SDTM exists to prevent: transformed information being treated as rawinformation, cleaning decisions disappearing from the simulation record,
filtering silently removing material observations, normalization changing
meaning without disclosure, unit conversion errors, aggregation hiding
material variation, interpolation being represented as observation,
extrapolation being represented as measured reality, imputed values appearing
as recorded values, synthetic supplementation appearing as empirical data,
transformations introducing hidden bias, precision being artificially
increased, information loss becoming invisible, multiple transformation stages
becoming unreconstructable, changed transformation logic being applied under
an unchanged identity, and simulation outputs becoming impossible to trace
back to the information basis from which they were produced.
Simulation Data Transformation
A Simulation Data Transformation is any governed operation that materiallychanges the: representation, structure, scale, format, resolution,
composition, value, distribution, temporal organization, spatial organization,
completeness, or interpretation
of information before or during simulation use.
Conceptually:
Input A → Transformation T → Input B
Input B may remain related to Input A, but it is not necessarilymethodologically identical to it.
Transformation Need
Every material transformation should have an identifiable reason.A Transformation Need may arise because: the simulation requires another unit,
sources use incompatible formats, sampling frequencies differ, missing
information must be treated, data contains technical noise, model interfaces
require normalization, multiple sources must be aligned, resolution must
change, derived variables are required, or information must be adapted to the
simulation representation.
Transformation Purpose
The transformation purpose should explain:Why must this information be changed before simulation use?
Examples include:
Compatibility
AlignmentNoise Reduction
Feature Construction
Missing-Value Treatment
Resolution Adjustment
Unit Harmonization
Data Fusionor:
Simulation Interface Preparation
Transformation Necessity
SDTM distinguishes:Necessary Transformation
from:Convenience Transformation.
A transformation may be technically convenient without being methodologically
justified.
Where a transformation materially affects simulation behavior, convenience
alone should not establish its legitimacy.
Transformation Method
A Transformation Method defines how the original information is converted intothe transformed Simulation Input.
It may specify: operation, algorithm, formula, rule, threshold, parameter,
model, software process, sequence, or another transformation mechanism.
Transformation Rule
A transformation should be sufficiently explicit that the relationshipbetween:
Input Before Transformation
and:Input After Transformation
can be understood and, where required, reconstructed.Transformation Parameters
Material parameters should remain traceable.For example:
a smoothing filter may require: window size, threshold, frequency, kernel, or
another parameter.
Changing these parameters may materially change the resulting Simulation
Input.
Data Cleaning
Cleaning may include: invalid-record removal, duplicate removal, formattingcorrection, impossible-value treatment, corrupted-record treatment, or
consistency correction.
Cleaning should not become an invisible mechanism for removing inconvenient
data. Cleaning ≠ Evidence Removal
SIMULOS® establishes:
Data should not be removed merely because it produces undesirable simulation
behavior.
Where materially relevant records are excluded, the basis for exclusion should
remain identifiable. Filtering
Filtering may remove: noise, frequencies, observations, events, values, or
records.
SDTM requires material filtering logic to remain visible.
Filter Effect
A filter may improve usability while reducing information.Therefore:
Cleaner Data ≠ More Complete Data
The effect of filtering should be assessed
where material. Normalization
Normalization may transform values into a common range or representation.For example:
0–100 → 0–1
The normalized value should remain connected to: original scale,
transformation rule, and semantic meaning.
Standardization
Standardization may express values relative to a distribution.The underlying basis should remain identifiable where the transformed values
affect simulation interpretation.
Unit Conversion
Unit transformations must preserve the relationship:Original Value + Original Unit → Conversion Rule → Converted Value + Target
Unit
SDTM prevents converted values from becoming detached from their original
measurement basis.
Format Conversion
Data may move between: structured formats, numerical representations, imageformats, coordinate systems, encoding systems, categorical structures, or
simulation-specific schemas.
Technical conversion should preserve materially relevant meaning.
Semantic Preservation Principle
SIMULOS® establishes:A transformation that preserves technical readability but changes material
meaning is not semantically neutral. Aggregation
Aggregation combines multiple observations into a reduced representation.
Examples include:
second → minute
individual → group
sensor points → regional average
Aggregation may simplify simulation input while hiding: variation, extremes,
sequences, correlations, or rare events.
Aggregation Loss
Where aggregation removes materially relevant information, the loss shouldremain visible.
For example:
an average temperature may hide short thermal spikes capable of affecting
system failure. Disaggregation
Disaggregation converts aggregated information into a more granular
representation.
Where the original information does not contain that granularity,
disaggregated values may depend upon assumptions or models.
SIMULOS® establishes:
Disaggregation must not be represented as direct observation where the
additional granularity was inferred. Interpolation
Interpolation estimates values between known observations.
Conceptually:
Observed A → Estimated Intermediate Value
→ Observed B
Interpolated values should remain distinguishable from direct observationswhere material. Extrapolation
Extrapolation estimates information beyond the observed range.
Because extrapolation extends beyond available observation, its methodological
basis and limitations should remain visible.
No Extrapolation-as-Observation Principle
A value generated beyond the observed data range does not become observedreality merely because it is numerically precise. Resampling
Resampling changes the frequency, density, or structure of observations.
Examples include:
100 Hz → 10 Hz
or:
hourly → minute-level representation
Resampling may: remove information, introduce estimated information, alter
signal behavior, or change temporal relationships.
Encoding
Information may be encoded into representations required by simulation
systems.
For example:
Category → Numerical Vector
The encoded representation should remain traceable to the original semanticcategory.
Derived Input
A Derived Simulation Input is produced from one or more existing inputs.Conceptually:
Input A + Input B + Rule → Derived Input C
The derivation relationship should remain
preserved. Derived ≠ Observed
SIMULOS® establishes:A calculated value must not silently acquire the status of a directly observed
value.
Feature Derivation
Simulation models may require derived features.Examples include: velocity from position changes, acceleration from velocity,
risk indicator from multiple variables, density from count and area, or
another constructed feature.
The derivation method should remain traceable where material.
Missing-Value Treatment
Missing information may be treated through: exclusion, substitution,interpolation, imputation, default value, synthetic replacement, or another
governed method.
SDTM requires the treatment to remain
explicit. Missing ≠ Zero
SIMULOS® establishes:Absence of information must not automatically become a zero-valued
observation. Imputation
Imputation replaces missing information with an estimated value.
An imputed value should remain identifiable as:
Imputed
rather than:
Observed
or:
Measured.
Imputation Basis
The basis may include: statistical estimate, neighboring observations,historical values, model output, population average, or another method.
The selected basis may materially influence simulation behavior.
Default Values
A simulation may technically require a value where none is available.A default value may be used where methodologically justified.
The default should remain identifiable as a default rather than being silently
treated as source data.
Synthetic Supplementation
Synthetic information may be introduced during transformation to supplementmissing or weak data.
SDTM governs the transformation process that introduces it.
SIIM preserves its synthetic identity.
SDRM governs what reality it can legitimately represent.
Outlier Treatment
Outliers may be: retained, excluded, capped, transformed, separately modeled,or investigated.
Outlier treatment should depend upon the simulation purpose and data basis.
Outlier ≠ Error
SIMULOS® establishes:
An unusual observation is not automatically an invalid observation.
Rare values may represent precisely the conditions a simulation needs to
examine.
Data Fusion
Multiple information sources may be combined into one Simulation Input.
Conceptually:
Source A + Source B + Fusion Method →
Fused Input
The fusion process should preserve materially relevant source relationshipsand transformation logic. Fusion ≠ Independent Confirmation
Two sources combined into one input do not necessarily constitute independent
evidence.
Their dependencies may remain relevant.
Spatial Transformation
Spatial information may require: coordinate conversion, map projection,spatial aggregation, interpolation, alignment, or resolution change.
Material spatial transformation should remain traceable where it can influence
simulated relationships.
Coordinate Transformation
Coordinate-system changes must preserve the applicable reference system andtransformation basis.
Errors in coordinate conversion can produce apparently valid but physically
incorrect simulation inputs.
Dimensional Transformation
Information may be reduced or expanded across dimensions.For example:
3D Reality → 2D Representation
or:
Multiple Variables → Composite Index
Such transformations may intentionally simplify reality.The simplification should remain connected to the simulation's Reality
Representation under RRS.
Transformation Sequence
Simulation data may undergo multiple transformations.For example:
Raw Sensor Data
↓Cleaning
↓
Filtering
↓
Unit Conversion
↓Resampling
↓
Normalization
↓Simulation Input
SDTM requires material sequence to remain reconstructable.Transformation Order Matters
Transformations may not be commutative.Conceptually:
Filter → Aggregate
may produce a different result from:Aggregate → Filter
Where order materially affects the resulting input, transformation sequencebecomes a governed property.
Transformation Dependency
One transformation may depend upon the output of another.These dependencies should remain visible where they affect reproducibility or
interpretation.
Transformation Chain
A Simulation Transformation Chain records the material progression:Original Input → T1 → Intermediate Input → T2 → Intermediate Input → T3 →
Simulation-Usable Input Transformation Identity
Each material transformation may receive an identifiable reference.
For example:
SDT-0042
This allows simulation records to reference the exact transformation logic
used.
Transformation Version
Transformation logic may change.For example:
Filter v1
may become:
Filter v2
A simulation executed under v1 should remain distinguishable from one executed
under v2.
No Silent Transformation Update Principle
SIMULOS® establishes:Materially changing transformation logic must not silently rewrite the
transformation basis of previous simulation executions.
Transformation Reproducibility
Where required by the simulation purpose, a transformation should besufficiently documented to allow an authorized independent implementation to
reproduce the transformed input from the same original basis.
Reproducibility may require: method, parameters, software version,
transformation sequence, source input version, and relevant execution
conditions.
Transformation Reversibility
Not every transformation is reversible.For example:
aggregation may permanently discard detail.
SDTM therefore distinguishes:
Reproducibility
from:Reversibility.
A transformation may be reproducible while information loss makes reversal
impossible.
Information Loss
Transformation may remove information.Loss may be:
Intentional
Incidental
Necessary
or:
Unrecognized
SDTM requires material information loss to remain visible.Transformation Gain
Some transformations create additional information representations.For example:
interpolation may create additional values.
But:
More values ≠ More observations.
Generated resolution should not be confused with additional empirical
evidence.
Precision Inflation
Transformation may produce numerically precise outputs from imprecise inputs.For example:
an estimated value may mathematically produce:
17.384729
This numerical precision does not establish equivalent informational
certainty.
No Precision Inflation Principle
SIMULOS® establishes:Transformation must not create an appearance of certainty or observational
precision unsupported by the underlying information basis.
Transformation-Induced Bias
Transformation logic may systematically alter the information basis.Examples include: selective filtering, biased imputation, asymmetric clipping,
population-dependent normalization, or model-based reconstruction.
Material transformation-induced bias should be identified and carried forward.
Transformation-Induced Uncertainty
A transformation may introduce additional uncertainty.For example: interpolation uncertainty, extrapolation uncertainty, imputation
uncertainty, fusion uncertainty, conversion uncertainty, or model-derived
uncertainty.
The subsequent SIUM — Simulation Input Uncertainty Module governs the
consolidated input uncertainty.
SDTM identifies transformation-induced contributions to that uncertainty.
Transformation Effect Assessment
After transformation, the resulting input should be assessed for materialchanges in: meaning, range, distribution, resolution, completeness,
representativeness, uncertainty, and simulation influence.
Representativeness Reassessment
Transformation may change representativeness.For example:
aggressive filtering may remove rare conditions that SDRM previously
considered represented.
Where transformation materially affects representation:
SDRM reassessment may be required.
Transformation Cannot Launder Weak Input
SIMULOS® establishes:Transformation does not automatically cure an unrepresentative, uncertain,
ambiguous, or otherwise limited input basis.
A weak source input may remain weak after sophisticated processing.
Transformation Limitation
A Transformation Limitation identifies a material restriction introduced orpreserved by transformation.
Examples include: lost high-frequency behavior, inferred missing values,
reduced spatial resolution, extrapolation beyond observed range, or uncertain
source alignment.
Transformation Condition
A transformed input may be suitable only under explicit conditions.For example:
Interpolated values suitable only where gaps do not exceed 5 seconds.
The condition should remain attached to downstream simulation use.
Transformation Status
A material transformation may receive a status such as:Transformation Accepted
Conditionally Accepted
Transformation Restricted
Transformation Rejected
or:Transformation Undetermined
The status applies to the transformation's suitability for the definedsimulation use.
Transformed Input Status
The resulting Simulation Input may be classified as:Simulation-Usable
Conditionally Simulation-Usable
RestrictedNot Simulation-Usable
or:Suitability Undetermined
This status does not replace subsequent temporal or uncertainty governance.Transformation Change
A material change may occur in: transformation method, parameters, software,source mapping, sequence, threshold, imputation rule, fusion logic, or another
transformation property.
Material changes should trigger reassessment of affected transformed inputs.
Transformation Impact Propagation
Where transformation materially affects downstream simulation use, the effectshould propagate.
Conceptually:
Transformation Change → Transformed Input Change → Scenario / Execution Effect
→ Output Effect → Reliance Effect
The later SIMULOS® Parent Standards govern those downstream consequences.
Point-in-Time Transformation
Reconstruction
SDTM supports questions such as:Which transformation was used for this execution?
Which parameters were active?
Which source input version entered it?
Which values were imputed?
Which observations were removed?
Which transformations introduced additional uncertainty?
Transformation Traceability
SDTM establishes:Source Input
↓Transformation Need
↓Transformation Method
↓Transformation Parameters
↓Transformation Execution
↓Intermediate States
↓Transformed Input
↓Transformation Effects
↓Conditions / Limitations
↓Simulation Use
Minimum Implementation Framework
1. Identify Material TransformationsDetermine which input changes can materially affect simulation behavior or
interpretation. 2. Establish Transformation Purpose
Record why each material transformation is required. 3. Define Transformation
Method
Specify the applicable: operation, rule, algorithm, formula, parameters, or
processing method.
4. Preserve Source Input Identity
Bind every material transformation to the exact input version from which it
originates. 5. Execute and Record the Transformation
Preserve the material transformation sequence and resulting input state. 6.
Identify Generated, Removed, or Modified Information
Determine whether the transformation: removes information, generates inferred
information, changes resolution, changes distribution, changes meaning, or
changes simulation influence.
7. Assess Transformation Effects
Evaluate material effects upon: representativeness, uncertainty, completeness,
precision, semantics, and simulation applicability.
8. Govern Missing Values, Outliers, and Synthetic Supplementation
Ensure treatment remains explicit and traceable. 9. Assess Transformation
Limitations
Identify information loss, extrapolation, imputation, bias, uncertainty, or
other material restrictions. 10. Assign Transformation Status
Determine whether the transformation is: Accepted, Conditionally Accepted,
Restricted, Rejected, or Undetermined.
11. Establish Transformed Input Status
Determine whether the resulting input may proceed to subsequent SIDS
governance. 12. Preserve Transformation Traceability
Maintain the complete relationship:
Source Input → Transformation → Transformed Input → Transformation Effect →
Simulation Use
Governance Outputs
SDTM may produce: Simulation Transformation Requirement, TransformationPurpose Record, Transformation Identifier, Transformation Method Record,
Transformation Rule, Transformation Parameter Record, Data Cleaning Record,
Filtering Record, Normalization Record, Standardization Record, Unit
Conversion Record, Format Conversion Record, Aggregation Record,
Disaggregation Record, Interpolation Record, Extrapolation Record, Resampling
Record, Encoding Record, Derived Input Record, Feature Derivation Record,
Missing-Value Treatment Record, Imputation Record, Default-Value Record,
Synthetic Supplementation Record, Outlier Treatment Record, Data Fusion
Record, Spatial Transformation Record, Coordinate Transformation Record,
Dimensional Transformation Record, Transformation Sequence Record, Simulation
Transformation Chain, Transformation Dependency Map, Transformation Version
Record, Transformation Reproducibility Record, Information Loss Record,
Transformation-Induced Bias Record, Transformation-Induced Uncertainty Record,
Transformation Effect Assessment, Representativeness Reassessment Signal,
Transformation Limitation Record, Transformation Condition Record,
Transformation Status, Transformed Input Status, Transformation Change Record,
and Simulation Data Transformation Traceability Map.
Use Case 1 — Autonomous Vehicle Sensor
Simulation
ScenarioA simulation consumes vehicle sensor data sampled at different frequencies:
camera — 30 Hz, radar — 20 Hz, lidar — 10 Hz, vehicle telemetry — 100 Hz.
The simulation requires a synchronized
input stream. Application
SDTM governs:Source Inputs
↓Timestamp Alignment
↓Resampling
↓
Interpolation Where Required
↓Synchronized Simulation Inputs
Interpolated values remain distinguishable from direct measurements, and thetransformation parameters remain traceable. Result
The simulation can determine exactly how the synchronized input stream was
produced and which portions contain transformed rather than directly observed
information. Use Case 2 — Industrial Failure Simulation
Scenario
Historical sensor records contain missing values and extreme temperature
spikes.
A preprocessing process proposes to: replace missing values with averages,
remove extreme values as outliers, smooth the resulting signal.
Application
SDTM prevents automatic treatment.
The temperature spikes are assessed before removal because they may represent
precisely the failure conditions the simulation intends to examine.
Missing values remain distinguishable from observed measurements after
imputation. Result
The transformation produces a governed Simulation Input without silently
removing potentially material failure behavior or representing imputed values
as direct observations.
Architectural Position
Simulation Data Transformation is the third internal governance space of theSimulation Input & Data Standard (SIDS).
The complete SIDS progression is:
Simulation Input Identification
↓Simulation Data Representativeness
↓Simulation Data Transformation
↓Simulation Temporal Data
↓Simulation Input Uncertainty
SIIM establishes:What is the input?
SDRM establishes:
What can it legitimately represent?
SDTM establishes:
What happened to it before simulation use?
The next module, STDM — Simulation Temporal Data Module, establishes whether
the information and its transformed state are temporally appropriate for the
simulation context in which they will be used.
Foundational Principle
A transformed Simulation Input remains legitimate only when the path from itsoriginal information basis to its simulation-usable form remains sufficiently
identifiable, justified, reproducible, limitation-aware, and traceable,
without allowing transformation to manufacture unsupported meaning,
representativeness, observational status, precision, or certainty.