Source-Bound, Deterministic, and Claim-Governed Reconstruction

Computational systems leave behind logs, traces, transcripts, tool events, alerts, tickets, and incident records. These records may show what was captured, but they do not automatically provide a coherent or accountable reconstruction of how behavior developed through time.

Runtime Evidence addresses the gap between retained records and defensible reconstruction.

Runtime Evidence is a source-bound, deterministic, and claim-governed reconstruction of longitudinal computational behavior.

It is not merely data captured while computation was running. It is an inspectable evidence object whose sources, transformations, measurements, authority, limitations, and preservation state remain explicit.

Records Are Not Yet Evidence

Operational records are often fragmented, incomplete, differently structured, weakly ordered, and ambiguous about roles or responsibility. A log entry may identify an event without explaining its relationship to earlier activity. A transcript may preserve language without distinguishing observed roles from inferred ones. A dashboard may display a score without retaining the method or source material that produced it.

Runtime Evidence does not treat these records as self-explanatory.

It asks:

• What source material was supplied?

• How was that material qualified?

• Which events and relationships can be reconstructed?

• What ordering does the record actually support?

• Which values were observed, declared, computed, or inferred?

• What evidence supports each measurement?

• Which conclusions are admissible?

• What remains unknown, unavailable, or outside the claim boundary?

The objective is not to generate the most persuasive explanation. It is to construct the strongest account the available evidence can legitimately support.

From Operational Record to Runtime Evidence

Runtime Evidence transforms source material through a declared and inspectable process:

Source Record
→ Qualification
→ Canonical Runtime
→ Versioned Measurement
→ Longitudinal Reconstruction
→ Runtime Evidence Record
→ Bounded Projections
→ Preservation

The source is first preserved and qualified. Events, participants, roles, timing, dependencies, and source locations are then organized into a canonical runtime representation.

Measurements may be computed only through identified methods. Worldlines, regimes, transitions, role relations, and investigative findings are constructed from this shared record. Every resulting view remains connected to the same evidence authority.

If the source, parser, threshold, algorithm, or measurement contract changes, the reconstruction becomes a new version. The previous record is not silently rewritten.

The Runtime Evidence Record

The central object of the framework is the Runtime Evidence Record: a structured and preservable representation of what can be reconstructed about a particular runtime under a declared computational contract.

A complete record may contain:

• source identity and qualification results;

• a canonical event ledger;

• supported temporal and dependency relations;

• actor, role, and interaction mappings;

• source-span bindings;

• runtime frames and worldline coordinates;

• versioned measurements and regime classifications;

• uncertainty, contradiction, and missingness states;

• claims and their supporting evidence;

• computation and software identities;

• preservation and export metadata.

This creates a reversible evidentiary path:

Claim
→ Finding
→ Measurement
→ Runtime Frame
→ Canonical Event
→ Source Evidence

A reviewer should be able to move backward from a conclusion to the record and method that authorized it.

Source-Bound

Every authoritative result must remain traceable to identifiable source material and declared transformations.

Source binding establishes where a result came from. It does not establish that the source is complete, authentic, or true. A cryptographic digest may confirm that the same bytes were processed, but it cannot prove that the original record was accurate or that relevant evidence was not omitted.

Runtime Evidence therefore preserves distinctions among:

• Observed — directly present in the source.

• Operator-declared — supplied as contextual information.

• Computed — produced through a declared method.

• Derived — constructed from other qualified values.

• Classified — assigned through specified criteria.

• Supported interpretation — an interpretation authorized by identified evidence and assumptions.

• Not supplied — absent from the submitted material.

• Not computable — unavailable because required evidence or conditions are missing.

• Forbidden — outside the authority of the record.

Absence is not converted into zero. Missing evidence is not treated as stability, recovery, normality, or proof that an event did not occur.

Deterministic Within a Declared Contract

Runtime Evidence separates the behavior of the original system from the reconstruction performed afterward.

The original model, agent, or workflow may be nondeterministic. The evidentiary transformation should nevertheless be reproducible within its declared scope.

Given the same:

• qualified source;

• canonicalization rules;

• computation contract;

• algorithms and parameters;

• reference assets;

• software version;

• and numerical environment,

the system should produce an equivalent canonical evidence core.

This supports replay, regression testing, comparison, version separation, and independent challenge.

Determinism does not establish validity.

A repeatable parser can still be wrong. A stable measurement can still represent the wrong construct. A source digest can identify a fabricated record. Deterministic reconstruction establishes procedural consistency—not authenticity, causality, scientific truth, or universal meaning.

Claim-Governed

Runtime Evidence treats every conclusion as a claim with a defined authority.

A claim should identify:

• what is being asserted;

• whether it is observed, computed, classified, or interpreted;

• its temporal and operational scope;

• the evidence and method supporting it;

