Known-Scenario Testing in a Controlled Evidence Chamber

The Fieldglass 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 source material, expected evidence, prohibited claims, and validation conditions are declared. Fieldglass then processes the record without access to the expected result and compares the resulting evidence against the declared expectations.

Declare the expectation. 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, telemetry, reconstruction, instrumentation, interpretation, and preservation architecture used throughout Fieldglass.

The Controlled Evidence Chamber

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

Each chamber binds together:

• a preserved scenario source;

• a scenario identifier and version;

• a declared Operational World;

• source-family and adapter information;

• canonicalization settings;

• an expected evidence map established before computation;

• expected positive, negative, and unavailable findings;

• applicable instrument and signal contracts;

• the Fieldglass release and method versions;

• explicit claim boundaries; and

• the resulting validation comparison.

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

A scenario cannot alter telemetry, thresholds, runtime construction, temporal markers, regime calculations, instrument findings, or evidence-support status. Its expected evidence remains outside the active computation until the comparison stage.

One Engine for Acquisition and Validation

Fieldglass provides two related paths through the same architecture.

PathGoverning questionEvidence AcquisitionWhat can Fieldglass reconstruct from this supplied operational record?Evidence ValidationDoes a known record produce the evidence expected under declared contracts and conditions?

Both paths use the same browser-local evidence engine:

Source Record
→ Qualification and Canonicalization
→ Current Evidence Run
→ Runtime Stability Foundation
→ Instrument Findings
→ Runtime Reconstruction
→ Evidence-Bound Interpretation
→ Preserved Record

There is no sample-specific telemetry path and no hidden validation override.

For the same canonical source, configuration, implementation release, and contract versions, Fieldglass should reproduce the same deterministic evidence identity and core computational findings. Issuance timestamps, operator annotations, 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 being tested, the operational context, required evidence, expected absences, and applicable claim boundary.

02 — Load

Load the preserved source material through the normal ingestion path.

The source is qualified, its family is detected, applicable adapters are disclosed, roles and events are mapped, and the raw record remains preserved.

03 — Declare

Review the expected evidence map before computation.

The map specifies what the case is expected to support, what should remain absent or unavailable, and what the system must not claim.

04 — Compute

Process the source through the standard Fieldglass evidence engine.

The active Current Evidence Run becomes the sole computational authority. Scenario labels and expected outcomes do not participate in measurement.

05 — Compare

Compare the observed findings with the predeclared evidence map.

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

06 — Preserve

Seal the completed validation as a Certified Runtime Evidence Record with its source identity, method versions, comparison results, limitations, provenance, and claim boundary intact.

Evidence Case Library

The Validation Harness includes controlled reference cases representing different forms of longitudinal computational behavior.

CasePrimary validation focusS1 — Stable ControlStable baseline behavior and resistance to false-positive instability findingsCH-1 — Echo-Time RunawayRecurrence, temporal deformation, compression, and accumulating runtime pressureRB-1 — Stable Role WorkflowCoherent handoffs, low cross-role displacement, and stable coordinationRB-2 — Manager / Engineer MisalignmentAuthority tension, role-phase lag, and persistent coordination displacementRB-3 — Tool Failure Retry LoopTool recurrence, retry pressure, temporal shear, and loop formationRB-5 — Observer Contradicts StateDivergence among source-supported state claims without determining truth, intent, or blameNO-1 — Symbolic Drift / Anchor LossChanging symbolic density, weakening continuity, and reduced anchoringRC-1 — Recovery After Boundary PressurePressure, correction, recovery posture, and evidence supporting sustained re-entryGV-1 — Claim Boundary Stress TestWhether the system refuses unsupported conclusions about intent, blame, causation, or objective truth

The library is organized across operational contexts such as:

• Monitoring Blind Spots;

• Workflow Coordination;

• Software Engineering;

• Security and SIEM;

• Cloud Infrastructure;

• Attention and Long-Horizon Work;

• Determinism and Validation.

