🧭 Foundations of Runtime Evidence
Source-Bound Reconstruction, Deterministic Formation, and Governed Claims
Computational systems leave behind logs, traces, transcripts, tool events, workflow histories, alerts, tickets, and incident records. These materials may show what was retained, but they do not automatically provide a coherent or accountable reconstruction of how behavior developed through time.
Runtime Evidence addresses the gap between captured operational records and defensible longitudinal reconstruction.
It follows directly from the preceding foundations:
Longitudinal Computational Dynamics establishes computational behavior across time as a scientific domain.
Longitudinal Computational Behavior identifies the developing runtime trajectory as its primary empirical object.
Chronodynamics defines its temporal coordinates, ordering relations, and marker authority.
Drift Dynamics measures movement relative to declared references.
Computational Behavior Architecture defines the objects and relationships through which the complete runtime can be represented.
Runtime Evidence determines what that reconstruction can legitimately support.
Runtime Evidence is a source-bound, deterministically formed, and claim-governed reconstruction of longitudinal computational behavior.
It is not merely data captured while computation was running. It is an inspectable evidence object in which source identity, transformation history, temporal structure, measurements, findings, missingness, authority, limitations, and preservation state remain connected.
Foundational Framework Page · September 2026 · Version 1.0
From Architectural Representation to Evidentiary Authority
Computational Behavior Architecture answers a structural question:
How can the complete computational runtime be represented as canonical events, roles, frames, dependencies, measurements, worldlines, regimes, and findings?
Runtime Evidence answers the next question:
What authority does that representation possess, what claims can it support, and how can that authority survive inspection, replay, export, and preservation?
The distinction is essential.
A runtime may be represented coherently while its source remains incomplete. A measurement may be reproducible while its scientific interpretation remains unvalidated. A finding may be supported within one run while failing to generalize beyond it. An export may preserve a conclusion while losing the provenance required to challenge it.
Runtime Evidence therefore treats evidence not as a file or score, but as a governed relationship among:
source;
qualification;
canonical reconstruction;
method;
measurement;
finding;
interpretation;
claim;
missingness;
and preservation.
Evidence exists through the preserved relationship among these elements—not through the presence of any one element alone.
Records Are Not Yet Evidence
Operational records are often fragmented, incomplete, differently structured, weakly ordered, and ambiguous about participants, roles, dependencies, or responsibility.
A log entry may identify an event without establishing how it relates to earlier activity. A transcript may preserve language without distinguishing source-observed roles from inferred ones. A trace may capture execution without recording the external condition that motivated it. A dashboard may display a score without retaining the method or source spans from which it was computed.
Runtime Evidence does not treat these records as self-explanatory.
It asks:
What source material was supplied?
Who or what produced it?
How was it preserved and qualified?
Which events, participants, and relationships can be reconstructed?
Which clocks and ordering relations does the record support?
Which values were observed, declared, computed, classified, inferred, or reviewed?
What source spans and methods support each measurement?
Which findings satisfy their declared rules?
Which claims are admissible?
What remains missing, conflicting, unavailable, or outside the claim boundary?
The objective is not to produce the most complete-sounding or persuasive account. It is to construct the strongest account the available evidence can legitimately support.
The governing distinction is:
A record shows that events were captured.
A reconstruction shows how supported events relate through time.
Runtime Evidence establishes what that reconstruction permits the system to claim.
The Formation of Runtime Evidence
Runtime Evidence is formed through a declared and inspectable sequence:
Source record → Qualification → Role-aware canonicalization → Current Evidence Run → Canonical runtime → Versioned measurement → Finding → Admissible claim → Projection → Sealing and preservation
Source Record
The originating operational material is retained and identified. It remains distinguishable from every later transformation.
Qualification
The source is examined for structure, coverage, timestamps, event order, roles, fields, duplication, missingness, conflict, and processing limitations. Qualification determines what is available—not what the investigator wishes were available.
Role-Aware Canonicalization
Qualified material is translated through declared adapters into shared event, participant, role, tool, source-span, and ordering structures. Adapter and transformation provenance remain attached.
Current Evidence Run
The Current Evidence Run becomes the active authority for computation. It identifies the evidence eligible for the investigation and binds the canonical runtime, methods, measurements, markers, instrument models, findings, review state, and export structures to one runtime identity.
Canonical Runtime
The qualified and canonicalized material is constructed as a shared runtime event ledger, spine, playback frames, role topology, dependencies, source mappings, and temporal coordinates. Every later computation reads from this governed representation.
Versioned Measurement
Measurements are computed only through declared contracts. Their eligible inputs, references, coordinate systems, parameters, windows, versions, uncertainty, and availability conditions remain explicit.
Finding
A finding is produced only when its stated evaluation or support conditions are satisfied. A value displayed by an instrument is not automatically a finding.
Admissible Claim
A claim becomes admissible when the available evidence, method, support state, scope, and claim rules authorize it. Admissibility does not make the claim objectively true.
Projection
Instrument panels, worldlines, summaries, guided investigations, reports, and exports present bounded views of the same governed evidence. They do not create new source facts.
Sealing and Preservation
The completed record retains the evidence core, methods, versions, findings, missingness, claim boundaries, integrity information, and replay requirements needed for later examination.
If the source, adapter, parser, threshold, algorithm, reference, or measurement contract changes, the reconstruction becomes a new version. The previous record is not silently rewritten.
The Runtime Evidence Objects
Several related objects must remain distinct.
The Current Evidence Run
The Current Evidence Run is the active governing evidence object for the present computation and investigation.
It determines:
which source and disclosures are in scope;
which canonical runtime is authoritative;
which evidence is available to each computation;
which methods and versions apply;
which measurements and markers are eligible;
which instrument models may be formed;
which findings are supported;
and which claim boundaries govern every surface.
The Current Evidence Run is dynamic during formation. It may move from awaiting source, through qualified and computed states, toward issuance and preservation. Its changes must be recorded rather than concealed.
It governs evidence. It does not own truth.
The Runtime Evidence Record
The Runtime Evidence Record is the structured representation of what can be reconstructed about a particular runtime under a declared computational contract.
It may contain:
source identity and qualification results;
a canonical event ledger;
runtime spine and playback frames;
supported temporal and dependency relations;
participant, role, tool, and interaction mappings;
source-span bindings;
worldline coordinates;
versioned measurements;
regime and marker states;
instrument models and findings;
evidence availability and missingness;
interpretations and claims;
computation and software identities;
and preservation and export metadata.
The Runtime Evidence Passport
The Runtime Evidence Passport identifies the record and exposes its formation, integrity, disclosure, authority, and preservation status.
It may include:
evidence identity;
source and integrity references;
qualification status;
operational-world context;
model, role, and tool disclosures where supplied;
schema, adapter, method, and software versions;
evidence coverage;
claim boundary;
issuance state;
export authority;
and evidence seal.
The Passport identifies and describes the evidence record. It does not certify that every source statement, measurement, or scientific interpretation is true.
The Certified Runtime Evidence Record
The Certified Runtime Evidence Record is the sealed or preserved form produced when the declared formation, integrity, and export requirements have been satisfied.
Certification concerns the formation and integrity of the record under stated conditions. It does not establish source authenticity unless authenticity was independently supported. It does not convert proxies into ground truth, establish hidden causation, or grant legal admissibility by itself.
This distinction prevents an active computational state, an identifying Passport, and a preserved record from being treated as the same object.
A Reversible Evidentiary Path
Runtime Evidence requires more than forward computation. It requires backward inspection.
A reviewer should be able to traverse:
Claim → Finding → Instrument projection → Measurement → Runtime frame → Canonical event → Source record
The reverse path should also remain visible:
Source record → Canonical event → Runtime frame → Measurement → Instrument projection → Finding → Claim
This bidirectional structure serves different purposes.
Forward traversal explains how the record became a claim. Backward traversal allows the claim to be challenged. Together, they expose where interpretation entered, which transformation occurred, what evidence was eligible, and which limitations apply.
If a finding cannot be traced backward to its source and method, it cannot function as a durable Runtime Evidence finding.
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, accurate, unbiased, or true.
A cryptographic digest may demonstrate that the same bytes were processed. It cannot prove that the originating system recorded events correctly, that the record was not fabricated before hashing, or that relevant material was not omitted.
Runtime Evidence therefore retains:
source identity;
source family and format;
supplied coverage;
source-span locations;
acquisition and transformation provenance;
qualification state;
integrity references where available;
missing and excluded material;
operator-supplied context;
and authenticity status.
The record must distinguish source binding from source authentication. A reconstruction may be strongly bound to a supplied source while the authenticity of that source remains unverified.
Evidence State and Missingness
Runtime Evidence preserves the status of information rather than flattening every value into a common certainty.
Evidence stateMeaningSource-observedDirectly present in the qualified operational recordOperator-declaredSupplied by an operator as context or assertionEvaluator-suppliedProvided through an identified evaluation or validation processComputedProduced through a declared deterministic methodDerivedConstructed from other qualified observations or measurementsClassifiedAssigned through declared criteria, thresholds, and persistence rulesSupported interpretationAuthorized by identified evidence and assumptions within a defined scopeReviewedExamined under a declared review process without changing its original evidence classConflictingIn tension with another eligible source or findingNot suppliedAbsent from the submitted materialNot computableUnavailable because required evidence or conditions are missingUnsupportedRequested or proposed but not authorized by the current evidenceForbiddenOutside the permitted claim boundary
Absence is not converted into zero. Missing evidence is not treated as stability, normality, recovery, or proof that an event did not occur.
Unavailable evidence is itself part of the evidentiary state. It must remain visible from computation through interface, export, and preservation.
Deterministic Within a Declared Contract
Runtime Evidence separates the behavior of the original system from the reconstruction performed afterward.
The original model, agent, person, workflow, or environment may behave nondeterministically. The evidentiary transformation should nevertheless be reproducible within its declared scope.
Given the same:
qualified source;
canonicalization rules;
adapter and schema versions;
computation contract;
algorithms and parameters;
references and thresholds;
eligible evidence horizon;
software version;
and numerical environment,
the system should reproduce an equivalent governed evidence core within its stated tolerance.
This supports:
replay;
regression testing;
method comparison;
version separation;
conformance testing;
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. A reproducible classification can rely on poorly calibrated thresholds.
Deterministic reconstruction establishes procedural consistency—not source authenticity, unique causation, scientific truth, legal sufficiency, or universal meaning.
From Observation to Claim
Runtime Evidence separates stages that conventional analytical systems often collapse.
Observation
An eligible property directly present in a qualified source record, or obtained from it through a declared non-interpretive extraction rule.
Measurement
A value produced by applying a defined method to eligible observations within a specified coordinate system, reference, window, and version.
Finding
A supported result established when the required measurement, persistence, comparison, or evaluation conditions have been met.
Interpretation
A bounded account of what one or more findings may mean under stated assumptions and exclusions.
Admissible Claim
A statement the system is permitted to produce, display, preserve, or export under the authority of the Current Evidence Run.
The canonical progression is:
Source → Observation → Measurement → Finding → Interpretation → Admissible claim → Projection → Export and preservation
No stage authorizes itself. A measurement does not establish its own meaning. A finding does not automatically identify a cause. An interpretation does not become a source fact because an operator accepts it. An admissible claim is not necessarily a universally true claim.
Claim-Governed
Runtime Evidence treats every conclusion as a governed computational object.
A claim should identify:
what is being asserted;
its evidence class;
temporal and operational scope;
governing Current Evidence Run;
supporting sources, measurements, and findings;
method and version;
assumptions and uncertainty;
evidence horizon;
missing and conflicting evidence;
review state;
and prohibited extensions.
A claim boundary is more than a disclaimer. It is an executable restriction on what the system is permitted to compute, present, preserve, or export.
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 role provenance is absent, it cannot assign a finding to a participant. If an observable failure marker is unavailable, it cannot invent formal Lead-Time. If a quantity is a proxy, every instrument, explanation, and export must preserve that status.
No claim should exceed the authority of its evidence.
Runtime Evidence makes that principle computationally enforceable. Evidence-Governed Computation™ generalizes it into an architectural discipline.
One Evidence Authority, Multiple Bounded Projections
Runtime behavior may require multiple forms of examination:
worldlines;
temporal maps;
drift trajectories;
regime classifications;
role and interaction topology;
pressure and stability views;
Flight Recorder replay;
guided investigation;
Human Read;
operational summaries;
and preservation artifacts.
These projections may expose different properties, but they must not create competing versions of the runtime.
The governing architecture is:
One Runtime. One Evidence Authority. Multiple Bounded Scientific Projections.
Every instrument and interface reads from the same Current Evidence Run. A projection may select, aggregate, organize, visualize, or explain authorized evidence. It cannot silently create canonical facts, change event identity, relocate a marker, redefine a regime, alter missingness, or extend the claim boundary.
Agreement among projections establishes architectural consistency. It does not constitute independent scientific corroboration when those projections share the same underlying source, signals, or methods.
Temporal Honesty
Longitudinal reconstruction requires explicit treatment of time.
Runtime Evidence distinguishes among:
source time;
normalized clock time;
turn order;
event order;
ingestion order;
dependency order;
symbolic time;
detection time;
retrospective reconstruction;
candidate boundary formation;
confirmed boundary crossing;
independently observed failure;
and sustained recovery.
These coordinates and states 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 requirement is prefix invariance. Appending later events must not silently change a value previously represented as an online measurement.
Temporal honesty also preserves marker authority:
t_aw identifies a supported weakening or awareness point;
t_candidate identifies a provisional boundary condition;
t* identifies a qualifying observable boundary crossing;
tf identifies an independently supplied or qualified observable failure;
and recovery requires sustained re-entry or reorganization.
A candidate boundary is not a confirmed crossing. A crossing is not automatically a failure. Formal Lead-Time exists only when both t* and tf are available and qualified. Without both, the record may support a warning window, candidate interval, or post-exit observation period—not formal Lead-Time.
Challenge, Reproduction, and Revision
Runtime Evidence is designed to remain open to challenge.
A reviewer should be able to ask:
Was the source sufficient for the finding?
Was event order established or assumed?
Did role mapping preserve uncertainty?
Was the measurement computed from eligible evidence?
Was the reference condition explicit?
Did the finding satisfy persistence requirements?
Did future information leak into an earlier signal?
Did the interface overstate a proxy?
Did the export preserve the original claim boundary?
Would another implementation reproduce the result under the same contract?
Challenge may reveal a source omission, parser defect, unstable threshold, invalid construct, unsupported interpretation, or stronger alternative explanation.
Revision must therefore be versioned. A corrected record does not erase the prior version. It identifies what changed, why it changed, which findings were affected, and whether the new result is comparable with the old one.
Reproducibility means that the declared process can be repeated. It does not require independent reviewers to accept the interpretation.
Passport, Ledger, Replay, and Preservation
Runtime Evidence must survive beyond the interface and session in which it was formed.
The Runtime Evidence Passport identifies the evidence object and exposes its formation, integrity, disclosure, coverage, claim boundary, export authority, and preservation status.
The Runtime Evidence Ledger records material evidence-state transitions, including acquisition, qualification, computation, marker formation, review, issuance, sealing, export, and revision where applicable.
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 distinguish what could have been known at that moment from what became visible later.
Preservation retains the evidence core, provenance, method identities, versions, claim states, limitations, and dependencies required for future inspection.
Presentation may adapt to runtime scale. Large records may require progressive replay, sampling, or summary-first visualization. The underlying evidence cannot be silently truncated merely to satisfy an interface constraint.
Evidence Commons extends this preservation logic beyond an individual instrument or investigation by providing a framework for controlled exchange, comparison, independent examination, and long-term governance of Runtime Evidence artifacts.
Its Place Within the Research
Runtime Evidence is the epistemic layer of the wider SubstrateX research and engineering program.
Longitudinal Computational Dynamics establishes the scientific domain.
Longitudinal Computational Behavior is the primary empirical object.
Chronodynamics defines temporal structure and marker authority.
Drift Dynamics characterizes reference-relative runtime motion.
Computational Behavior Architecture defines the representational and computational system.
Runtime Evidence determines what can be reconstructed and substantiated from the available record.
Evidence-Governed Computation™ governs which measurements, findings, projections, and claims the evidence may authorize.
SubstrateX Aperture™ implements the complete architecture as a Runtime Evidence Observatory.
Evidence Commons extends preservation, portability, comparison, and independent scrutiny beyond an individual investigation.
Runtime Evidence therefore connects scientific representation with operational accountability.
SubstrateX Aperture™ as the Reference Implementation
SubstrateX Aperture operationalizes Runtime Evidence by transforming guided samples, validation fixtures, and user-supplied operational records into source-bound runtime reconstructions.
Its public workflow can be understood through seven stages:
Acquire — identify and preserve the source.
Qualify — determine coverage, structure, roles, ordering, and limitations.
Structure — construct the canonical runtime, event ledger, spine, frames, and mappings.
Govern — establish the Current Evidence Run and bind computation to its authority.
Measure — compute versioned signals, markers, regimes, and instrument models.
Investigate — examine the worldline through the Runtime Blackbox, Flight Recorder, bounded instruments, and Guided Investigation.
Preserve — issue the Passport, record evidence status, and export the sealed evidence artifact when requirements are met.
Operational Worlds and Morphic UX adapt guidance, language, emphasis, and presentation without mutating the evidence. The same qualified source, computation contract, configuration, and version produce the same governed evidence core within declared tolerance.
SubstrateX Aperture does not validate every scientific construct merely by implementing it. Its importance is that the framework 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 Runtime Evidence provides discriminating knowledge beyond simpler logging, tracing, or evaluation methods.
Claim Boundaries
Runtime Evidence can establish what a qualified record and declared method support. It does not automatically:
authenticate the originating record;
prove that the source is complete;
reveal hidden model state or private reasoning;
establish intent, consciousness, identity, or subjective experience;
infer unique causation from chronology;
assign legal responsibility or blame;
convert a proxy into ground truth;
validate a measurement because it is deterministic;
establish prospective prediction from retrospective reconstruction;
generalize findings beyond the tested domain;
or confer legal admissibility on an artifact.
These boundaries do not weaken the framework. They define the conditions under which its claims remain defensible.
The Foundational Contribution
The distinctive contribution of Runtime Evidence is the unification of:
source qualification;
longitudinal behavioral reconstruction;
temporal and dependency structure;
drift, regime, role, and stability analysis;
source and transformation provenance;
deterministic evidence identity;
typed evidence status and preserved missingness;
shared computational authority;
executable claim boundaries;
bounded instrument projections;
investigation and replay;
versioned challenge and revision;
and durable preservation
within one externally inspectable evidentiary architecture.
The framework does not claim ownership over logs, provenance, runtime verification, process mining, cryptographic identity, chain of custody, 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.
Computational Behavior Architecture makes the runtime representable.
Runtime Evidence makes its reconstruction inspectable, challengeable, and preservable.
Evidence-Governed Computation™ ensures that no claim exceeds the authority of its evidence.