From Operational Records to Inspectable Runtime Evidence

Fieldglass® is not simply a dashboard placed over logs. Its code implements a browser-local computational architecture for transforming operational records into source-bound, role-aware, temporally ordered Runtime Evidence.

It accepts transcripts, logs, traces, incidents, workflow records, and structured event data. It qualifies the source, reconstructs the runtime, computes behavioral measurements, establishes an evidence authority, and exposes the resulting record through instruments, replay, guided investigation, Passports, and preservation artifacts.

The complete path is:

Source Record → Qualification → Canonical Runtime → Current Evidence Run → Certified Runtime Evidence Record → Runtime Stability Foundation → Instrument Projections → Investigation → Passport → Preservation

Every stage remains connected to the same source and evidence identity.

That continuity is the central engineering principle of Fieldglass.

It Establishes the Source Before Analysis Begins

Fieldglass begins by identifying exactly what evidence has entered the system.

The source architecture supports:

• transcripts;

• JSON and JSONL records;

• operational logs;

• incident records;

• role-aware workflows;

• guided samples;

• and registered validation cases.

The code preserves the raw source, identifies the active adapter, records qualification warnings, verifies source identity where hashes are available, and separates source content from descriptive fixture metadata.

A bounded preview may be shown in the interface, but the computational source is not reduced to satisfy display constraints.

The interface may summarize the source. The evidence computation remains bound to the complete qualified record.

If a required source cannot be resolved, Fieldglass exposes the failure. It does not silently replace the missing evidence with sample content or inferred data.

It Preserves Roles as Evidence-Bearing Structure

Fieldglass does not flatten every participant into an undifferentiated sequence of messages.

Its role-aware canonicalization architecture preserves:

• the original source label;

• the normalized operational role;

• aliases and mappings;

• mapping confidence;

• mapping provenance;

• unresolved roles;

• role changes;

• tool participation;

• and interaction boundaries.

These roles become part of the reconstructed runtime.

The system can then examine:

• role continuity;

• role displacement;

• fragmentation;

• cross-role drift;

• phase lag;

• handoff coherence;

• authority conflict;

• tool-loop pressure;

• and coordination degradation.

This makes interaction topology a computational property of the runtime—not a label attached after analysis.

Role telemetry remains bounded by the source. It may describe observable patterns of coordination or fragmentation, but it cannot establish intent, blame, legal responsibility, organizational truth, or hidden mental state.

It Constructs a Canonical Runtime

Operational records usually arrive as fragments:

• turns;

• timestamps;

• messages;

• alerts;

• tool calls;

• retries;

• failures;

• handoffs;

• and corrections.

Fieldglass transforms those fragments into a canonical runtime representation.

The canonical runtime spine connects:

• frame position;

• canonical and source turns;

• event references;

• source spans;

• role information;

• behavioral signals;

• temporal operators;

• regimes;

• markers;

• stability;

• drift;

• pressure;

• continuity;

• boundary proximity;

• recovery evidence;

• and replay coordinates.

The resulting worldline is not merely a plotted curve. It is a normalized and replayable runtime object through which the source, measurements, events, roles, transitions, and visual representation remain connected.

This is the central specimen of the observatory.

The runtime is reconstructed once. Every instrument examines a bounded projection of that same runtime.

It Maintains a Unified Temporal Authority

Runtime behavior does not unfold through one clock alone.

Fieldglass distinguishes among:

• frame order;

• canonical-turn order;

• source-turn order;

• event order;

• dependency order;

• wall-clock time;

• and symbolic-time progression.

The temporal authority also separates important runtime markers:

• first observable weakening;

• candidate boundary formation;

• confirmed Basin Exit;

• observable failure;

• recovery;

• and re-entry.

These distinctions prevent different surfaces from assigning conflicting meanings to the same moment.

The code detects coordinate disagreements and invalid event sequences. It refuses to calculate formal Lead-Time when the required markers are absent, incompatible, or improperly ordered.

A retrospective pattern cannot therefore be presented automatically as a prospective warning.

Formal Lead-Time requires both an admissible detection marker and an independently qualified failure anchor. Without both, the interval remains unresolved or observational.

