Evidence Formation and Flight-Recorder Control for Runtime Reconstruction

When a complex computational process fails, its final output rarely explains how the failure formed. Logs may contain alerts, retries, tool calls, messages, handoffs, corrections, deployments, and errors. Those records preserve individual events, but they do not automatically establish the longitudinal trajectory connecting them: what changed, what persisted, where pressure accumulated, when a boundary became observable, whether an apparent recovery held, or which claims the available record can support.

The SubstrateX Aperture™ Runtime Blackbox provides the controlled computational environment through which that trajectory is formed as Runtime Evidence.

The SubstrateX Aperture™ Runtime Blackbox is the browser-local evidence-formation and run-state console through which a qualified canonical runtime is loaded, authorized computation and reconstruction are initiated, the Current Evidence Run is assembled, evidence-authority and issuance state are exposed, and the resulting record is handed to replay, investigation, and preservation—without allowing the interface to become the source, the evidence authority, or an independent scientific instrument.

Its governing principle is:

Compute one runtime. Bind one evidence authority. Expose every transition.

Why a Computational Blackbox Is Necessary

Aircraft investigators do not rely only on the final condition of an aircraft or on a retrospective explanation of what occurred. They recover an ordered record through which the development of an incident can be reconstructed and challenged.

Long-horizon computational systems require a comparable capability.

An agentic or operational runtime may extend across hundreds of interactions involving models, people, tools, services, workflows, and infrastructure. A visible failure may appear at the end of that process even though relevant weakening, drift, recurrence, handoff disruption, or boundary pressure developed much earlier.

Conventional logs preserve fragments. They rarely provide one governed object that connects:

• the supplied source;

• its canonical representation;

• ordered events and runtime frames;

• computed measurements;

• temporal and boundary markers;

• regimes and transitions;

• bounded Instrument Findings;

• interpretation and Human Read;

• source-linked investigation;

• run identity and claim boundaries; and

• a preservable evidence artifact.

The Runtime Blackbox coordinates the formation and lifecycle of that object.

It does not recover hidden model state, private reasoning, or an inaccessible internal mechanism. It operates within the observable-runtime-behavior boundary established by the source and declared methods.

The Blackbox Is Not the Entire Observatory

The blackbox metaphor becomes misleading if every Aperture responsibility is collapsed into it.

The relevant components are connected but distinct:

ComponentResponsibilityAuthority limitIngestion EngineBinds and qualifies the source, applies a versioned adapter, and constructs the canonical runtime input.Does not create telemetry, markers, regimes, or findings.Runtime BlackboxControls and exposes the compute lifecycle through which the active evidence run is formed.Does not become source evidence, an instrument, or an independent evidence authority.Current Evidence RunHolds the active computational authority and run-wide evidence state.Is active and mutable only through authorized computation.Flight RecorderAligns runtime events, frames, roles, markers, and source references for navigation and replay.Does not create another runtime or alter recorded findings.Runtime ReconstructionProvides the evidence-bound investigative environment through which the trajectory is examined.Cannot strengthen the evidence it presents.Runtime Evidence AuthorityDetermines whether computed material satisfies identity, legitimacy, conformance, sufficiency, disclosure, and claim-lineage requirements.Does not make unsupported findings true.Runtime Evidence PassportCarries persistent evidence identity, formation, integrity, certification scope, and claim boundaries.Is not the evidence computation or a truth certificate.Preservation architecturePackages the issued record, Passport, manifests, lineage, and replay information.Cannot expand the authority of the preserved record.

The Runtime Blackbox makes these transitions visible and coordinated. It does not absorb their separate responsibilities.

What Enters the Blackbox

The Runtime Blackbox begins after controlled ingestion has produced a qualified canonical runtime.

Its input may include or reference:

• raw source identity and binding;

• canonical identity;

• the applied adapter and canonicalization versions;

• ordered canonical units;

• roles, events, and source-span mappings;

• supplied temporal coordinates;

• ingestion warnings and missingness;

• operator-declared context identified as such;

• applicable compute configuration; and

• release, registry, schema, and method versions.

The Blackbox does not silently reacquire, reinterpret, or replace the source. If an evidence-bearing ingestion decision changes—such as the applied adapter, role mapping, event mapping, or canonical ordering—the canonical runtime must be recomputed before a new run can be formed.

