Known-Scenario Testing in a Controlled Evidence Chamber

The SubstrateX Aperture™ Validation Harness is a browser-local testing architecture for determining whether known source records produce reproducible, contract-conformant, and evidence-bounded results through the same computational pipeline used for operator-supplied evidence.

Before computation begins, the scenario source, expected evidence, expected absences, prohibited claims, and validation conditions are declared. Aperture then processes the source without access to the expected result. Only after the Runtime Evidence Record has been formed does the harness compare the observed evidence with the predeclared expectation map.

Declare the expectation. Isolate it from computation. Preserve the source. Run the same engine. Inspect the difference.

The Validation Harness does not create a favorable result, substitute expected values for computed findings, or use a separate demonstration engine. It exercises the same ingestion, canonicalization, reconstruction, telemetry, instrumentation, evidence-authority, REIM, synthesis, Human Read, and preservation architectures used throughout Aperture.

Its governing distinction is:

The evidence run is computed first. The validation comparison is formed afterward. The comparison may evaluate the evidence; it may never rewrite it.

The Controlled Evidence Chamber

The Evidence Chamber is the controlled environment within which one validation case is executed.

Each chamber may bind together:

• a preserved scenario source;

• scenario identity and version;

• source classification, provenance, and fixture type;

• declared source family and applicable adapter configuration;

• canonicalization and computation settings;

• an Operational World used for contextual guidance;

• an expected evidence map established before computation;

• expected positive, negative, partial, and unavailable findings;

• applicable signal, temporal, instrument, REIM, and preservation contracts;

• the Aperture release and method versions;

• explicit claim boundaries and prohibited claims;

• the resulting Runtime Evidence Record and Passport identity; and

• a separate validation comparison record.

The chamber controls the test conditions. It does not control the result.

A scenario cannot alter telemetry, thresholds, runtime construction, temporal markers, regime computation, Instrument Findings, REIM classification, evidence-support state, certification posture, or Evidence Seal. Its expectations remain outside the active evidence computation until the comparison stage.

The Two-Object Validation Model

Validation requires two distinct objects.

Runtime Evidence Record
Contains the evidence computed from the scenario source through the standard Aperture pipeline.Must be formed without access to expected labels, fixture outcomes, rubric scores, or comparison results.

Validation Comparison Record
Compares the issued evidence record with the predeclared expectation map and records agreement, mismatch, absence, and inadmissibility.May evaluate the record but cannot alter its identity, findings, Passport, Evidence Seal, or certification scope.

The two objects may be packaged together in a preserved validation artifact, but they remain separately identifiable.

This separation protects deterministic evidence identity. A change to the expected evidence map may change the validation comparison and its artifact identity. It must not change the canonical runtime, run identity, Runtime Evidence Record, or Evidence Seal produced from the unchanged source and computation.

Expectation is test context—not evidence input.

Anti-Contamination Architecture

The Validation Harness must prevent case knowledge from leaking into the computation it is intended to test.

The following may participate in evidence computation when explicitly declared as normal run inputs:

• the preserved scenario source;

• the selected ingestion adapter and canonicalization configuration;

• registered computational methods and thresholds;

• applicable schemas and registries; and

• source- or operator-declared context that would also be available in an ordinary run.

The following must remain outside evidence computation:

• scenario title or sample identity;

• fixture metadata describing the expected outcome;

• expected evidence labels;

• known-case classification;

• validation rubric scores;

• expected markers or regimes;

• case narrative or framing written to explain the scenario;

• target Human Read language;

• comparison status; and

• interface state.

These excluded objects must not enter:

• telemetry formation;

• marker placement;

• regime classification;

• Instrument Findings;

• the Runtime Stability Foundation;

• Runtime Evidence Interpretation Matrix (REIM) features or class scoring;

• Human Read propositions;

• Runtime Evidence Authority conformance; or

• Passport issuance.

Known-case expectations may be evaluated after computation. They cannot serve as evidence during computation.

This prevents the harness from succeeding merely because it already knows the answer.

One Engine for Evidence Acquisition and Validation

Aperture provides two related uses of the same architecture.

Evidence acquisition asks:

What can Aperture reconstruct and establish from this supplied operational record?

Evidence validation asks:

Does a known record produce the evidence expected under declared contracts and conditions?

Both use the same browser-local evidence engine:

Source record
↓
Qualification and canonicalization
↓
Runtime reconstruction and behavioral telemetry
↓
Current Evidence Run
↓
Instrument Findings, REIM, synthesis, and Human Read
↓
Runtime Evidence Authority
↓
Runtime Evidence Record, Passport, and Evidence Seal