It Creates One Active Evidence Authority

Once the essential runtime computation is complete, Fieldglass forms a Current Evidence Run.

The Current Evidence Run is the active, run-wide computational authority. It brings together the qualified source, canonical runtime, measurements, markers, regimes, roles, instrument models, investigation state, and export dependencies.

When the required evidence contract is satisfied, the governed payload can be sealed as a Certified Runtime Evidence Record.

This distinction matters:

• The Current Evidence Run governs the active investigation.

• The Certified Runtime Evidence Record is the sealed evidence payload.

• The Runtime Evidence Passport identifies and discloses the resulting run.

• The preservation artifact carries that identity and lineage beyond the interface.

Fieldglass therefore does not allow each page, chart, or instrument to construct its own version of the run.

There is one evidence authority.

It Establishes a Shared Stability Substrate

Before individual instruments examine the runtime, the code organizes the Certified Runtime Evidence Record through the Runtime Stability Foundation.

This shared measurement layer provides a common representation of:

• coherence support;

• contraction state;

• phase-lock confidence;

• attractor projections;

• Basin structure;

• return curvature;

• boundary pressure;

• weakening;

• candidate formation;

• confirmed exit;

• observable failure;

• recovery;

• and re-entry evidence.

The Runtime Stability Foundation does not create telemetry or modify the evidence record. It organizes existing source-bound and computed evidence into a common stability substrate from which the instruments can operate.

Its quantities are output-derived measurements and proxies. They are not direct observations of hidden model state, and they must not be described as calibrated probabilities unless separate validation establishes that interpretation.

It Gives Measurements Different Levels of Authority

Not every value in Fieldglass has the same evidentiary status.

The Signal Authority distinguishes among:

• direct observations;

• derived measurements;

• output-based proxies;

• interpretive projections;

• and experimental constructs.

Each registered signal carries information about:

• its source and dependencies;

• its computation method;

• its temporal scope;

• its authority class;

• its missingness state;

• its allowed interpretation;

• and its prohibited claims.

This prevents a composite score, interpretive label, or visualization from silently presenting itself as a direct observation.

It also allows Fieldglass to represent absence honestly:

• unavailable dependency;

• insufficient evidence;

• not observed;

• not computed;

• outside scope;

• or experimental.

A missing value does not become zero. An unavailable signal does not become evidence of stability.

It Constrains Nine Instruments to the Same Evidence

Fieldglass includes nine registered instruments:

• Seismo examines runtime trajectory, disturbance, boundary formation, and recovery posture.

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

• Drift examines displacement, deviation, curvature, and attractor movement.

• Pressure examines accumulating runtime strain, boundary load, and recovery conditions.

• Bridge examines role, handoff, tool, and operational coordination.

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

• Scope examines runtime coverage, topology, containment, and available evidence.

• Dynamics exposes broader multivariate runtime relationships under declared profiles.

• Interferometer compares coupled streams, roles, signals, or trajectories.

Each instrument has a contract defining:

• what it may read;

• which signals it depends upon;

• what findings it may produce;

• its authority level;

• its evidence basis;

• and what it is prohibited from claiming.

Instrument findings remain attached to the run, Passport, signal references, source spans, confidence posture, and claim boundary.

The instruments do not create nine competing realities.

They provide nine bounded views of one certified runtime.

It Routes Interpretation Without Turning It Into Truth

The Runtime Evidence Interpretation Matrix, or REIM, connects computed evidence to structured investigation.

REIM constructs an evidence-derived feature profile, evaluates registered interpretation classes, identifies primary and secondary possibilities, records rejected alternatives, and directs the operator toward relevant evidence chapters.

It also applies contradiction guards and prevents sample names, expected labels, or operational-world framing from becoming classification authority.

REIM is currently a versioned heuristic interpretation layer. It may support investigative routing and bounded operational interpretation, but it is not ground truth, a causal engine, or a universally validated diagnostic classifier.

Its conclusions remain subordinate to the Certified Runtime Evidence Record.

It Produces a Runtime Evidence Passport

Every completed evidence run can issue a Runtime Evidence Passport containing:

• run identity;