Selected Operational World, cockpit profile, sample title, validation expectation, and interface state cannot become computational source material merely because they are visible when compute begins.

The Evidence-Formation Lifecycle

The Blackbox exposes a controlled lifecycle from unformed source context to an issued evidence record.

The governing sequence is:

Qualified canonical runtime
↓
Blackbox load and identity binding
↓
Runtime reconstruction and authorized computation
↓
Current Evidence Run
↓
Evidence formation and claim-boundary assembly
↓
Runtime Evidence Authority conformance and certification boundary
↓
Certified Runtime Evidence Record, Passport, Ledger, and Evidence Seal
↓
Flight Recorder, Guided Investigation, export, and preservation

The lifecycle is represented through three principal Blackbox states.

Awaiting

No qualified canonical runtime has entered an active compute cycle.

The source may be absent, unresolved, still in preflight, or awaiting operator action. No Passport is issued. No interface panel may treat sample content, empty state, or earlier run data as the active evidence authority.

Loaded

A qualified canonical runtime has been bound to the active compute cycle.

Computation or reconstruction may be underway, or the active Current Evidence Run may be awaiting evidence-authority checks. Runtime objects can begin to populate under declared methods, but issuance has not yet occurred.

Loaded does not mean certified.

Issued

The required evidence-formation, identity, integrity, disclosure, conformance, and claim-boundary conditions have been satisfied for the declared certification scope.

The Runtime Evidence Record has crossed the declared certification boundary and can be represented as a Certified Runtime Evidence Record. The Runtime Evidence Passport is issued, the Runtime Evidence Ledger is bound, and the Evidence Seal identifies the governed evidentiary core. The certified record can proceed through authorized investigation, export, and preservation.

Issued does not mean true, safe, scientifically validated, or independently replicated.

Failed, cancelled, interrupted, or non-conformant formation does not silently fall back to Issued. It results in non-issuance or an explicitly qualified state with the applicable reason preserved.

The state indicator reports the lifecycle. It does not create the lifecycle event it displays.

Forming the Current Evidence Run

The Current Evidence Run is the active computational authority formed around the qualified canonical runtime.

Depending on the available evidence and active release, it may bind:

• source and canonical identities;

• canonical runtime structures;

• runtime event ledger;

• canonical runtime spine;

• playback frames;

• registered telemetry and metrics;

• temporal coordinates and markers;

• regime history;

• Signal Authority and metric-legitimacy state;

• Runtime Stability Foundation;

• bounded Instrument Findings;

• REIM posture and routing;

• evaluation and synthesis objects;

• deterministic Human Read;

• provenance and disclosure state;

• claim boundaries;

• Passport formation state; and

• preservation readiness.

Not every object becomes available at the same moment. The Blackbox coordinates their formation under one run identity and exposes when dependencies remain missing, partial, or non-conformant.

The Current Evidence Run is not a loose collection of interface values. It is the shared active authority from which evidence-bearing surfaces must read.

The related record objects remain distinct:

Current Evidence Run
Governs active computation and investigation.

Runtime Evidence Record
Preserves the qualified machine-readable evidence assembled from that run.

Certified Runtime Evidence Record
Represents the issued record after declared identity, integrity, conformance, disclosure, lineage, and claim-boundary checks.

Completion of computation does not, by itself, cross the certification boundary.

No page, chart, instrument, operational lens, or summary may construct a competing account of the run.

The run is formed once. Its authorized projections are many.

From Events to a Runtime Trajectory

A collection of events is not yet a reconstruction.

Aperture organizes qualified canonical units into ordered runtime structures that preserve relationships among:

• source and canonical coordinates;

• runtime events;

• roles and interactions;

• source spans;

• tool activity;

• behavioral measurements;

• regimes and transitions;

• temporal and boundary markers;

• worldline positions; and

• replay state.

The canonical runtime spine provides the ordered structure. The runtime event ledger records operational events associated with that structure. Playback frames provide inspectable positions through the reconstructed chronology. The worldline represents the evidence-supported trajectory derived from the spine.

A frame may connect:

• its canonical and source coordinates;

• events active at that position;

• participating roles;

• available measurements;

• applicable regime;

• candidate or confirmed markers;

