Controlled Source Qualification and Role-Preserving Canonicalization

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

Before SubstrateX Aperture™ can reconstruct a worldline, compute a registered signal, establish a temporal marker, classify a regime, or produce an Instrument Finding, it must determine what record was supplied, how that record is structured, which roles and events are observable, which transformations are authorized, and which ambiguities remain unresolved.

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

The Aperture Ingestion Engine establishes this first evidentiary boundary.

The SubstrateX Aperture™ Ingestion Engine is the controlled boundary between heterogeneous operational records and Aperture computation. It binds the supplied source, qualifies its observable structure, applies a declared and versioned adapter, normalizes supported roles and events with explicit provenance, and constructs the canonical runtime input required for evidence computation—without creating telemetry, deciding what occurred, or altering the evidentiary 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 displays a measurement. It begins when an observable record enters the system and every material transformation between that record and the computational runtime becomes identifiable, inspectable, and bounded.

The controlled intake path is:

Observable source
↓
Raw source binding and source identity
↓
Preflight qualification
↓
Source-family detection
↓
Declared, versioned adapter
↓
Role, event, coordinate, and source-span mapping
↓
Canonical runtime construction
↓
Canonical identity and ingestion disclosures
↓
Handoff to reconstruction and evidence computation

Each stage protects a different evidentiary relationship.

• The source binding establishes what bytes or records were supplied.

• Preflight determines whether the observable structure can enter a supported path.

• Source-family detection describes what the record structurally resembles.

• The adapter performs declared transformations into canonical units.

• Role and event mapping preserves interaction and operational structure.

• Source-span mapping retains a path from canonical units back to the supplied record.

• Canonical identity distinguishes the normalized computational input from both the raw source and later evidence artifacts.

• Ingestion disclosures carry ambiguity, missingness, overrides, and limitations into downstream computation.

The Ingestion Engine does not itself produce the Current Evidence Run. It produces the qualified, provenance-bearing canonical runtime that reconstruction and evidence computation consume. The Current Evidence Run is formed only after authorized computational objects begin to be assembled around that canonical input.

Four Concepts That Must Remain Distinct

Ingestion becomes unreliable when file format, source family, adapter, and Operational World are treated as interchangeable.

Input representation
Describes how the supplied record is encoded, such as text, JSON, JSONL, or another supported representation.
What operational domain the record represents.

Source family
Describes the observable structure, conventions, roles, and event semantics the record resembles.
How the operator wishes to investigate the record.

Ingestion adapter
Performs a declared and versioned transformation from a supported source structure into canonical runtime units.
Scientific telemetry, markers, regimes, or conclusions.

Operational World
Describes the operator’s investigative environment and domain context.
Adapter selection, canonicalization, or evidence computation.

These objects may be related, but none may silently substitute for another.

A JSON file is not automatically a CI record. A selected Security Operations world does not make an ambiguous log a SIEM source. A source-family suggestion does not authorize an adapter to invent missing structure. An adapter recommendation does not become an applied transformation until it is selected or resolved under the declared ingestion rules.

Detected source family describes the record. Applied adapter describes the transformation. Selected Operational World describes the investigation.

Heterogeneous Operational Records

Aperture is designed to qualify different forms of longitudinal computational and operational activity through one canonical runtime architecture.

Supported or candidate source families may include:

• Aperture-structured transcripts;

• conversational and role-delimited transcripts;

• agent and tool-execution traces;

• GitHub and continuous-integration records;

• security and SIEM incident records;

• cloud and infrastructure logs;

• workflow and ticket histories;

• support and customer-incident records;

• monitoring and observability exports;

• structured validation fixtures; and

• other records for which a declared adapter and evidence contract exist.

The list identifies source families, not universal compatibility claims. A family is supported only to the extent that the active release contains an applicable adapter, schema, tests, and declared limitations.

Two records may share a file extension while containing different operational structures. Conversely, the same source family may arrive through several encodings. Aperture therefore qualifies the observable record rather than inferring its evidentiary meaning from the filename alone.

Raw Source Binding and Identity

The first obligation of ingestion is to preserve the distinction between what was supplied and what Aperture later constructed.

The raw source binding may retain or reference:

• the supplied source object;

• source name and representation;

• byte length or record count;

• source hash where supported;

• acquisition or loading context;

• declared source metadata;

• source-origin disclosures;

• encoding and parsing status;

• truncation or coverage warnings; and

• the relationship between the complete source and any bounded interface preview.

The source identity is not the run identity, canonical identity, record identity, or artifact identity. Those identities arise at different stages and must remain distinguishable.

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

