⚙️ SubstrateX Aperture™ Technical and Validation Supplement
The Public Contract for Conformance, Reproducibility, and Independent Challenge
The SubstrateX Aperture™ Technical and Validation Supplement defines how a specific Aperture release can be identified, inspected, tested, compared, reproduced, and challenged. The Foundational System explains what the Runtime Evidence Observatory is. The Engineering Architecture explains how its implementation is organized.
The Validation Harness executes controlled cases through the production evidence pipeline. This supplement establishes the versioned technical contracts required to determine whether a particular release behaves as claimed.
A working interface demonstrates implementation. It does not, by itself, establish determinism, scientific validity, predictive performance, generalization, or independent replication. Each requires its own evidence.
The supplement therefore treats validation as part of the architecture—not as a general claim attached to the software.
From Architecture to Testable Contract
Aperture transforms operational records into source-bound runtime reconstructions, registered measurements, bounded Instrument Findings, interpretation objects, Runtime Evidence Passports, and preservation artifacts.
For that process to be reproducible, every authoritative output must be governed by an explicit contract:
What source was examined?
How was it qualified, transformed, and canonicalized?
Which identity refers to the source, canonical runtime, computation, evidence record, and artifact?
Which method produced each measurement?
Which parameters, thresholds, dependencies, and temporal coordinates were used?
What evidence supports each marker, regime, finding, or classification?
Which outputs must reproduce exactly?
Which numerical or environmental differences are permissible?
Which material is source-observed, computed, derived, projected, interpreted, or contextual?
What remained unavailable, not observed, not computed, unvalidated, or undemonstrated?
Which claims does the evidence authorize?
Which conditions require the system to reject or qualify a claim?
The supplement converts these questions into versioned registries, schemas, conformance requirements, validation protocols, release manifests, expected-output contracts, and replication procedures.
Its governing principle remains:
One evidence object. One authority. Multiple bounded projections.
Relationship to the Validation Harness
The Validation Harness and Technical and Validation Supplement perform different functions.
Technical and Validation Supplement
Registers the semantic contracts, schemas, comparison rules, maturity states, validation protocols, release requirements, and replication procedures.
Validation HarnessExecutes known and controlled sources through the production evidence pipeline and compares the independently computed Runtime Evidence Record with a predeclared expectation map.
Validation Result Record
Preserves the observed comparison state, discrepancies, missingness, and certificate scope for one executed case.
Independent replication
Repeats specified procedures outside the originating implementation or team and publishes the resulting methods, discrepancies, and limitations.
The supplement does not execute evidence computation, and the harness does not define scientific maturity by itself.
The supplement declares the testable contract. The harness executes it. The validation record preserves what happened. Independent replication tests whether the result survives outside its origin.
What the Supplement Registers
The technical baseline coordinates several registries. Each registry has its own version and authority. A public release must identify the exact bundle used for computation.
Canonical Signals
The supplement registers 28 research-facing behavioral signals across four semantic families:
motion and coherence;
temporal organization;
formation and boundary dynamics; and
role and interaction dynamics.
Those semantic families are distinct from the runtime authority levels through which measurements may be represented:
Level 0 — source-derived features;
Level 1 — derived runtime dynamics; and
Level 2 — instrument projections.
Each signal contract should identify:
signal and registry identity;
the construct being represented;
eligible source and canonical inputs;
computational method;
temporal scope, coordinate domain, and ordering assumptions;
parameters, thresholds, dependencies, and precision;
output type, unit, range, and missingness behavior;
evidence and authority class;
computability and sufficiency requirements;
eligible instruments and downstream consumers;
permitted interpretations;
prohibited claims;
validation and calibration status; and
supersession history.
A signal name alone is not a measurement contract. Its method, evidence basis, temporal scope, version, and limitations must remain recoverable.
Runtime Signal Authority
The runtime Signal Authority records which registered measurements are actually implemented, available, and authorized in a specific release.
The semantic registry and runtime Signal Authority are not automatically identical. A research-facing signal may be defined but not yet implemented, availability-gated, experimental, or represented through a different runtime object.
A conforming release must publish a crosswalk showing:
research signal identity;
runtime signal identity where implemented;
implementation and schema version;
measurement level;
authority class;
availability state;
consuming instruments;
validation status; and
reason for any missing, combined, or superseded entry.
The metric-legitimacy matrix remains the authority for what a computed value is permitted to mean within the release.
Scientific Instruments
The supplement defines nine non-mutating instrument contracts:
Seismo;
Chronos;
Drift;
Pressure;
Bridge;
Noesis;
Scope;
Dynamics; and
Interferometer.
During active computation, every instrument reads authorized evidence associated with the same Current Evidence Run. It may issue only its own bounded Instrument Finding. Those findings may later be preserved within the Runtime Evidence Record.
Every instrument contract should specify:
sensor and eligible evidence inputs;
signal dependencies;
required source coverage;
method and version;
coordinate and evidence horizon;
measured property;
permitted finding types;
handling of unavailable evidence;
claim boundary; and
prohibited conclusions.
Instruments may select, transform, compare, or visualize authorized evidence according to their contracts. They cannot create a second source of truth, invent missing values, relocate authoritative markers, or extend the run's claim boundary.
Agreement among instruments demonstrates consistency among projections of the same evidence object. It does not make those instruments independent witnesses.
Canonical Objects
The supplement establishes minimum contracts for:
source and qualification records;
adapter and canonicalization records;
canonical runtime events;
canonical runtime spine and playback frames;
runtime event ledger;
signal, metric, marker, and regime records;
Current Evidence Run;
Runtime Evidence Record;
Certified Runtime Evidence Record;
Runtime Evidence Passport;
Evidence Seal;
Instrument Findings;
REIM, synthesis, and Human Read objects;
claim, challenge, and investigation records;
Validation Comparison Records;
preservation manifests; and
release and artifact identities.
These contracts preserve the distinctions among source evidence, deterministic computation, contextual information, interpretation, visualization, validation comparison, and preservation.
Temporal and Claim Authority
The supplement also governs:
event, turn, wall-clock, dependency, and symbolic-time coordinates;
coordinate reconciliation;
eligible evidence horizons;
candidate and confirmed runtime markers;
source-supplied and computed markers;
prospective and retrospective computation;
Basin Exit and recovery conditions;
formal lead-time admissibility;
warning windows and post-exit observation intervals;
claim classes;
evidence-basis and sufficiency rules; and
protection against future-information leakage.
A temporal warning claim is admissible only when the detector, eligible evidence horizon, ordering relationship, marker authority, and applicable temporal coordinate are declared.
Formal lead time requires both a qualifying boundary marker and an observable failure marker. A boundary marker without a failure anchor may support a warning window or post-exit observation interval, but not formal lead time.
Five States of Scientific Maturity
One of the supplement's most important responsibilities is separating maturity states that are often treated as interchangeable.
StateWhat it establishesDefinedThe construct has a stable, versioned semantic contract.ImplementedAn identified release contains an executable method associated with that contract.DeterministicRepeated eligible computation reproduces governed outputs within declared equality rules or tolerances.ValidatedThe outputs demonstrate specified relationships to controlled constructs or external criteria under a declared protocol.Independently replicatedAn unaffiliated party reproduces the specified result from the released materials and reports its methods and discrepancies.
A construct can be defined without being implemented.
A method can be implemented without being deterministic.
A deterministic measurement can remain scientifically unvalidated.
A result can be internally validated without being independently replicated.
Determinism establishes reproducibility under a declared contract. It does not establish scientific truth.
The maturity state belongs to a specific construct, method, release, protocol, and result. It should not be generalized to the entire system without evidence.
Six Surfaces of Conformance
Aperture conformance cannot be reduced to one score. The supplement evaluates releases across six separate surfaces.
1. Source Conformance
Whether records are preserved, qualified, parsed, role-resolved, transformed, and canonicalized as declared.
2. Computational Conformance
Whether methods, parameters, dependencies, ordering rules, precision, availability, and missingness behavior match the registered contract.
3. Object Conformance
Whether the release produces the required runtime, evidence, Passport, seal, marker, finding, interpretation, validation, and preservation objects with the correct schemas and relationships.
4. Authority Conformance
Whether every authoritative output resolves to the same source, canonical runtime, run, Runtime Evidence Record, and Passport identity and remains inside its evidence basis and claim boundary.
5. Artifact Conformance
Whether exports preserve identifiers, hashes, versions, omissions, uncertainty, lineage, manifests, replay requirements, and challenge paths without allowing the export envelope to rewrite the deterministic evidence core.
6. Validation Conformance
Whether tests use bound sources, locked expectation maps, declared environments, comparison rules, pass criteria, anti-contamination controls, and discrepancy classifications.
A release may conform semantically while lacking empirical validation. It may reproduce its own outputs while remaining uncalibrated against external outcomes. These distinctions must remain visible.
From Scenario to Reproducible Result
A named example is not automatically a validation fixture.
A fixture becomes replication-ready only when it is bound to:
exact source bytes or an exact authorized source reference;
provenance and permitted use;
fixture identity and version;
a declared test purpose;
source and canonical identities or hashes;
expected qualification results;
expected runtime objects;
expected signal, marker, regime, and finding states;
expected unavailable and prohibited outputs;
comparison rules and tolerances;
expected claim-boundary decisions;
anti-contamination requirements; and
a specific software and computation-contract version.
The expected-output package must distinguish among:
byte-exact equality;
canonical-object equality;
deterministic identity equality;
tolerance-bound numerical comparison;
set equality;
order equivalence;
semantically equivalent enumerations;
intentionally variable envelope metadata; and
presentation-only differences.
Screenshots are useful documentation. They are not expected-output contracts.
The Runtime Evidence Record must be formed before the expected-output package becomes available to the comparison stage. A matching expectation cannot be used to repair or complete the record being tested.
The Fourteen Validation Protocols
The supplement defines fourteen validation protocols:
Deterministic replay — reproduction of governed outputs under the same eligible inputs and versions.
Ingestion conformance — preservation of source, role, event, adapter, and canonicalization relationships.
Source perturbation — controlled changes to source structure or content and inspection of resulting identity and evidence differences.
Cross-surface congruence — alignment among reconstruction, instruments, Evidence State, Human Read, investigation, Passport, and export.
Temporal leakage — detection of future-information use outside the eligible evidence horizon.
Boundary and lead-time evaluation — correct treatment of candidate boundaries, confirmed Basin Exit, failure anchors, warning windows, and formal lead time.
Role-topology ablation — evaluation of findings when role or interaction information is removed or changed under controlled conditions.
Instrument dependency analysis — verification that instruments honor required signals, substrate state, missingness, and authority limits.
Stable and negative controls — confirmation that absent phenomena and stable cases remain correctly unasserted.
Export round trips — preservation of identity, structure, manifest, seal, lineage, and claim boundaries through export and reload.
Adversarial source isolation — verification that case framing, embedded instructions, expected labels, and interface metadata do not contaminate computation.
External-log generalization — evaluation of declared methods against operational records outside controlled fixture structure.
Capacity and preservation — behavior across supported evidence volumes, reconstruction modes, and preservation requirements.
Operator interpretation — evaluation of whether Human Read, Guided Investigation, Operational World context, and cockpit adaptation preserve the canonical evidence and its limitations.
These protocols test different propositions.
A parser test can establish that roles were preserved correctly. It cannot establish that role fragmentation is a valid scientific construct.
A deterministic replay can establish that the same governed outputs were reproduced. It cannot establish that a boundary marker predicts operational failure.
A retrospective case may identify a possible warning interval. It cannot support a prospective prediction claim without held-out evaluation, eligible evidence at the claimed time, and an independently qualified failure anchor.
Aperture therefore requires validation claims to remain specific to the evidence and protocol that support them.
Negative and Failed Cases
A serious validation system must preserve stable, null, absent-pattern, contradictory, inconclusive, and failed cases—not only examples that produce striking findings.
The validation framework must represent states such as:
available;
not observed;
not supplied;
not computed;
insufficient window;
unavailable dependency;
candidate only;
proxy-only;
outside scope;
not demonstrated;
inconclusive;
comparison not matched; and
execution or conformance failed.
These states must not be silently converted into zero, normal, safe, low risk, or negative conclusions.
A stable negative case is scientifically valuable because it tests whether an instrument refrains from producing a finding when the required evidence is absent.
The ability not to make a claim is part of an instrument's validity.
Failed cases must remain part of the release record when they affect advertised behavior, known limitations, or scientific interpretation.
Integrity and Release Identity
Reproducibility requires more than a product version number.
A conforming release should bind the complete computational environment through distinct integrity layers, which may include:
raw source identity or hash;
canonical source identity or hash;
run identity;
computation-contract hash;
registry and schema bundle hash;
software or build hash;
Runtime Evidence Record identity or hash;
Runtime Evidence Passport and Evidence Seal references;
expected-output bundle hash;
Validation Result Record identity; and
preservation-artifact hashes.
The release manifest should identify:
exact software and build;
runtime and dependency environment;
schemas, registries, and method versions;
parameters and thresholds;
fixtures and source references;
expected-output packages;
validation protocol versions;
comparison rules;
known failures and limitations;
completed validation reports;
superseded versions; and
materials required for replication.
Published records must not be silently replaced. Corrections require a new version, an explanation of the defect, identification of affected artifacts and claims, and preservation of the original record.
The Evidence Seal protects the declared evidence-bearing core of a record. It does not replace the release manifest, software hash, expected-output hash, or artifact identity. Each integrity layer answers a different question.
Release Requirements
A release presented as conformant should publish or make inspectable:
public release identity;
implementation and build identity;
canonical schema bundle;
semantic registry versions;
runtime Signal Authority;
research-to-runtime signal crosswalk;
instrument contract versions;
temporal and claim-authority contracts;
evidence-authority conformance rules;
Validation Harness and protocol versions;
bound fixtures and expected-output packages where releasable;
known failures and unresolved discrepancies;
preservation and replay requirements;
certification scope; and
explicit non-certifications.
Where a required component cannot be published because of privacy, licensing, security, or intellectual-property restrictions, the release must identify the limitation and the resulting effect on reproduction or independent challenge.
Conformance cannot be inferred from a marketing version, interface label, or successful demonstration alone.
Independent Replication
The supplement defines replication as an executable procedure rather than a request to trust the originating team.
An independent team should be able to:
obtain and verify a complete release or replication package;
reproduce the declared environment;
verify schemas, registries, methods, and contract versions;
load a bound source through the registered ingestion path;
compare qualification and canonicalization results;
reconstruct the runtime;
compute the Current Evidence Run;
issue or withhold the Runtime Evidence Record and Passport under the declared authority rules;
export and reload the preservation artifact;
compare governed objects with the expected-output package;
repeat the process within and across declared environments;
run negative, perturbation, temporal-leakage, anti-contamination, and authority tests;
classify every discrepancy; and
publish the resulting identities, hashes, methods, failures, and limitations.
Replication does not require agreement with Longitudinal Computational Dynamics® or with the interpretation of a finding. It requires sufficient information to reproduce, test, challenge, or falsify a specified computational or scientific claim. An independent replication result may be positive, partial, negative, inconclusive, or blocked by unavailable materials. Each state is more informative than an unsupported assertion of reproducibility.
What the Supplement Establishes
The supplement establishes the conditions under which Aperture can demonstrate that:
a source was acquired and qualified through a declared method;
an ordered canonical runtime was constructed;
signals, markers, regimes, roles, and Instrument Findings were computed through identified contracts;
active outputs remained bound to one Current Evidence Run;
issued outputs remained bound to one Runtime Evidence Record and Passport identity;
claims were admitted, qualified, or rejected through explicit evidence and authority boundaries;
validation expectations remained isolated from evidence computation;
results reproduced—or differed—under a specified protocol;
discrepancies were classified rather than concealed; and
a preservation artifact contains the objects, identities, hashes, omissions, and lineage it claims to contain.
It does not establish through architecture alone:
hidden model state or private reasoning;
consciousness, cognition, intent, agency, or identity;
blame or unique cause;
objective truth;
universal dynamical laws;
universal safety or deployment readiness;
regulatory compliance or legal admissibility;
calibrated probability without calibration;
predictive performance without prospective evaluation;
generalization beyond tested conditions; or
independent replication before an unaffiliated party has completed it.
Those conclusions require different evidence and, where appropriate, independent scientific, operational, legal, regulatory, or domain-specific evaluation.
Why This Supplement Matters
Many analytical systems publish conclusions without publishing the contracts that authorize them. Measurements appear in dashboards without recoverable methods. Classifications are presented without defined evidence horizons. Validation cases are named without source-bound fixtures. Reproducibility is implied without frozen releases, expected outputs, integrity layers, or discrepancy reports.
The SubstrateX Aperture™ Technical and Validation Supplement is designed to make those gaps visible.
Its central contribution is not a declaration that every scientific question has been resolved. It is the establishment of a public structure through which those questions can be tested without surrendering evidence authority to the interface, instrument, fixture, validation harness, or system creator.
It makes possible:
semantic inspection;
implementation conformance testing;
deterministic replay;
controlled validation;
negative and failed-case preservation;
release comparison;
artifact verification;
independent challenge; and
eventual replication under disclosed conditions.
The Governing Definition
The Technical and Validation Supplement is the versioned public contract through which SubstrateX Aperture™ registers its signals, instruments, canonical objects, evidence authorities, schemas, maturity states, validation protocols, integrity requirements, release identities, expected-output rules, and replication procedures so that a specific implementation can be inspected, reproduced, challenged, and—only where the evidence warrants it—validated.
Within the Engineering section, the Technical and Validation Supplement follows the Validation Harness and precedes What the Code Actually Does.
The sequence is deliberate:
Execute the implementation → test it under controlled conditions → publish the contracts and limitations → examine what the code actually establishes
Aperture does not ask investigators to trust its explanation. It defines the conditions under which its evidence, computation, and claims can be independently inspected, reproduced, challenged, and—where the results warrant it—validated.