• eligible Instrument Findings;

• evidence availability; and

• supporting source spans.

The worldline is not a directly observed hidden path inside a model. It is a computational representation of longitudinal relationships supported by the observable record.

This is the point at which fragmented operational history becomes an inspectable runtime specimen.

The Flight Recorder

The Runtime Blackbox governs evidence formation. The Flight Recorder makes the resulting chronology navigable.

Through the Flight Recorder, an investigator can move across the reconstructed runtime and inspect how observable conditions changed from one frame to another. Events, marker tracks, roles, regimes, transitions, measurements, Instrument Findings, and frame-local source evidence remain aligned to shared runtime coordinates.

Replay does not generate a new version of the run.

It returns to an existing position in the recorded reconstruction and presents the evidence associated with that position. A recomputation is a separate lifecycle event governed by its own canonical input, configuration, versions, and run identity.

The operator can move through a reversible evidence path:

Human Read or chapter statement
↓
REIM posture or synthesis field
↓
Instrument Finding
↓
Measurement and marker
↓
Runtime frame and recorder event
↓
Canonical event
↓
Source span

This reversibility prevents the replay surface from becoming an independent explanatory authority.

Temporal and Marker Integrity

The Blackbox and Flight Recorder preserve distinctions among coordinate systems and marker classes.

Aperture may distinguish:

• source-turn order;

• canonical-turn order;

• frame order;

• event order;

• dependency order;

• wall-clock time when supplied; and

• symbolic-time progression.

It also distinguishes among:

• first observable weakening;

• candidate boundary formation;

• confirmed Basin Exit;

• observable failure;

• recovery;

• re-entry;

• warning windows; and

• post-exit observation intervals.

These are not interchangeable labels for a dramatic point on a chart.

Formal lead time is admissible only when an eligible qualifying boundary marker and an independently available observable failure marker are both present, properly ordered, and governed by a declared temporal method. If the failure marker is absent, Aperture may report an open warning window or post-exit observation interval. It must not convert that interval into formal lead time.

Replay also preserves the evidence horizon under which a finding was available. A retrospectively visible pattern cannot be represented as a prospective warning unless it was computable from the evidence available at the claimed point.

One Runtime, Nine Scientific Views

The Runtime Blackbox and Flight Recorder are not additional scientific instruments.

Aperture’s nine instruments project bounded measurements onto the same Current Evidence Run:

• Seismo examines worldline development, disturbance, boundary formation, transition, and recovery posture.

• Chronos examines temporal organization, recurrence, compression, shear, and symbolic-time relationships.

• Drift examines displacement from registered anchors, curvature, continued departure, and re-alignment.

• Pressure examines runtime strain, accumulated load, boundary pressure, and recovery reserve.

• Bridge examines recorded roles, authority movement, handoffs, tool interactions, and coordination continuity.

• Noesis examines observable formation, recurrence, modulation, continuity, and re-anchoring.

• Scope examines runtime topology, containment relationships, boundary geometry, and possible recovery corridors.

• Dynamics examines cross-signal movement and relationships among registered runtime dimensions.

• Interferometer examines alignment, divergence, reinforcement, and interference among registered streams or recurring structures.

Each instrument reads eligible evidence through its versioned contract and may write only its own bounded Instrument Finding.

The Blackbox coordinates those findings with the run. The Flight Recorder positions them within the chronology. Neither grants an instrument permission to create source facts, change canonical telemetry, move authoritative markers, or enlarge the claim boundary.

One recorded runtime. One governing evidence authority. Nine bounded scientific projections.

From Replay to Guided Investigation

A complete runtime record can expose more information than an operator knows how to examine.

Guided Investigation organizes that complexity into six canonical chapters:

• Evidence Formation;

• Worldline Formation;

• Runtime Formation;

• Failure Formation;

• Runtime Replay; and

• Operational Interpretation.

Each chapter asks bounded questions and routes the operator toward eligible findings, frames, markers, events, source spans, and claim limits.

REIM may identify the best-supported interpretation posture and recommend where inspection should begin. The Evaluation and Synthesis Layer may assemble authorized findings into a structured evidence bundle. Human Read may translate that bundle into deterministic operator-facing language.

