Fieldglass® Technical and Validation Supplement

The Public Contract for Conformance, Reproducibility, and Independent Challenge

The Fieldglass Technical and Validation Supplement defines how a Fieldglass release can be identified, inspected, tested, compared, and challenged.

The Fieldglass Foundational System paper explains what the observatory is. The Engineering Architecture explains how the implementation is organized. This supplement establishes the versioned technical contracts needed to determine whether a specific release behaves as claimed.

A working interface demonstrates implementation. It does not, by itself, establish determinism, scientific validity, predictive performance, 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

Fieldglass transforms operational records into source-bound runtime reconstructions, measurements, classifications, investigative projections, 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 and canonicalized?

  • Which method produced each measurement?

  • Which parameters, thresholds, and temporal coordinates were used?

  • What evidence supports each marker or classification?

  • Which outputs must reproduce exactly?

  • Which differences are permissible?

  • What was not observed, computed, validated, or demonstrated?

  • Which claims does the evidence authorize?

  • What would cause the system to reject a claim?

The supplement converts these questions into versioned registries, schemas, validation protocols, release requirements, and replication procedures.

Its governing principle remains:

One evidence object. One authority. Multiple bounded projections.

What the Supplement Registers

The current semantic baseline defines the technical identity of the Fieldglass measurement system across several coordinated registries.

Canonical Signals

The supplement registers 28 research-facing behavioral signals across four families:

  • motion and coherence;

  • temporal organization;

  • formation and boundary dynamics;

  • role and interaction dynamics.

Each signal contract identifies:

  • the construct being represented;

  • eligible source and canonical inputs;

  • temporal scope and ordering assumptions;

  • method and parameter requirements;

  • output type, unit, range, and precision;

  • missingness behavior;

  • evidence and authority class;

  • allowed interpretations;

  • prohibited claims;

  • validation 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.

Scientific Instruments

The supplement defines nine read-only instrument contracts:

  • Seismo

  • Chronos

  • Drift

  • Pressure

  • Bridge

  • Noesis

  • Scope

  • Dynamics

  • Interferometer

Every instrument reads from the same Certified Runtime Evidence Record. Instruments may select, transform, compare, or visualize authorized evidence, but they cannot create a second source of truth, invent missing values, 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;

  • canonical runtime events;

  • runtime spines and playback frames;

  • signal and marker records;

  • regime classifications;

  • Certified Runtime Evidence Records;

  • Runtime Evidence Passports;

  • claim and challenge records;

  • instrument findings;

  • projection objects;

  • preservation manifests;

  • and release identities.

These contracts preserve the distinctions between source evidence, deterministic computation, contextual information, interpretation, visualization, and preservation.

Temporal and Claim Authority

The supplement also governs:

  • event, turn, wall-clock, dependency, and symbolic-time coordinates;

  • candidate and confirmed runtime markers;

  • prospective and retrospective computation;

  • Basin Exit and recovery conditions;

  • formal Lead-Time admissibility;

  • claim classes;

  • evidence horizons;

  • and protection against future-information leakage.

A temporal warning claim is admissible only when the detector, eligible evidence horizon, ordering relation, failure anchor, and temporal coordinate are declared.

Five Different States of Scientific Maturity

One of the supplement’s most important contributions is its separation of claims that are often treated as interchangeable.

StateWhat it establishesDefinedThe construct has a stable, versioned semantic contract.ImplementedA frozen release contains an executable method associated with that contract.DeterministicRepeated eligible computation reproduces governed outputs within declared tolerances.ValidatedThe outputs demonstrate specified relationships to controlled constructs or external criteria.Independently replicatedAn unaffiliated party reproduces the specified result from the released materials.

A construct can be defined without being implemented.

A method can be implemented without being deterministic.

A deterministic measurement can remain scientifically unvalidated.

A validated result does not become independently replicated until another party reproduces it.

Determinism establishes reproducibility under a declared contract. It does not establish scientific truth.

Six Surfaces of Conformance

Fieldglass 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, and canonicalized as declared.

  2. Computational conformance
    Whether methods, parameters, dependencies, ordering rules, precision, and missingness behavior match the registered contract.

  3. Object conformance
    Whether the release produces the required runtime, evidence, Passport, marker, claim, projection, and preservation objects.

  4. Authority conformance
    Whether every authoritative output resolves to the same evidence object and remains inside its claim boundary.

  5. Artifact conformance
    Whether exports preserve identifiers, hashes, versions, omissions, uncertainty, lineage, and challenge paths.

  6. Validation conformance
    Whether tests use bound fixtures, expected outputs, declared environments, pass criteria, 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 Fixture 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;

  • provenance and permitted use;

  • a declared test purpose;

  • source and canonical hashes;

  • expected qualification results;

  • expected runtime objects;

  • expected signal and marker outputs;

  • comparison rules and tolerances;

  • expected claim-boundary decisions;

  • and a specific software and computation-contract version.

The expected-output package must also distinguish between:

  • byte-exact equality;

  • canonical-object equality;

  • tolerance-bound numerical comparison;

  • set or order equivalence;

  • intentionally variable metadata;

  • and presentation-only differences.

