Controlled Source Qualification and Role-Preserving Canonicalization

Every runtime reconstruction depends on how its source entered the system.

Before Fieldglass can compute a signal, reconstruct a worldline, identify a regime, or project an instrument finding, it must establish what record was supplied, how that record is structured, which roles and events are present, what transformations were applied, and which ambiguities remain unresolved.

If these relationships are lost during ingestion, every downstream result may inherit the error.

The Fieldglass Ingestion Engine establishes this first evidentiary boundary.

The Fieldglass Ingestion Engine is the controlled boundary between heterogeneous operational records and Fieldglass computation. It preserves the supplied source, qualifies its observable structure, applies a declared and versioned adapter, normalizes roles and events with explicit provenance, and constructs the canonical runtime from which evidence computation may begin—without creating telemetry or altering the meaning of the source.

Its governing principle is:

Structure may be normalized. Evidence may not be invented.

Where Runtime Evidence Begins

Runtime evidence does not begin when an instrument produces a measurement.

It begins when an observable record enters the system and becomes bound to a traceable sequence of transformations.

The canonical ingestion path is:

Observable Source
→ Raw Source Binding
→ Preflight Qualification
→ Source-Family Detection
→ Versioned Adapter
→ Role and Event Mapping
→ Canonical Runtime Construction
→ Evidence Compute
→ Current Evidence Run

Each stage preserves a different aspect of evidentiary integrity.

The source establishes what was supplied. Preflight determines whether its structure can be processed. The adapter translates supported structures into canonical form. Role and event mapping preserve the interaction topology. Canonical runtime construction creates the normalized object required for computation.

Only after these stages complete may Fieldglass generate runtime telemetry and establish the Current Evidence Run.

Heterogeneous Operational Records

Fieldglass is designed to work across different forms of longitudinal computational and operational behavior.

Supported source families may include:

• Fieldglass structured transcripts;

• conversational and role-delimited transcripts;

• GitHub and continuous-integration records;

• security and SIEM incident records;

• cloud and infrastructure logs;

• workflow and ticket histories;

• support and customer incident records;

• tool and agent execution traces;

• monitoring and observability exports;

• and other qualified operational records.

These are source families, not file formats.

A source family describes the operational environment and event structure represented by the record. A file format describes how that record is encoded, such as plain text, structured text, JSON, or another supported representation.

Keeping those concepts separate prevents Fieldglass from assuming that two files with the same extension contain the same kind of evidence.

Source Qualification

The Ingestion Engine does not assume that every uploaded record is complete, correctly labeled, or suitable for every form of analysis.

It first qualifies the source by examining observable characteristics such as:

• structural delimiters;

• message or event ordering;

• role labels;

• timestamps;

• tool records;

• workflow transitions;

• incident markers;

• recognizable source-family conventions;

• and evidence continuity.

Source-family detection is a qualified computational finding. It is not an unquestionable declaration of what the record “really is.”

When evidence is ambiguous, Fieldglass must expose that ambiguity instead of silently forcing the source into a preferred structure.

Preflight Before Compute

Preflight establishes whether the source can proceed into evidence computation and what limitations will accompany it.

Before compute, Fieldglass may show:

• the detected source family;

• the selected Operational World;

• any mismatch between selected and detected context;

• the proposed adapter and its status;

• the adapter version;

• source coverage and structural warnings;

• detected or mapped roles;

• canonical turns or events produced;

• approximate evidence volume;

• expected operating band;

• recommended investigative path;

• and whether unresolved conditions remain.

Preflight does not generate scientific findings.

It does not compute:

• runtime telemetry;

• stability regimes;

• Basin Exit;

• Lead-Time;

• worldline findings;

• instrument conclusions;

• recovery classifications;

• or a Certified Runtime Evidence Record.

Preflight qualifies and prepares the record. Evidence computation begins afterward.

The fact that a source can be parsed does not mean that every scientific claim is available.

Raw Source and Canonical Runtime

Fieldglass preserves a strict distinction between the record supplied by the operator and the representation constructed for computation.

ObjectFunctionRaw sourceThe original material supplied to FieldglassCanonical runtimeThe normalized, evidence-bearing representation used for deterministic computationCurrent Evidence RunThe active authority binding the source, canonical runtime, measurements, markers, findings, and claim boundariesCertified Runtime Evidence RecordThe sealed or preserved evidence payload produced later in the lifecycle