• its assumptions and uncertainty;

• and the limitations that constrain it.

A claim boundary is more than a disclaimer. It is an executable restriction on what the system is permitted to conclude.

If model internals were not supplied, the record cannot authorize claims about hidden state. If source authenticity was not established, the system cannot certify authenticity. If an observable failure anchor is absent, it cannot invent formal lead time. If a measurement is only a proxy, every interface and export must preserve that status.

No claim should exceed the authority of its evidence.

Runtime Evidence makes that commitment computational.

One Evidence Object, Multiple Bounded Projections

Runtime behavior may require many forms of examination: worldlines, regime maps, role topology, temporal analysis, replay, investigative guidance, operational interpretation, and preservation.

These perspectives may differ, but they must not create competing versions of the runtime.

The governing architecture is:

One evidence object. One computational authority. Multiple bounded projections.

Every instrument and interface reads from the same authoritative record. A projection may select, organize, aggregate, visualize, or explain authorized evidence. It cannot silently create new canonical facts, change markers, redefine regimes, or extend the claim boundary.

Agreement between projections establishes architectural consistency. It does not constitute independent scientific corroboration when those projections share the same underlying signals and evidence.

Temporal Honesty

Longitudinal reconstruction requires explicit treatment of time.

Runtime Evidence distinguishes among:

• source timestamps;

• event and turn order;

• ingestion order;

• dependency order;

• symbolic time;

• detection time;

• retrospective boundary onset;

• and independently observed failure time.

These coordinates are not interchangeable.

A pattern recognized after a run may be a valid retrospective finding, but it cannot be presented as a prospective warning unless the system could have produced it using only the evidence available at that point.

This prevents future-information leakage and the backdating of detection. It also protects the distinction between a candidate boundary, a confirmed transition, an observation interval, and formal lead time.

Passport, Replay, and Preservation

The Runtime Evidence Passport identifies the evidence object and records how it was formed. It may contain source digests, evidence identity, contract and software versions, disclosure state, coverage, issuance metadata, and preservation status.

The Passport identifies the record. It does not certify that every source statement or scientific interpretation is true.

Replay reconnects source events, runtime frames, measurements, transitions, and claims. It allows an investigator to stop at a particular point, inspect the evidence then available, and determine how later observations changed the status of a finding.

Preservation ensures that the reconstruction survives beyond the interface that first presented it. The preserved artifact retains the evidence core, provenance, method identities, claim states, limitations, and dependencies required for future inspection and challenge.

Its Place Within the Research

Runtime Evidence is the epistemic layer of the wider research program.

• Recursive Science® investigates how runtime behavior forms, persists, changes, and fails.

• Computational Behavior Architecture defines how that behavior can be represented as events, roles, trajectories, regimes, measurements, and runtime objects.

• Runtime Evidence determines what can be reconstructed and substantiated from the observable record.

• Evidence-Governed Computation™ governs which measurements, interpretations, and claims that evidence may authorize.

• Fieldglass® implements the complete architecture as a working Runtime Evidence Observatory.

• Evidence Commons® extends preservation, portability, comparison, and independent review beyond an individual investigation.

Runtime Evidence therefore connects scientific representation with operational accountability.

Fieldglass as the Reference Implementation

Fieldglass operationalizes Runtime Evidence by transforming guided samples, validation fixtures, and user-supplied operational records into source-bound runtime reconstructions.

Its workflow moves through five principal stages:

1. Acquire — preserve and qualify the source.

2. Structure — construct the canonical runtime.

3. Measure — compute versioned signals, markers, roles, and regimes.

4. Investigate — examine the worldline through bounded instruments and guided questions.

5. Preserve — issue the Passport and export the inspectable evidence artifact.

Fieldglass does not validate every scientific construct merely by implementing it. Its importance is that the architecture becomes executable, inspectable, versionable, and open to falsification.

Independent researchers can test whether measurements correspond to their stated constructs, whether prospective signals survive leakage controls, whether findings generalize beyond reference cases, and whether the resulting evidence provides knowledge that simpler approaches do not.

The Foundational Contribution

The distinctive contribution of Runtime Evidence is the unification of:

• longitudinal behavioral reconstruction;

• temporal measurement;

• regime and role analysis;

• source and transformation provenance;

• deterministic evidence identity;

• shared computational authority;

• executable claim boundaries;

• investigation and replay;

• and durable preservation

within one externally inspectable architecture.

The framework does not claim ownership over logs, provenance, runtime verification, process mining, cryptographic identity, or audit records as individual concepts.

Its contribution lies in bringing these requirements together around the reconstruction of long-horizon computational behavior—and ensuring that the authority and limitations of the evidence travel with every measurement, interpretation, investigation, and export.

Observability makes activity visible. Runtime Evidence makes an account of that activity reconstructable, inspectable, challengeable, and preservable.