The interface may summarize the source. Canonicalization remains accountable to the complete qualified record.

If the declared source cannot be resolved, read, or qualified, Aperture exposes the failure. It does not silently substitute sample content, a cached fixture, an earlier run, or inferred data.

Source binding establishes what entered the system. It does not certify that every proposition contained in the source is true.

Preflight Qualification

Preflight determines whether the source can proceed through a supported ingestion path and which limitations must accompany it.

Qualification may examine observable characteristics such as:

• structural delimiters;

• message, turn, or event ordering;

• role labels and role changes;

• timestamp availability and consistency;

• tool records and tool-result boundaries;

• workflow transitions;

• incident markers;

• recognizable source-family conventions;

• source-span recoverability;

• record continuity;

• required-field availability;

• encoding integrity; and

• evidence volume.

Preflight may report:

• detected or candidate source family;

• source-family confidence or ambiguity;

• proposed adapter and version;

• adapter availability;

• detected roles and unresolved labels;

• preliminary event or turn counts;

• timestamp and ordering posture;

• structural warnings;

• evidence-volume estimate;

• proposed operating band;

• selected Operational World as separate operator context;

• mismatch between detected source family and selected Operational World; and

• conditions requiring operator review.

Source-family detection is a qualified structural finding. It is not an unquestionable declaration of what the source “really is.” When several interpretations remain plausible, Aperture must preserve the ambiguity rather than force the record into a preferred family.

Preflight does not compute:

• behavioral telemetry;

• runtime stability;

• regime state;

• Basin Exit;

• formal lead time;

• worldline findings;

• recovery posture;

• Instrument Findings;

• REIM classification; or

• a Runtime Evidence Passport.

A record can be parseable without being sufficient for every scientific or operational claim.

Versioned Adapter Authority

Adapters allow heterogeneous source structures to enter one canonical runtime architecture.

Each adapter must declare:

• the source families it supports;

• the input representations it accepts;

• the structures and delimiters it recognizes;

• the segmentation and ordering rules it applies;

• the roles and aliases it can normalize;

• the event families it can extract;

• its timestamp and coordinate handling;

• its source-span behavior;

• its identifier and version;

• its assumptions and defaults;

• its ambiguity and missingness states;

• its warnings and refusal conditions; and

• the limits of its authority.

An adapter may:

• parse and segment;

• normalize supported structure;

• map declared roles and events;

• reconcile supported representations;

• preserve source references;

• qualify uncertainty;

• expose missingness; and

• refuse unsupported input.

An adapter may not:

• fabricate missing events;

• invent undisclosed participants;

• turn an ambiguous role into a source fact;

• infer hidden model state;

• assign intent, cause, responsibility, or blame;

• generate scientific telemetry;

• establish regimes or Basin Exit;

• compute formal lead time;

• force the source into the selected Operational World;

• use validation expectations as source evidence; or

• produce downstream conclusions.

The deterministic expectation is:

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

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

Role-Preserving Canonicalization

Roles are evidence-bearing structural relationships. They affect how participants, tools, observers, and operational authorities are represented across the runtime.

Where supported, Aperture may distinguish:

• source-supplied roles;

• recognized aliases;

• normalized canonical roles;

• adapter-assigned structural roles;

• operator-reviewed corrections;

• unresolved roles;

• tool and observer distinctions;

• role transitions; and

• mapping confidence and provenance.

Canonical roles may include structures such as:

System
User
Assistant
Engineer
Manager
Project Manager
Observer
Tool
Administrator

These are structural translations, not declarations of personal identity, organizational authority, competence, intention, or responsibility outside the supplied record. An adapter-assigned role must never appear as though it was explicitly supplied by the source. An operator correction must remain visible as an override. If that correction changes the canonical runtime used for computation, the canonical identity and subsequent run identity must reflect the change.

Preferred Explicit Structure

Where possible, role-delimited records provide the clearest pre-canonicalization structure:

Engineer:
Regression reproduced.

Tool:
Command executed.

Assistant:
Investigating the recorded failure sequence.

This makes several relationships visible before transformation:

• who or what produced each entry;

• where one runtime unit ends and another begins;

• how roles changed;

• which content is an action, observation, or tool result; and

• what order the interactions followed.

Unstructured records may still be processed when a suitable adapter exists. Any boundaries, roles, or event types introduced by the adapter must remain identified as derived structure rather than source-supplied fact.

Event, Coordinate, and Source-Span Preservation

Every canonical runtime unit should retain a path back to the record from which it was constructed.

Where supported, a canonical unit may preserve:

• source span or record reference;

• original ordering;