Some controlled Atlas cases are paired with real-log alternates, including CI and cloud-infrastructure records. These alternates test whether the architecture can process more irregular operational material while preserving source identity, adapter provenance, and the distinction between synthetic fixtures and real-world records.

A controlled scenario and a real-world alternate are never treated as equivalent sources merely because they examine similar conditions.

Expected Evidence Maps

Every validation case begins with an expected evidence map.

The map may define:

• the operator question;

• expected source and role structures;

• expected observable events;

• required telemetry coverage;

• anticipated regime or transition posture;

• temporal markers that should be available;

• findings that should remain absent;

• evidence that may be unavailable;

• recommended investigative paths; and

• conclusions prohibited by the claim boundary.

Expected evidence is declared before computation to prevent retrospective adjustment of the hypothesis to match the result.

A validation comparison may return:

• Matched — the observed evidence satisfies the declared condition;

• Partially matched — some, but not all, required evidence is present;

• Not matched — the expected condition is not supported;

• Unexpected finding — an undeclared finding was produced and requires inspection;

• Unavailable — required source coverage or authority is missing; or

• Inadmissible — the proposed comparison exceeds the evidence or instrument contract.

Negative findings matter. A stable control should not be forced into a failure regime, and missing evidence should not be converted into a zero, a negative result, or an inferred event.

What the Harness Tests

The Validation Harness supports several distinct forms of evaluation.

Replay Determinism

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

Schema Conformance

Whether runtime objects, instrument findings, evidence bundles, Passports, and preserved records conform to their declared schemas.

Instrument Contract Conformance

Whether each instrument reads only authorized evidence, 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.

Negative-Control Behavior

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

Cross-World Consistency

Whether different operational records are normalized into the shared architecture without allowing domain language or selected Operational World to change canonical telemetry.

Preservation Integrity

Whether the resulting artifact retains its source identity, release information, methods, findings, limitations, provenance, and claim boundary through export and replay.

Temporal and Boundary Validation

The harness explicitly tests distinctions that conventional demonstrations can easily obscure.

A Basin Exit is valid 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 markers are available:

• t* — the qualifying boundary marker; and

• tf — the observable failure marker.

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

The harness also tests whether Fieldglass preserves distinctions between:

• candidate and confirmed;

• observation and computation;

• finding and interpretation;

• absent and unavailable;

• temporary correction and supported recovery;

• operational association and causation; and

• deterministic output and validated scientific truth.

The Validation Certificate

A completed validation run can produce a versioned validation certificate recording:

• scenario and source identity;

• canonical evidence hash;

• Fieldglass release;

• adapter and schema versions;

• instrument and signal-contract versions;

• declared expectations;

• observed findings;

• comparison states;

• replay result;

• missing or contradictory evidence;

• claim boundary; and

• preservation status.

The certificate confirms that a specified case was executed and compared under declared conditions.

It does not certify that:

• every scientific construct is universally valid;

• Fieldglass has established objective truth;

• a system is safe or compliant;

• an observed relationship is causal;

• a proxy is a calibrated probability; or

• the result constitutes independent replication.

From Internal Validation to Independent Challenge

The Validation Harness makes Fieldglass testable. It does not make Fieldglass 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:

• held-out and adversarial cases;

• independently sourced datasets;

• prospective testing;

• threshold calibration;

• comparison against alternative methods;

• cross-model and cross-system studies;

• external reviewers; and

• independent replication.

Reviewer-ready bundles can provide the fixtures, expected evidence maps, schemas, version manifests, release hashes, replication instructions, and known limitations required for that work.

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

Why the Validation Harness Matters

A scientific observatory should not demonstrate itself only through selected screenshots or persuasive interpretations. Its evidence pipeline must be capable of confronting stable controls, missing evidence, contradictory records, failed expectations, and results that do not support the proposed construct.

The Fieldglass Validation Harness creates that environment.

It turns validation into an inspectable evidence process: expectations are declared before computation, the source is preserved, the production engine remains unchanged, mismatches stay visible, and the resulting artifact can be replayed and challenged.

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