None of those layers may create source events, recompute telemetry through narrative, convert a candidate marker into a confirmed marker, or close the investigation by assertion.

The operator retains judgment and can return from every material statement to the evidence that authorizes it.

Operational Context Without Computational Contamination

Operational World Mapping preserves domain meaning around the evidence lifecycle.

Four concepts remain distinct:

• Detected source family describes what the supplied record structurally resembles.

• Applied adapter describes how the record was canonicalized.

• Selected Operational World describes how the operator intends to investigate the run.

• Operational World Lens describes how authorized findings are contextualized after computation.

The selected world may change terminology, explanatory emphasis, question order, recommended instruments, and investigative navigation. It cannot change the source, canonical runtime, telemetry, markers, Instrument Findings, Runtime Evidence Interpretation Matrix (REIM) posture, run identity, Passport, Evidence Seal, or preservation authority. The Adaptive Evidence Cockpit may similarly change interface density, visible priorities, starting chapter, Operator Mode, or Shift Mode. Its session preferences remain outside the evidence-bearing computation.

The interface adapts. The recorded runtime does not.

Identity, Authority, and Issuance

A blackbox record is useful only if its identities remain coherent across the lifecycle.

Aperture distinguishes:

Source identity
The supplied record before canonical transformation.

Canonical identity
The normalized runtime input under declared ingestion versions and options.

Run identity
The active evidence computation under governing method and configuration versions.

Record identity
The issued Runtime Evidence Record assembled from the run.

Passport identity
The persistent authority envelope associated with that record.

Artifact identity
A particular export or preservation package.

Runtime Evidence Authority evaluates whether computed material satisfies the declared requirements for:

• identity alignment;

• provenance;

• evidence coverage and claim-specific sufficiency;

• Signal Authority and metric legitimacy;

• temporal and marker authority;

• instrument-contract conformance;

• disclosure and missingness;

• claim lineage;

• certification scope;

• explicit non-certifications;

• evidence sealing;

• export authority; and

• preservation readiness.

The Blackbox displays and coordinates this transition. It does not replace Runtime Evidence Authority.

Runtime Evidence Passport and Evidence Ledger

When the applicable issuance conditions are satisfied, the Runtime Evidence Passport identifies the resulting evidence record and carries its authority beyond the active compute state.

The Passport may carry or reference:

• source, canonical, run, record, and artifact identities;

• computation, registry, schema, and method versions;

• formation and integrity posture;

• source coverage and evidence sufficiency;

• disclosure and missingness state;

• certification scope;

• explicit non-certifications;

• claim boundaries;

• Evidence Seal;

• export authority; and

• preservation readiness.

The Runtime Evidence Ledger preserves the evidence-bearing lineage associated with formation and issuance. Passport and ledger identity must remain aligned with the Runtime Evidence Record.

Variable envelope information—such as issuance timestamps, operator-declared context, or review notes—must remain distinguishable from the deterministic evidentiary core.

Passport issuance does not certify objective truth, scientific validity, causation, intent, safety, compliance, or independent replication. It establishes the identity and declared authority of the evidence object.

Failure, Refusal, and Non-Issuance

The Runtime Blackbox must be able to stop.

Non-issuance conditions may include:

• unresolved source or canonical identity;

• failed ingestion or canonicalization;

• missing required runtime structures;

• compute interruption or cancellation;

• invalid coordinate relationships;

• conformance failure;

• unavailable required measurement dependencies;

• Passport and record identity mismatch;

• missing claim-boundary state;

• integrity failure;

• unsupported evidence volume; or

• preservation requirements that cannot be satisfied.

A partial Current Evidence Run may remain available for bounded diagnostic inspection when the implementation permits it. It must not be represented as an issued Runtime Evidence Record if the issuance requirements were not met.

The interface must not substitute a prior issued run, sample Passport, or cached conclusion for a failed active computation.

Non-issuance is an evidence state. It is not an interface inconvenience to conceal.

Preservation and Evidence Commons Handoff

The Runtime Blackbox does not conclude with a visualization.

When export and preservation requirements are satisfied, Aperture can package the available evidence-bearing objects into a preservation artifact containing or referencing:

• source and canonical identities;

• canonical runtime structures;

• event ledger, runtime spine, and playback frames;

• telemetry, markers, and regime history;