Screenshots are useful documentation, but they are not expected-output contracts.

The Validation Framework

The supplement defines 14 validation protocols covering:

  • deterministic replay;

  • ingestion conformance;

  • source perturbation;

  • cross-surface congruence;

  • temporal leakage;

  • boundary and Lead-Time evaluation;

  • role-topology ablation;

  • instrument dependency analysis;

  • stable and negative controls;

  • export round trips;

  • adversarial source isolation;

  • external-log generalization;

  • capacity and preservation;

  • and operator interpretation.

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 and an independently qualified failure anchor.

Fieldglass therefore requires validation claims to remain specific to the evidence and protocol that support them.

Negative Cases Matter

A serious validation system must preserve stable, null, absent-pattern, and failed cases—not only examples that produce striking findings.

The validation framework requires Fieldglass to represent states such as:

  • not observed;

  • not computed;

  • insufficient window;

  • unavailable dependency;

  • outside scope;

  • not demonstrated;

  • inconclusive;

  • and failed.

These states must not be silently converted into zero, normal, safe, or low-risk 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 the instrument’s validity.

Integrity and Release Identity

Reproducibility requires more than a product version number.

A conforming release must bind the complete computational environment through distinct integrity layers:

  • raw source hash;

  • canonical source hash;

  • computation-contract hash;

  • registry and schema bundle hash;

  • Certified Runtime Evidence Record hash;

  • software or build hash;

  • and preservation-artifact hashes.

The release manifest must identify the exact software, dependencies, methods, parameters, fixtures, expected outputs, known failures, validation reports, and superseded versions associated with the release.

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.

Independent Replication

The supplement defines replication as an executable procedure rather than a request to trust the author.

An independent team should be able to:

  1. obtain and verify a complete release package;

  2. reproduce the declared environment;

  3. load the bound source through the registered intake path;

  4. compare qualification and canonicalization results;

  5. reconstruct the runtime;

  6. compute the evidence record;

  7. issue the Passport;

  8. export the preservation artifact;

  9. compare governed objects with expected outputs;

  10. repeat the process within and across environments;

  11. run negative, perturbation, leakage, and authority tests;

  12. classify every discrepancy;

  13. and publish the resulting hashes, methods, failures, and limitations.

Replication does not require agreement with Recursive Science or the interpretation of a finding. It requires sufficient information to reproduce, test, or falsify a specified claim.

Current Baseline

FG-TVS-2026.1, Version 1.0.0 establishes the current canonical semantic baseline for:

  • 28 research-facing signal contracts;

  • nine instrument contracts;

  • canonical evidence and preservation objects;

  • seven Operational Worlds;

  • eight operational samples;

  • 26 reported validation cases;

  • one source-bound 160-turn fixture;

  • expected-output requirements;

  • 14 validation protocols;

  • integrity and release-hash requirements;

  • and an independent replication procedure.

The semantic registry and executable implementation remain separately versioned. The reviewed RL1331 implementation currently maintains a 25-entry runtime Signal Authority, while the supplement defines a 28-signal research-facing architecture. A conforming release must publish an explicit crosswalk between these layers rather than treating the counts as interchangeable.

The current supplement does not claim that every registered construct has already been calibrated or independently replicated. It records the materials still required for higher validation levels, including a frozen executable release, complete algorithm bindings, machine-readable schemas, complete fixture and expected-output bundles, cross-environment replay results, independent external datasets, calibrated predictive studies, and unaffiliated replication.

These are not hidden omissions. They are part of the public evidentiary state of the system.

What the Supplement Establishes

The supplement establishes the conditions under which Fieldglass can demonstrate that:

  • a source was acquired and qualified through a declared method;

  • an ordered runtime representation was constructed;

  • signals, markers, regimes, roles, and instrument projections were computed through identified contracts;

  • authoritative outputs remain bound to one Certified Runtime Evidence Record;

  • claims were admitted, qualified, or rejected through explicit boundaries;

  • results reproduce—or differ—under a specified protocol;

  • and a preservation artifact contains the objects and hashes it claims to contain.

It does not establish, through architecture alone:

  • consciousness or sentience;

  • hidden model state;

  • internal reasoning;

  • intent or deception;

  • blame or unique cause;

  • objective truth;

  • universal dynamical laws;

  • operational safety;

  • regulatory compliance;

  • legal admissibility;

  • or calibrated prediction.

Those conclusions require different evidence and, where appropriate, independent scientific, operational, legal, 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 or expected outputs.

The Fieldglass Technical and Validation Supplement is designed to make those gaps visible.

Its central contribution is not a declaration that every scientific question has already been resolved. It is the establishment of a public structure through which those questions can be tested without surrendering evidence authority to the interface, the instrument, or the system’s creator.

Fieldglass 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.

Read the Fieldglass Technical and Validation Supplement

Versioned registries, validation protocols, release requirements, and replication materials for the Fieldglass Runtime Evidence Observatory.