Fieldglass® Engineering Architecture
A Browser-Local Reference Implementation for Source-Bound Runtime Reconstruction and Evidence-Governed Computation
Fieldglass® is not a collection of dashboards assembled around a log analyzer. It is a browser-local computational architecture designed to preserve authority continuously—from the source record through reconstruction, measurement, interpretation, investigation, Passport issuance, and export.
Fieldglass is a browser-local, evidence-governed architecture in which source records are qualified and bound to canonical identity, transformed into role-bearing runtime trajectories, measured through versioned signal authority, and exposed through instruments, interpretations, investigations, Passports, and preservation artifacts that remain bounded by the same evidence run.
Its defining engineering property is authority continuity.
Every authoritative measurement, marker, finding, interpretation, visualization, and export must remain accountable to the same source-bound runtime object.
From Research Instrument to Computational Architecture
Fieldglass began as an experimental environment for making concepts developed through Recursive Science® visible in recorded interactions.
As the system developed, the engineering problem expanded.
It was no longer enough to calculate a trajectory or display a regime map. An investigator also needed to know:
which source produced the reconstruction;
how the source was qualified;
how events and roles were canonicalized;
which values were observed, derived, or projected;
when a temporal marker became available;
which instrument was authorized to present a finding;
whether different surfaces referred to the same run;
what a conclusion was permitted to claim;
and what evidence would remain after the interface closed.
These requirements produced a complete architecture.
A worldline cannot select its own source. An instrument cannot invent telemetry because its display requires a value. An operational lens cannot alter the underlying measurement. An interpretation cannot convert a proxy into a fact. A Passport cannot certify more than the record contains. An export cannot retain the conclusion while discarding its evidentiary lineage.
The Authority Path
The logical architecture follows one controlled path:
Source Record
→ Source Authority
→ Qualification and Canonicalization
→ Canonical Runtime
→ Versioned Computation
→ Current Evidence Run
→ Certified Runtime Evidence Record
→ Bounded Projections
→ Investigation
→ Runtime Evidence Passport
→ EvidenceCommons Preservation
Each transition has an explicit boundary.
Source resolution does not perform diagnosis.
Canonicalization does not establish failure.
Measurement does not establish cause.
An instrument finding does not modify telemetry.
REIM does not create evidence.
Investigation does not rewrite the run.
Passport issuance does not certify truth.
Preservation does not increase claim authority.
The architecture keeps evidence creation, measurement, interpretation, presentation, and preservation distinct while maintaining their lineage.
The Governing Invariants
Fieldglass is organized around a stable set of engineering rules.
Source Primacy
Every authoritative result must resolve to identifiable source material or an explicitly disclosed external dependency.
Canonical Identity
One qualified source and computation profile must resolve to one identifiable run authority. Routes and instruments cannot create competing run identities.
Evidence Before Projection
Canonical runtime records and evidence objects are formed before visualization, narrative interpretation, or operational framing.
Authority Non-Amplification
No projection may support a stronger claim than its evidence, method, temporal horizon, and authority class allow.
Instrument Non-Sovereignty
Instruments read registered evidence. They cannot create telemetry, move formal markers, change Passport identity, or rewrite the evidence record.
Temporal Admissibility
Every temporal claim must identify its coordinate, eligible evidence horizon, marker authority, and prospective or retrospective status.
Explicit Absence
Missing, unavailable, ambiguous, conflicting, not-computable, candidate, and unconfirmed states remain distinct from zero or a positive finding.
Contextual Non-Interference
Operational Worlds may change language, guidance, examples, and investigative emphasis. They do not change canonical telemetry.
Preservation Closure
A preserved conclusion must travel with its source identity, method lineage, status, limitations, and claim boundary.
Source Provider and Ingestion Architecture
Fieldglass begins with source material already available to the operator:
transcripts;
logs and traces;
JSON and JSONL events;
incident communications;
workflow records;
tickets;
tool and agent traces;
guided samples;
and validation bundles.
The source-provider architecture separates several responsibilities that ordinary upload interfaces often collapse:
resolving the selected source;
preserving the source identity and bytes;
verifying available integrity information;
recording source and fixture metadata;
qualifying the material for supported computations;
caching or retaining it under the active session policy;
and exposing explicit failure states when the source cannot be resolved.
Source content remains data. Prompt-like instructions, malicious text, or executable snippets contained inside a record do not gain authority to alter Fieldglass policies, methods, registries, or exports.
Role-Aware Canonicalization
Fieldglass reconstructs behavior as an interaction among participants rather than flattening every event into one undifferentiated stream.
Canonical events preserve:
source identity and source span;
original actor and role labels;
normalized role classes;
role-assignment provenance;
confidence and ambiguity;
authority relationships;
role transitions;
handoffs;
tool participation;
temporal fields;
and transformation history.
This enables the system to reconstruct cross-role drift, authority conflict, handoff coherence, role-phase lag, epistemic fragmentation, tool-loop pressure, and observer-state divergence.
Role topology does not infer private identity, intent, motive, blame, or legal responsibility. It represents the operational relationships supported by the record.
Essential-First Evidence Formation
Fieldglass uses an essential-first evidence commit.
A browser-local system should not leave the entire run without authority because a large appendix, visualization, or export model is still being constructed. Fieldglass therefore commits the minimum evidence-bearing record as soon as the primary computation completes.
The essential record includes:
runtime identity;
canonical frames and events;
the runtime spine;
role context;
registered signals;
temporal markers;
regime state;
core measurements;
invariants;
and claim boundaries.
Large reports, visual models, supplemental projections, and export structures can be attached afterward.
This creates a stable evidence checkpoint before expensive presentation layers are hydrated.
The lifecycle progresses through five defined states:
Acquired → Qualified → Computed → Issued → Preserved
A route change, animation, or completed visualization cannot advance the evidence state. The lifecycle is controlled by the evidence objects themselves.
Current Evidence Run and Certified Record
The Current Evidence Run, or CER, is the active run-wide computational authority.
It holds the canonical runtime, registered measurements, temporal state, role relationships, evidence status, marker authority, instrument models, claims, and preservation context required by the system.
Once the release’s issuance conditions are satisfied, the canonical payload can be sealed as a Certified Runtime Evidence Record, or CRER.
Certification has a deliberately bounded meaning: the record completed the declared Fieldglass computation and evidence-formation contract.
It does not imply:
external accreditation;
scientific consensus;
source authenticity;
legal admissibility;
deployment approval;
or universal validity of every measurement.
The Canonical Runtime Spine
The canonical runtime spine is the shared coordinate and replay object underlying Fieldglass.
Each position may contain:
frame and source coordinates;
active roles;
source-linked content;
stability and motion values;
drift, pressure, recurrence, and continuity;
regime state;
temporal measurements;
boundary and recovery markers;
events;
evidence status;
and source references.
The worldline is projected from this spine.
It is not an arbitrary curve drawn through selected scores. Every visible point must resolve to a canonical frame, registered measurements, events, source material, and claim boundary.
This allows an investigator to move from aggregate shape to local evidence. A visible deformation can be inspected at its source position. A regime transition can be traced to the frames satisfying its persistence rule. Replay becomes traversal of the evidence object rather than animation over detached chart data.
Unified Temporal Authority
Fieldglass resolves temporal meanings through one shared temporal authority.
This prevents Seismo, Chronos, Reconstruction, operator briefs, and exports from independently deciding when weakening, boundary formation, Basin Exit, visible failure, or recovery occurred.
The architecture distinguishes:
t_aw — first governed weakening evidence;
t_candidate — first supported candidate-boundary evidence;
t* — confirmed Basin Exit under the registered contract;
tf — independently observable failure;
tr — supported recovery or re-entry.
A candidate boundary is not a confirmed transition. A confirmed Basin Exit is not automatically an observed failure.
Formal lead time is available only when the required anchors exist, use compatible coordinates, and appear in valid order. Without an observable failure anchor, Fieldglass may report an open post-exit observation window. It cannot manufacture a numerical lead-time claim.
Retrospective reconstruction must also remain distinct from prospective detection. A claimed warning at position t must be reproducible using only evidence available at or before t.
Runtime Stability Foundation
The Runtime Stability Foundation provides the shared stability substrate for every instrument and investigative surface.
It organizes evidence-bound representations of:
runtime phase;
continuity and coherence;
contraction and pressure;
attractor support;
basin geometry;
perturbation response;
boundary proximity;
weakening and confirmed transition;
recovery or re-entry;
and the limitations governing those representations.
The foundation cannot create telemetry, construct the CER, alter Signal Authority, modify compute, or grant export authority.
It is a read-only context built from the Certified Runtime Evidence Record.
Its quantities remain observable-output constructions unless stronger evidence is supplied. Identity coherence is a continuity measure—not identity as a fact. Basin geometry belongs to the registered representation—not a hidden physical space inside the model. A risk score is not a calibrated probability unless external calibration establishes that interpretation.
Signal Authority
A large analytical system may produce hundreds of intermediate values, arrays, scores, labels, and display calculations. Without governance, any visible number can gradually be treated as a canonical measurement.
Fieldglass controls this through Signal Authority.
Every governed signal identifies:
its stable name and family;
authority level;
source fields;
computation or proxy relationship;
temporal window;
evidence basis;
eligible consumers;
claim boundary;
prohibited interpretations;
and scientific and implementation status.
The reviewed architecture distinguishes three levels:
Level 0 — Core Surface Telemetry: evidence-near measurements.
Level 1 — Recursive Dynamics: derived behavioral and interaction constructs.
Level 2 — Instrument Projection: higher-order stability, regime, basin, recovery, continuity, and motion views.
A Level 2 projection cannot be presented as a direct observation.
The architecture also preserves a version distinction between the earlier 28-item Semantic Measurement Registry and the 25-entry RL1331 Signal Authority. The first is a research-facing measurement catalog. The second is the executable product-facing authority registry in the reviewed implementation. They are related, but not equivalent.
This distinction prevents version changes and architectural consolidation from being hidden behind one apparently stable count.
Contract-Bound Instruments
Fieldglass contains nine instrument contracts:
Seismo;
Chronos;
Drift;
Pressure;
Bridge;
Noesis;
Scope;
Dynamics;
and Interferometer.
Each contract declares:
which evidence objects it may read;
which signal levels it may consume;
which transformations it performs;
which findings it may produce;
how missing evidence is handled;
what it may display and export;
and what it is prohibited from claiming.
Instrument findings are first-class projection objects. They retain the run and Passport identity, authority level, evidence basis, signal dependencies, source spans, interpretation, operational context, confidence posture, claim boundary, and creation lineage.
The visual design of an instrument may evolve without changing its scientific contract. Changing its inputs, formula, threshold, classification rule, or exported claims creates a new contract version.
Runtime Evidence Interpretation Matrix
The Runtime Evidence Interpretation Matrix, or REIM, converts evidence-bound features into ranked interpretations and investigative routes.
It can distinguish conditions such as:
stable operation;
temporal formation;
boundary formation;
runtime drift;
role-coordination pressure;
tool-loop pressure;
recovery or re-entry;
and multi-factor incidents.
REIM does not create evidence, modify telemetry, or replace instrument findings. If no registered interpretation satisfies its threshold, it can report only that runtime evidence was computed.
That fallback is intentional. The architecture does not require every record to become an incident.
REIM is deterministic under a frozen implementation, but its weighted rules and representation-sensitive inputs make it a versioned heuristic interpretation layer, not a universally validated diagnostic classifier.
Its recommendations route investigation. They do not authorize intervention.
Reconstruction and Guided Investigation
Runtime Reconstruction brings the canonical spine, temporal authority, Runtime Stability Foundation, instrument findings, REIM, Passport identity, evidence ledger, and claim boundaries together in one investigation context.
The reconstruction is organized into chapters concerned with:
worldline formation;
runtime signals;
role topology;
instrument findings;
failure formation;
replay;
evidence formation;
claim lineage;
and preservation readiness.
The Guided Investigation Architecture provides the operator with relevant questions, inspection objectives, evidence status, source authority, confidence posture, and routes to supporting views.
The guide does not decide the case. It helps the operator move through unfamiliar evidence while preserving the difference between computational findings, human interpretation, unresolved questions, and formal claims.
Passport Identity
The Runtime Evidence Passport identifies the issued evidence record.
It can preserve:
source and run identities;
canonical hashes;
computation and build versions;
source and role coverage;
operational context;
model and toolchain disclosures when supplied;
formation and boundary state;
evidence and replay integrity;
claim boundaries;
disclosure status;
and preservation readiness.
The Passport contains both deterministic and variable information.
Canonical source identity, computation versions, frames, registered signals, marker states, and method-bound outputs can belong to the deterministic core. Issuance time, browser-session activity, operator declarations, display state, and export context may vary.
Fieldglass therefore distinguishes the deterministic evidence identity from a particular Passport issuance envelope.
The Passport identifies what was computed and under which boundaries. It does not certify truth, intent, hidden state, consciousness, root cause, or deployment safety.
Evidence Commons Preservation
Evidence Commons preservation carries the runtime beyond the live browser session.
A preservation bundle may contain machine-readable evidence objects, source and computation identities, instrument findings, human-readable reports, temporal and role appendices, validation results, surface audits, manifests, schemas, redaction states, and release information.
The objective is future challengeability.
A reviewer should be able to:
identify the source;
inspect or recompute the canonical runtime;
locate the basis of a signal or marker;
determine what an instrument was authorized to claim;
compare the result with another version;
and see where evidence was missing, withheld, or redacted.
A PDF may present the investigation, but presentation alone is not a complete evidence artifact. Machine-readable objects, contracts, versions, and manifests preserve the authority path.
Browser-Local Scaling
Fieldglass performs its public computation locally in the browser without mandatory server upload, account creation, or remote telemetry.
This creates a practical foundation for independent research and sensitive operational review, but it also introduces memory, responsiveness, and export constraints.
The architecture responds through:
preflight qualification;
compute bands;
worker execution;
essential-first evidence commit;
progressive replay;
deferred appendices;
bounded visual hydration;
sampled worldline rendering;
and chunked export generation.
The governing principle remains:
Runtime evidence is computed and preserved before a presentation strategy is selected.
Large runs may require reduced visualization density. The underlying evidence must not be silently truncated merely to satisfy the interface.
Evidence is preserved. Presentation adapts.
What the Engineering Establishes
The reviewed implementation establishes that the proposed architecture has been translated into an operating computational system.
The code resolves and qualifies sources, preserves roles, computes longitudinal features, creates canonical frames and events, forms a runtime spine, attaches shared temporal and stability contexts, governs signals by authority class, binds instruments through contracts, routes interpretation through REIM, identifies the run through a Passport, and packages evidence with its lineage and limitations.
This is stronger than a conceptual diagram.
Each architectural proposition now corresponds to executable objects, contracts, state transitions, audits, and failure conditions.
What It Does Not Establish
The existence of working code does not prove that:
Recursive Science is a complete account of intelligence;
worldlines are universal natural invariants;
Basin Exit predicts every failure;
stability proxies correspond to hidden model entities;
REIM generalizes across systems and domains;
every threshold is calibrated;
or every signal provides value beyond simpler baselines.
The implementation creates the conditions under which those questions can be tested.
An external researcher can reject the terminology while still evaluating source integrity, canonicalization, role ablation, deterministic replay, temporal leakage, marker issuance, signal dependence, surface congruence, and preservation fidelity.
The Engineering Contribution
Fieldglass combines existing lineages in logging, observability, process reconstruction, runtime verification, provenance, canonicalization, instrumentation, visual analytics, and AI governance.
Its distinctive engineering proposition is their integration around one source-bound runtime object:
role-bearing longitudinal reconstruction;
multiple temporal coordinates and governed markers;
stability, worldline, regime, boundary, and recovery representations;
explicit signal-legitimacy classes;
contract-bound instruments that cannot create authority;
evidence-bound interpretation and investigative routing;
deterministic evidence identity separated from issuance metadata;
and preservation of records, claims, absences, and limitations together.
Fieldglass implements a reference architecture for Evidence-Governed Runtime Reconstruction. Its defining achievement is not the number of metrics or interfaces it contains, but the continuity of authority from source evidence to preserved claim.
The physical implementation records the history of an intensive research and engineering process. The enduring architecture lies beneath it: the objects, contracts, schemas, authority boundaries, non-mutation rules, and preservation requirements that allow runtime behavior to become inspectable evidence.