• source event or turn identity;

• canonical event or turn identity;

• supplied timestamp;

• normalized timestamp representation;

• source-supplied role;

• normalized or assigned role;

• event family;

• adapter action;

• transformation provenance;

• ambiguity or missingness state; and

• applicable warnings.

The adapter may normalize timestamp representation. It does not establish later temporal claims merely by parsing a time field. Wall-clock time, event order, turn order, dependency order, and symbolic time remain distinct coordinate domains. Their reconciliation and claim authority belong to the downstream temporal architecture.

This lineage allows an investigator to move backward from:

Instrument Finding
↓
Measurement and runtime frame
↓
Canonical event
↓
Source span

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

Canonical Runtime Construction

The canonical runtime is the normalized computational representation produced from the qualified source.

Depending on the source and adapter, it may contain or support:

• ordered canonical units;

• roles and role transitions;

• event identities and event families;

• source-span references;

• tool and operational records;

• supplied and normalized time references;

• availability and missingness states;

• transformation provenance; and

• the structural basis for the runtime event ledger, runtime spine, and playback frames.

Canonicalization provides a common computational form across heterogeneous records. It does not replace the raw source, establish scientific findings, or certify that the source account is true.

Three identities must remain distinct at this stage:

IdentityWhat it identifiesSource identityThe supplied record before canonical transformation.Canonical identityThe normalized runtime input under a declared adapter and canonicalization version.Run identityThe later evidence computation formed from canonical input, configuration, and governing method versions.

Changing presentation does not change canonical identity. Changing source content, adapter behavior, canonical mapping, or evidence-bearing canonicalization options may.

Evidence Volume and Operating Bands

Evidence volume affects computation, replay, visualization, and export strategy. It does not authorize the interface to discard the canonical record.

The current public operating bands may be expressed as:

BandIndicative sizeComputational and presentation postureInteractive0–250 turnsFull reconstruction and telemetry with fully hydrated worldline, replay, instruments, and export where supported.Extended Local251–1,000 turnsFull evidence computation with sampled or progressively hydrated visualization, progressive replay, and chunked export.Archive1,001–2,500 turnsBatch-oriented reconstruction, summary-first visualization, progressive replay loading, and evidence-first export.

These figures describe declared implementation bands, not universal scientific limits. Record complexity, event density, browser resources, adapter behavior, and release configuration may also affect capacity.

The modes may change:

• rendering density;

• progressive hydration;

• replay loading;

• visualization sampling;

• panel priority;

• export assembly; and

• expected compute time.

They must not silently change:

• source identity;

• canonical content;

• evidence-bearing event order;

• measurement definitions;

• marker semantics;

• Instrument Findings;

• claim boundaries; or

• preserved evidence coverage.

The canonical evidence structure is established before its presentation strategy is selected.

If a record exceeds the declared capacity of the active release, Aperture must refuse, qualify, or route it through an explicitly supported mode. Silent truncation is not an ingestion strategy.

Missingness, Ambiguity, and Refusal

A controlled ingestion system must be capable of declining to create a complete canonical runtime.

Relevant qualification or refusal states may include:

• unsupported source structure;

• unresolved source-family ambiguity;

• unavailable adapter;

• adapter mismatch;

• malformed structured data;

• unsupported encoding;

• missing required fields;

• invalid or indeterminate ordering;

• timestamp inconsistency;

• unresolved role ambiguity;

• broken source-span mapping;

• excessive or undisclosed truncation;

• insufficient runtime horizon; and

• evidence volume beyond the declared operating band.

Aperture must expose these conditions rather than silently repair the record or imply that a complete reconstruction is available.

A partially qualified source may support a limited canonical runtime. If so, its limitations must propagate into reconstruction, evidence coverage, Signal Authority, temporal admissibility, Instrument Findings, REIM, Human Read, Runtime Evidence Authority, the Passport, and preservation.

Unavailable structure must remain unavailable. Ambiguity must remain visible. A default must never masquerade as source evidence.

Validation-Case Isolation

Registered validation cases pass through the same ingestion and canonicalization pipeline as operator-supplied records.

Fixture context may include:

• scenario identity;

• expected evidence;

• known positive or negative conditions;

• prohibited claims;

• comparison rules; and

• validation metadata.

Those objects are not part of the computational source unless the fixture explicitly includes them as source content.

The Ingestion Engine must keep sample identity, expected outcomes, case framing, rubric scores, and interface labels outside canonical evidence formation. Otherwise, the validation case could contaminate the result it is intended to test.

The canonical runtime is formed first. Comparison with a locked expectation map occurs afterward through the Validation Harness.