Canonicalization may normalize:

• supported structural delimiters;

• role aliases;

• event representations;

• turn boundaries;

• timestamp formats;

• tool records;

• and source references.

It must not silently change:

• substantive source content;

• evidentially meaningful ordering;

• source-supplied roles;

• tool results;

• recorded timestamps;

• or unresolved ambiguity.

The canonical runtime is derived from the source. It never replaces the source.

Where the raw material is retained only within the browser session, that retention must remain distinct from durable preservation. Long-term preservation occurs only through the declared preservation and export process.

Versioned Adapter Authority

Adapters allow heterogeneous records to enter one canonical runtime architecture.

Each adapter must declare:

• the source families it supports;

• the structures it recognizes;

• accepted input representations;

• the roles and aliases it can normalize;

• the event families it can extract;

• its version;

• its assumptions;

• its ambiguity states;

• its failure conditions;

• and the limits of its authority.

An adapter may:

• parse;

• segment;

• normalize;

• qualify;

• map supported structures;

• retain source references;

• and declare uncertainty.

An adapter may not:

• fabricate missing events;

• invent undisclosed participants;

• infer hidden model state;

• assign intent;

• generate scientific telemetry;

• determine Basin Exit;

• create Lead-Time;

• force the record into the operator’s selected world;

• or produce downstream conclusions.

The deterministic expectation is:

Same source + same adapter version + same declared options = same canonical runtime.

If an adapter changes how evidence is segmented, ordered, or represented, its version must change. The resulting canonical identity must preserve that distinction.

Role-Preserving Canonicalization

Roles are not cosmetic labels. They define how participants, tools, and operational authorities relate across the recorded runtime.

Fieldglass may normalize supported source labels into canonical roles such as:

System
User
Assistant
Engineer
Manager
PM
Observer
Tool
Admin

Examples of operational aliases may include:

sre → Engineer
platform_engineer → Engineer
soc_analyst → Observer
security_analyst → Observer
incident_commander → Manager
github_actions → Tool
datadog → Tool
splunk → Tool
cloudwatch → Tool
grafana → Tool

These mappings are versioned structural translations. They are not claims about a participant’s personal identity, intent, responsibility, or authority outside the supplied record.

Fieldglass distinguishes among several forms of role provenance:

Role provenanceMeaningSource-suppliedThe role was explicitly present in the original recordAlias-normalizedA supported source label was mapped to a canonical roleAdapter-assignedThe adapter proposed a role needed to represent an otherwise unstructured sourceOperator-confirmedThe operator accepted a proposed mappingOperator-overriddenThe operator changed the proposed or detected role assignment

An adapter-assigned role must never appear as though it came directly from the source.

An operator override must remain visible in provenance. If that override changes the canonical runtime used for computation, the evidence identity must reflect the change.

Preferred Role-Delimited Structure

Where possible, Fieldglass accepts explicit role-delimited records:

Engineer:
Regression reproduced.

Tool:
Command executed.

Assistant:
Investigating the recorded failure sequence.

This structure makes several evidentiary relationships visible before canonicalization:

• who or what produced each entry;

• where one runtime unit ends and another begins;

• how role transitions occurred;

• and what order the interactions followed.

Unstructured records may still be processed where an appropriate adapter exists. Any structure introduced by that adapter must remain disclosed.

Event and Source-Span Preservation

A canonical runtime must retain a path back to the source material from which it was constructed.

Where supported, each canonical unit may preserve:

• source span;

• original ordering;

• event or turn identity;

• timestamp or coordinate;

• source-supplied role;

• normalized role;

• event family;

• adapter action;

• and transformation provenance.

This enables an investigator to move backward from:

Instrument finding
→ Runtime frame
→ Canonical event
→ Source span

Without that path, a finding may be visually persuasive but evidentially detached.

Operational World Boundaries

Fieldglass keeps three identities separate during ingestion:

ObjectMeaningAuthoritySelected Operational WorldThe environment chosen by the operator for orientationGuidance and presentationDetected Source WorldThe source family suggested by observable characteristicsQualified detectionCanonical RuntimeThe normalized object used for computationComputational authority

For example, an operator may select Workflow Coordination while Fieldglass detects that the supplied material resembles a Software Engineering and CI record.

The system should disclose that mismatch. It must not silently force the source into the selected world.