For the same normalized source, configuration, implementation release, and governing contract versions, Aperture should reproduce the same deterministic evidence identity and core computational findings. Validation timestamps, reviewer annotations, comparison notes, and other declared envelope metadata may vary without changing that deterministic core.

The Validation Workflow

01 — Select

Choose a known operational scenario from the Evidence Case Library.
Each case identifies the behavior or contract being tested, source type, fixture provenance, required evidence, expected absences, prohibited claims, and applicable comparison rules.
Selection identifies the test. It does not supply an answer to the evidence engine.

02 — Load

Load the preserved source through the normal Ingestion Engine.
The source is qualified, its family is evaluated, the applied adapter is disclosed, roles and events are mapped with provenance, and the raw record remains preserved.
The selected Operational World may guide the interface. It does not alter ingestion or telemetry.

03 — Declare

Review and lock the expected evidence map before computation.

The map specifies:

• what the case is expected to support;

• what should remain absent, negative, partial, or unavailable;

• which markers or claims require particular evidence;

• which comparison rules apply; and

• what the system must not claim.

Locking the expectation before compute prevents retrospective adjustment of the test to match the output.

04 — Compute

Process the source through the standard Aperture evidence engine.

The Current Evidence Run becomes the sole active computational authority. Scenario labels, expected outcomes, rubric scores, and interface state remain unavailable to evidence formation.

The resulting Runtime Evidence Record, Passport, and Evidence Seal are issued or withheld according to the same authority conditions applied to ordinary records.

05 — Compare

Compare the issued evidence with the locked expectation map.

The comparison records agreement, partial agreement, absence, unexpected findings, unavailable evidence, and inadmissible expectations without rewriting the run.

If the evidence record was not issued, the comparison must preserve the issuance failure and evaluate only what remains legitimately inspectable.

06 — Preserve

Preserve the validation artifact with both objects intact:

• the independently computed Runtime Evidence Record and Passport; and

• the Validation Comparison Record bound to that evidence identity.

The artifact may also contain the scenario source, expectation map, method versions, comparison rules, reviewer context, limitations, and claim boundaries according to the applicable preservation contract.

The Evidence Case Library

The Evidence Case Library contains controlled reference cases representing different forms of longitudinal computational behavior and evidence conditions.

Cases may be organized across contexts such as:

• monitoring and reliability;

• workflow coordination;

• software engineering and continuous integration;

• security operations and SIEM;

• cloud infrastructure;

• attention and long-horizon work;

• agent and tool workflows;

• stable and negative controls; and

• determinism and conformance validation.

The library may contain:

• synthetic fixtures designed to isolate a declared condition;

• controlled multi-stage scenarios;

• stable controls;

• missing-evidence cases;

• contradictory or ambiguous cases;

• adversarial fixtures;

• regression cases from earlier releases; and

• real-log alternates where use and disclosure are permitted.

A synthetic fixture and a real-world alternate are never treated as equivalent sources merely because they investigate a similar condition.

Each case should disclose:

• fixture or source type;

• origin and version;

• construction method where applicable;

• known modifications or redactions;

• intended validation purpose;

• expected evidence map version;

• applicable contracts; and

• limitations on generalization.

The case library provides reproducible test material. It is not an empirical substitute for independently sourced operational datasets.

Expected Evidence Maps

Every validation case begins with a versioned expected evidence map.

The map may define:

• validation question;

• expected source and role structures;

• expected observable events;

• required telemetry coverage;

• anticipated regime or transition posture;

• markers that should be available;

• findings expected to remain absent;

• evidence expected to be unavailable;

• expected REIM posture or admissible alternatives;

• recommended investigative path;

• preservation requirements; and

• conclusions prohibited by the claim boundary.

Expected evidence should be expressed as testable conditions rather than persuasive narrative.

Where practical, the map should identify:

• the relevant evidence path;

• comparison operator;

• tolerance or admissible range;

• required persistence;

• coordinate domain;

• expected availability state;

• versioned method or contract; and

• failure condition.

This makes the validation comparison inspectable and reduces post hoc reinterpretation.

Comparison States

A validation comparison may return:

Matched
The observed evidence satisfies the declared condition under the applicable comparison rule.

Partially matched
Some required evidence is present, but one or more conditions remain incomplete or unsupported.

Not matched
The expected condition is not supported by the observed evidence.

Unexpected finding
An undeclared finding was produced and requires inspection rather than automatic rejection.

Unavailable
Required source coverage, dependency, marker, or authority is missing.

Inadmissible
The expectation exceeds the evidence, method, calibration, or instrument contract.