• source identity;

• canonical and artifact hashes;

• qualification status;

• operational context;

• model and research disclosures;

• runtime-formation summary;

• integrity and coverage;

• computation versions;

• claim boundaries;

• certification scope;

• preservation status;

• and explicit exclusions.

The deterministic evidence core can remain stable even when the complete Passport envelope contains variable issuance timestamps or operator-declared context. Fieldglass keeps those layers distinguishable.

The Passport may certify that a source was acquired, computed, reconstructed, and bound to a replayable evidence chain under a declared release.

It does not certify:

• truth;

• correctness;

• causation;

• intent;

• consciousness;

• hidden state;

• blame;

• safety;

• or deployment approval.

The Passport identifies the evidence. It does not exceed it.

It Preserves the Complete Evidence Lineage

Fieldglass does not end with a dashboard conclusion.

Its preservation architecture carries the source-to-result chain into an EvidenceCommons® artifact containing the available:

• canonical evidence record;

• runtime spine;

• worldline and frames;

• temporal and role appendices;

• signal records;

• markers and regimes;

• instrument findings;

• REIM interpretation;

• technical and operator-facing reports;

• validation state;

• Passport identity;

• claim boundaries;

• preservation manifest;

• and integrity hashes.

Operational Worlds may change guidance, terminology, examples, investigative emphasis, and brief wording. They do not rewrite the underlying telemetry or evidence identity.

The same Certified Runtime Evidence Record can therefore be examined through different operational lenses without becoming a different runtime.

It Runs Locally and Preserves Evidence Before Presentation

The public implementation operates inside the browser.

Source records do not require mandatory upload to a remote service. Computation, reconstruction, investigation, and export can remain local to the operator’s session.

For larger records, Fieldglass may adapt rendering density, replay loading, or visualization strategy. It does not silently reduce the canonical evidence record merely to keep a visualization small.

Runtime evidence is computed first. Presentation adapts second.

This makes the interface a projection of the evidence architecture—not the authority behind it.

What Is Original in the Engineering

Fieldglass does not claim to have invented logs, entropy, hashes, trajectories, role graphs, attractors, regimes, or replay as isolated concepts.

Its engineering contribution lies in how these elements are integrated.

A source-bound record becomes a role-bearing canonical runtime. That runtime becomes a temporally ordered evidence authority. Measurements receive explicit legitimacy classes. Instruments operate as contract-bound projections. Interpretation remains subordinate to evidence. Reconstruction, investigation, Passports, and preservation remain tied to the same identity.

This is materially different from assembling several analytical charts inside one interface.

The code implements a reference architecture for Evidence-Governed Runtime Reconstruction.

It makes the underlying scientific constructs:

• executable;

• inspectable;

• versionable;

• replayable;

• preservable;

• challengeable;

• and available for empirical validation.

What the Code Does Not Prove

The existence of the implementation demonstrates that the architecture can be built.

It does not, by itself, validate every scientific construct or establish universal predictive performance.

Fieldglass must still be evaluated through:

• deterministic replay;

• negative and stable controls;

• temporal-leakage testing;

• role-topology ablation;

• construct validation;

• cross-domain evaluation;

• prospective studies;

• calibrated datasets;

• and independent replication.

The system’s scientific credibility depends on preserving this distinction.

The code operationalizes the theory. Validation determines which measurements and claims survive independent testing.

The Complete Engineering Contribution

Fieldglass brings together source qualification, role-aware canonicalization, runtime reconstruction, temporal authority, stability measurement, signal governance, scientific instrumentation, interpretive routing, guided investigation, Passport issuance, and evidence preservation within one coherent computational system.

That is what the code actually does.

It takes records that ordinarily remain fragmented across logs, transcripts, traces, and incident histories and transforms them into a single evidence-bearing runtime that another person can inspect from source to conclusion.

Fieldglass turns runtime behavior into an object that can be reconstructed, measured, questioned, replayed, preserved, and challenged—without asking the investigator to trust the explanation.

Read the Engineering Architecture

Explore the complete implementation, authority model, schemas, runtime lifecycle, and code-to-paper crosswalk behind Fieldglass.