The Handoff to Evidence Computation

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

The handoff becomes available when:

• source identity has been established;

• the raw source has been bound or appropriately referenced;

• source-family posture has been recorded;

• the applied adapter and version are known;

• canonicalization has completed or declared partial status;

• role, event, coordinate, and source-span provenance are available;

• operator overrides have been disclosed;

• structural warnings and missingness have been recorded; and

• canonical identity can be resolved.

The resulting canonical runtime can then support:

• runtime event-ledger construction;

• canonical runtime-spine formation;

• playback-frame construction;

• Runtime Reconstruction;

• behavioral telemetry;

• temporal and marker authority;

• the Current Evidence Run;

• the Runtime Stability Foundation;

• bounded Instrument Findings;

• REIM and Human Read;

• Runtime Evidence Authority;

• Passport issuance; and

• preservation.

The Ingestion Engine cannot override any of those downstream authorities.

Relationship to Operational World Mapping

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

The Ingestion Engine asks:

How does this supplied record become a qualified canonical runtime?

Operational World Mapping asks:

How is domain meaning preserved around canonicalization and returned through an appropriate investigative lens?

The Operational World registry may provide domain vocabularies, role aliases, event-semantic dictionaries, adapter recommendations, preflight guidance, and mismatch disclosure. The Ingestion Engine remains responsible for applying the adapter and constructing the canonical runtime.

After computation, the Operational World Lens may change terminology, explanatory emphasis, recommended questions, instrument priority, and navigation. It cannot change the canonical runtime, telemetry, markers, Instrument Findings, REIM posture, evidence identity, Evidence Seal, or preservation authority.

If an operator changes only the selected Operational World, the underlying evidence computation remains unchanged.

If an operator changes the applied adapter, role mapping, event mapping, or another evidence-bearing canonicalization decision, the canonical runtime must be recomputed and its identity must reflect the change.

Relationship to Runtime Evidence Authority and the Passport

Ingestion establishes the source and canonical lineage that later authority objects depend upon.

Runtime Evidence Authority evaluates whether downstream computed material satisfies the identity, provenance, legitimacy, sufficiency, disclosure, claim-lineage, and conformance requirements necessary to become qualified Runtime Evidence.

The Runtime Evidence Passport may subsequently carry or reference:

• source identity;

• canonical identity;

• run and record identity;

• adapter and canonicalization versions;

• source coverage;

• ingestion warnings;

• disclosed overrides;

• evidence sufficiency;

• claim boundaries;

• certification scope;

• explicit non-certifications; and

• preservation status.

The Passport does not retroactively improve the source or erase ingestion limitations. It carries those limitations forward as part of the evidence object’s authority.

Claim Boundary

The Ingestion Engine may establish:

• what source was supplied;

• how it was encoded and bound;

• which source family it resembles;

• which adapter was applied;

• how canonical units were formed;

• how roles, events, coordinates, and source spans were mapped;

• which transformations and overrides occurred;

• what canonical identity resulted; and

• which limitations accompanied the transformation.

It does not independently establish:

• behavioral stability;

• runtime regimes;

• Basin Exit;

• formal lead time;

• recovery or re-entry;

• operational impact;

• root cause or unique causation;

• hidden model state or private reasoning;

• intent, consciousness, cognition, agency, or identity;

• objective truth;

• responsibility, competence, or blame;

• safety or compliance; or

• the final authority of a downstream claim.

Those matters require subsequent computation, qualified evidence, external context, or human judgment.

The Architectural Contribution

File parsers, log adapters, role mappings, and canonical schemas are not individually new.

The Aperture contribution is their integration within an evidence-governed runtime architecture in which:

• the supplied source remains distinct from its canonical representation;

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

• every material transformation retains provenance;

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

• source family, adapter, Operational World, and interface lens cannot silently substitute for one another;

• preflight cannot manufacture scientific findings;

• validation expectations cannot enter canonical evidence formation;

• ambiguity, missingness, and overrides propagate downstream;

• presentation modes cannot reduce evidence authority;

• computation begins only after canonicalization; and

• every downstream finding can retain a path through the canonical runtime to the originating source.

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

It is the first controlled boundary at which an operational record becomes eligible for evidence computation.

The Governing Definition

The SubstrateX Aperture™ Ingestion Engine is the versioned, provenance-preserving source boundary that binds heterogeneous operational records, qualifies their observable structure, applies declared adapters, constructs role- and event-aware canonical runtimes, and carries ambiguity and missingness into downstream computation without creating telemetry, interpretation, or evidence beyond the supplied record.

Runtime 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.