• Signal Authority and metric-legitimacy state;

• Instrument Findings;

• REIM, synthesis, and Human Read objects;

• Certified Runtime Evidence Record;

• Runtime Evidence Passport;

• Runtime Evidence Ledger;

• Evidence Seal;

• provenance and disclosure state;

• missingness and claim boundaries;

• replay information;

• version manifests; and

• artifact integrity references.

Preservation extends authority continuity beyond the active interface. It does not make every included interpretation correct.

Evidence Commons can receive the preservation-ready artifact as a portable evidence object rather than a screenshot or detached narrative. The handoff must retain record identity, lineage, applicable manifests, replay posture, and claim boundaries.

The evidentiary loop becomes:

Source
↓
Canonical runtime
↓
Current Evidence Run
↓
Certified Runtime Evidence Record and Passport
↓
Reconstruction and Guided Investigation
↓
Preservation artifact and Evidence Commons handoff

Determinism, Replay, and Validation

Determinism means that the same eligible canonical input, governing versions, configuration, and computational conditions should reproduce the same governed core outputs within declared tolerances.

Replay means that an operator can revisit the ordered evidence already bound to the run.

Reconstruction means that observable longitudinal relationships are organized into an inspectable runtime representation.

These properties are related, but they are not interchangeable.

None independently establishes scientific validity.

Validation still requires stable and negative controls, anti-contamination tests, temporal-leakage evaluation, perturbation tests, role-topology ablation, instrument-dependency analysis, threshold calibration, external datasets, prospective studies, falsification attempts, and independent replication.

The Validation Harness may exercise known scenarios through the same evidence engine, but fixture identity and expected outcomes must remain outside Blackbox computation until a separate comparison stage.

The Blackbox makes evidence formation reproducible and inspectable. Validation determines which constructs and claims survive testing.

What the Runtime Blackbox Does Not Claim

The Runtime Blackbox does not independently:

• recover hidden model state, weights, activations, or private reasoning;

• determine consciousness, cognition, agency, selfhood, or intent;

• establish objective truth;

• determine root cause or unique causation;

• assign human or organizational blame;

• convert every anomaly into failure;

• treat every computed score as a calibrated probability;

• infer missing source events;

• create a failure marker that was not supplied or legitimately computed;

• convert retrospective evidence into prospective prediction;

• certify universal safety, alignment, compliance, or deployment readiness;

• intervene in the runtime merely because Shift Mode is active;

• validate its own scientific constructs by executing them; or

• reconstruct evidence that was never supplied.

A partial source can support only a partial reconstruction. Missing events, absent failure anchors, uncertain roles, invalid ordering, and unavailable dependencies remain limits on what the issued or unissued run can responsibly establish.

The Architectural Contribution

Compute consoles, event logs, replay tools, dashboards, provenance records, and export manifests are not individually new.

The Aperture contribution is their integration within a single evidence-governed runtime lifecycle in which:

• ingestion remains distinct from computation;

• the Blackbox exposes formation without becoming evidence authority;

• the Current Evidence Run governs every active evidence-bearing surface;

• the Flight Recorder replays one chronology rather than generating another;

• reconstruction remains source-bound;

• temporal markers preserve coordinate and evidence-horizon authority;

• nine instruments project from the same run;

• interpretation remains subordinate to measurement;

• Operational Worlds and cockpit profiles cannot modify computation;

• Passport issuance follows declared authority checks;

• failure and non-issuance remain visible;

• preservation retains identity, lineage, and claim boundaries; and

• every material finding can remain traceable from conclusion to source.

The Runtime Blackbox and Flight Recorder are therefore more than interface metaphors.

Together, they make the formation and longitudinal reconstruction of Runtime Evidence operational, inspectable, replayable, and preservable.

The Governing Definition

The SubstrateX Aperture™ Runtime Blackbox is the browser-local evidence-formation and run-state architecture that binds a qualified canonical runtime to one Current Evidence Run, coordinates authorized reconstruction and measurement, exposes conformance and issuance state, and hands the resulting certified evidence record to replay, investigation, and preservation without allowing interface state, interpretation, or presentation to become evidence authority.

Aperture does not ask the operator to trust an explanation of what happened. It preserves a reversible path from finding to frame, from frame to event, and from event back to source.