These states describe the relationship between expectation and observation. They do not modify the observation.

Negative findings matter. A stable control should not be forced into a failure posture. Missing evidence should not be converted into zero, a negative result, or an inferred event. An unexpected finding should not be discarded merely because it was not predicted by the fixture.

What the Harness Tests

The Validation Harness supports several distinct forms of evaluation.

Replay Determinism

Whether identical canonical inputs and governing method versions reproduce the same deterministic evidence identity and core findings.

Canonical and Schema Conformance

Whether canonical runtime objects, Current Evidence Run structures, Instrument Findings, synthesis objects, Passports, and preserved records conform to their declared schemas and identity relationships.

Evidence-Authority Conformance

Whether computed material satisfies the declared provenance, legitimacy, coordinate, temporal, claim, Passport, seal, export, and preservation relationships required by Runtime Evidence Authority.

Metric-Legitimacy Conformance

Whether registered measurements use eligible inputs, disclose their authority class, preserve availability and missingness, and remain within their permitted interpretations.

Instrument Contract Conformance

Whether each instrument reads only authorized evidence, honors dependencies, produces permitted findings, exposes missingness, and remains within its stated claim boundary.

Scenario Reconstruction

Whether observable structures deliberately represented in a known case are reconstructed under the declared methods without using case identity as evidence.

Negative-Control Behavior

Whether stable cases, missing markers, unsupported claims, absent phenomena, and incomplete evidence remain correctly unasserted.

Anti-Contamination Conformance

Whether sample identity, expected outcomes, case framing, rubric scores, and interface state remain excluded from telemetry, findings, REIM, Human Read, Passport issuance, and the Evidence Seal.

Temporal and Prospective Admissibility

Whether temporal claims use the correct coordinate authority, eligible evidence horizon, and source-supplied anchors without future-information leakage.

Cross-World Consistency

Whether different operational records enter the shared evidence architecture without allowing domain language, selected Operational World, operator role, or cockpit profile to change canonical telemetry.

Preservation Integrity

Whether the resulting artifact retains source, canonical, run, record, Passport, and artifact identities together with methods, findings, comparison state, limitations, provenance, and claim boundaries.

These tests establish implementation behavior under declared conditions. They do not all establish scientific validity.

Temporal and Boundary Validation

The harness explicitly tests distinctions that conventional demonstrations can obscure.

A Basin Exit is supported only when the declared observable stability-boundary method produces a qualifying crossing. It is not proof of hidden internal instability.

Formal lead time is admissible only when both required anchors are available:

• t* — the qualifying boundary marker; and

• tf — the observable failure marker.

If no observable failure marker is supplied, Aperture may report a warning window or post-exit observation interval. It must not report formal lead time.

The harness also tests whether Aperture preserves distinctions between:

• candidate and confirmed;

• observation and computation;

• source-supplied and computed markers;

• finding and interpretation;

• absent, not observed, not supplied, and unavailable;

• temporary correction and supported recovery;

• operational association and causation;

• retrospective explanation and prospectively admissible signal; and

• deterministic output and scientifically validated construct.

A temporal expectation that depends on evidence occurring after the claimed warning point is inadmissible as a prospective result, even if it improves retrospective classification.

Validation Result Record and Certificate Scope

A completed validation run may produce a versioned Validation Result Record containing:

• scenario and source identity;

• expectation-map identity and version;

• canonical, run, Runtime Evidence Record, and Passport references;

• Evidence Seal;

• Aperture release;

• adapter, schema, registry, and method versions;

• declared expectations;

• observed findings;

• comparison states;

• replay result;

• missing or contradictory evidence;

• reviewer annotations identified as such;

• claim boundary; and

• preservation status.

If Aperture renders this record as a validation certificate, the certificate has a narrow scope. It confirms that a specified case was executed through the declared pipeline and compared with a predeclared expectation map under identified conditions.

It does not certify that:

• every scientific construct is universally valid;

• Aperture has established objective truth;

• the source is complete or representative of real-world use;

• a system is safe, aligned, compliant, or deployment-ready;

• an observed relationship is causal;

• a proxy is a calibrated probability;

• the scenario generalizes across models, domains, or institutions;

• the result constitutes independent replication; or

• a matching fixture proves that the tested construct is correct.

The validation record certifies execution and comparison scope—not universal scientific validity.

From Internal Validation to Independent Challenge

The Validation Harness makes Aperture testable. It does not make Aperture self-validating.

Controlled fixtures, known scenarios, replay tests, and conformance checks establish whether the implementation behaves consistently with its declared contracts. Broader scientific validation requires additional evidence, including:

• held-out and adversarial cases;