The selected world frames the investigation. The detected world describes the source. The canonical runtime governs computation.

Operational World context may change examples, terminology, intake guidance, and recommended investigative paths. It does not change telemetry.

Evidence-First Scaling

Fieldglass prioritizes evidence preservation and complete canonical construction over visualization density.

Current operating bands include:

Interactive

0–250 turns

• full runtime reconstruction;

• full telemetry computation;

• full worldline visualization;

• full instrument projection;

• and full export coverage.

Extended

251–1,000 turns

• full runtime reconstruction;

• full telemetry computation;

• sampled worldline rendering;

• progressive replay;

• and chunked export generation.

Archive Scale

1,001–2,500 turns

• batch reconstruction;

• full evidence preservation;

• summary-first visualization;

• progressive replay loading;

• and evidence-first export.

These operating modes may change how evidence is rendered, hydrated, replayed, or exported. They must not discard source evidence merely to satisfy interface constraints.

The evidence is constructed before its presentation strategy is selected.

Failure and Refusal States

A controlled ingestion system must be capable of refusing, qualifying, or limiting a record.

Relevant states may include:

• unsupported source structure;

• unresolved role ambiguity;

• invalid event ordering;

• malformed structured data;

• missing required fields;

• timestamp inconsistency;

• excessive truncation;

• adapter mismatch;

• insufficient runtime horizon;

• unsupported encoding;

• and evidence volume beyond the declared operating band.

Fieldglass should expose these conditions rather than silently repairing the record or implying that a complete reconstruction is available.

A partially qualified source may still support limited analysis, but its limitations must propagate into the Current Evidence Run and every downstream claim.

The Handoff to Evidence Computation

The Ingestion Engine prepares the source for measurement. It does not certify conclusions.

Evidence computation may begin only after:

• source identity has been established;

• the raw source has been bound;

• the adapter and version have been recorded;

• canonicalization has completed;

• role and event provenance have been preserved;

• structural warnings have been disclosed;

• and material preflight conditions have been resolved or accepted.

The resulting canonical runtime then becomes an input to the Current Evidence Run.

From that point:

• telemetry is computed;

• temporal markers are established;

• regimes are reconstructed;

• the Runtime Stability Foundation is formed;

• instruments project findings;

• Guided Investigation exposes evidence paths;

• and preservation may produce a Certified Runtime Evidence Record and Runtime Evidence Passport.

The Ingestion Engine cannot override any of these downstream authorities.

Relationship to Operational World Mapping

The Ingestion Engine and Operational World Mapping are related but distinct.

The Ingestion Engine asks:

How does this source become a qualified canonical runtime?

Operational World Mapping asks:

How does evidence move between a domain-specific operational environment and the canonical Fieldglass architecture?

The Ingestion Engine establishes the record, roles, events, adapters, and provenance.

Operational World Mapping uses that qualified structure to translate domain-specific records inward and return evidence-supported findings through appropriate operational language.

Neither permits the operational lens to manufacture telemetry or rewrite the evidence.

Claim Boundary

The Ingestion Engine can establish:

• what source was supplied;

• which structure was detected;

• which adapter was applied;

• how roles and events were mapped;

• what canonical runtime was constructed;

• and which limitations accompanied that transformation.

It cannot establish:

• hidden reasoning;

• internal model state;

• consciousness;

• intent;

• objective truth;

• responsibility or blame;

• unique causation;

• behavioral stability;

• Basin Exit;

• Lead-Time;

• or operational significance.

Those questions require subsequent evidence computation, instrument findings, external context, or human judgment.

The Architectural Contribution

File parsers, log adapters, and role normalization are not individually new.

The Fieldglass contribution is their integration within a controlled evidence architecture:

• the raw source remains distinct from its canonical representation;

• every material transformation retains provenance;

• source-supplied and adapter-assigned roles remain distinguishable;

• Operational World context cannot rewrite the source;

• preflight cannot manufacture scientific findings;

• computation begins only after canonicalization;

• ambiguity and missingness remain visible;

• and every downstream result can be traced through the adapter to the originating record.

The Ingestion Engine is therefore not simply the entrance to Fieldglass.

It is the first point at which Fieldglass establishes whether the runtime can become evidence at all.

Fieldglass evidence does not begin when an instrument produces a measurement. It begins when the source enters the system and every transformation between that source and the canonical runtime remains visible, bounded, and accountable.