• independently sourced datasets;

• prospective testing;

• threshold and probability calibration;

• comparison with alternative methods;

• cross-model and cross-system studies;

• ablation and sensitivity analysis;

• false-positive and false-negative analysis;

• external reviewers; and

• independent replication.

Reviewer-ready bundles may provide:

• scenario sources or lawful access instructions;

• expected evidence maps;

• schemas and registry manifests;

• method and release versions;

• deterministic identity and seal references;

• comparison rules;

• replication instructions;

• validation results; and

• known limitations.

The Technical and Validation Supplement documents the contracts, registries, methods, versions, and validation references required to interpret those bundles. The Validation Harness executes the cases. The two responsibilities should remain distinct.

The implementation exposes its methods so its findings can be tested—not so its own outputs can serve as proof of validity.

Reference Evidence Artifacts

Each validation scenario may be preserved as a complete machine-readable Aperture artifact.

A reference artifact records the result of processing a known source through the standard browser-local evidence engine and comparing the issued record with a declared expectation map. It allows reviewers to inspect the relationship among:

• the supplied source;

• ingestion and canonicalization;

• the canonical runtime;

• computed measurements;

• temporal markers;

• Instrument Findings;

• Runtime Reconstruction;

• REIM, synthesis, and Human Read;

• Runtime Evidence Authority;

• the Passport and Evidence Seal;

• the expected evidence map;

• the validation comparison;

• provenance and versioning; and

• claim boundaries.

A reference artifact is not a screenshot of the result. It is the structured computational and validation record from which the result was presented.

Reference artifacts allow another investigator to determine:

• which source and scenario were used;

• whether the source was synthetic, controlled, modified, or operational;

• which Aperture release and contracts governed computation;

• which evidence objects were produced;

• which signals and findings were available;

• which markers were observed or computed;

• what evidence remained missing;

• how expectations compared with observations;

• how interpretations were bounded; and

• what was preserved for replay or independent comparison.

A published artifact demonstrates that Aperture produces an exportable and inspectable evidence structure under declared methods. It does not, by itself, prove the scientific validity of every construct represented within it.

Evidence Commons may preserve and make such artifacts available for review according to their privacy, disclosure, and sharing conditions. Preservation does not enlarge their certification scope.

The Claim Boundary

The Validation Harness does not independently establish:

• objective truth;

• hidden model state or private reasoning;

• intent, consciousness, cognition, agency, or identity;

• root cause or universal causation;

• human or organizational blame;

• universal safety, deployment readiness, or regulatory compliance;

• calibrated probability without applicable calibration;

• generalization beyond the tested cases;

• independent replication; or

• required operational action.

The harness answers narrower questions about whether Aperture behaved reproducibly and conformantly under declared test conditions and whether observed results agreed with predeclared expectations.

Why the Validation Harness Matters

A Runtime Evidence Observatory should not demonstrate itself only through selected screenshots, favorable fixtures, or persuasive interpretations. Its evidence pipeline must confront stable controls, missing evidence, contradictory records, failed expectations, unexpected findings, and cases that do not support the proposed construct.

The SubstrateX Aperture™ Validation Harness creates that environment.

It turns validation into an inspectable evidence process:

• expectations are declared and locked before computation;

• scenario knowledge remains outside the evidence engine;

• the source is preserved;

• the production pipeline remains unchanged;

• the Runtime Evidence Record is issued independently of expected outcomes;

• mismatches, absences, and unexpected findings remain visible;

• comparison results remain separate from the evidentiary core;

• negative controls can falsify inappropriate behavior;

• the complete lineage can be replayed; and

• the resulting artifact can be challenged independently.

The contribution is not a demonstration mode. It is a controlled architecture for testing whether Runtime Evidence Infrastructure behaves according to its declared contracts without allowing the test to determine its own result.

The Governing Definition

The Validation Harness is the browser-local, anti-contamination testing architecture through which SubstrateX Aperture™ processes known and controlled sources through its standard evidence pipeline, issues the resulting Runtime Evidence Record independently of scenario expectations, compares that record with a predeclared evidence map, and preserves agreement, mismatch, absence, uncertainty, and claim limits without altering the evidence being tested.

Within the Engineering section, the Validation Harness follows the Adaptive Evidence Cockpit and precedes the Technical and Validation Supplement.

The sequence is deliberate:

Adapt the operator environment → execute controlled cases → document methods and validation lineage

Aperture does not validate itself by displaying the result it was designed to find. It preserves the source, isolates the expectation, runs the same evidence engine used for every record, and exposes the agreement, mismatch, absence, and uncertainty for inspection.