An Evidence-Governed Architecture for Runtime Intelligence

Computational Behavior Architecture defines the structural system through which activity produced by models, agents, tools, people, and operational environments can be reconstructed as an evidence-bearing runtime trajectory.

It is the architectural convergence point of the foundational research:

• Longitudinal Computational Dynamics establishes computational behavior across time as a scientific domain.

• Longitudinal Computational Behavior identifies the developing runtime trajectory as its primary empirical object.

• Chronodynamics defines the clocks, ordering relations, markers, and temporal transformations through which that trajectory unfolds.

• Drift Dynamics measures movement relative to declared semantic, objective, role, tool-state, temporal, and stability references.

• Computational Behavior Architecture specifies the objects, relationships, contracts, and authority structures required to represent and investigate the resulting runtime.

The architecture connects source records, canonical reconstruction, temporal organization, behavioral measurement, scientific instrumentation, guided investigation, claim governance, replay, and preservation under one evidence authority.

Its central question is architectural: how can recorded computational activity become a defensible account of behavior through time without severing findings from the sources, methods, uncertainties, and limits that authorize them?

Computational Behavior Architecture does not describe the internal construction of a model. It does not replace transformer mechanics, mechanistic interpretability, software observability, evaluation, security telemetry, or operational monitoring. It provides the structural layer through which externally observable runtime activity can be organized into a source-bound and inspectable behavioral reconstruction.

Foundational Architecture Page · September 2026 · Version 1.0

From Dynamics to Architecture

The earlier foundations establish that runtime behavior has temporal structure and measurable motion.

A runtime does not develop through elapsed time alone. Its events are ordered through source time, normalized clock time, turn order, event order, dependency order, and symbolic time. Within those coordinates, the trajectory may preserve its organization, change reference, accumulate displacement, approach a boundary, transition between regimes, collapse, or recover.

Those scientific constructs require a computational structure capable of representing them without collapsing their differences.

Chronology cannot substitute for dependency. A distance score cannot identify its own reference. A regime label cannot establish its persistence. A boundary marker cannot authorize a failure claim. A visual narrative cannot replace source evidence.

Computational Behavior Architecture therefore defines how the elements of a runtime remain distinct while becoming investigable as one system.

The science defines what must be observed and measured. The architecture defines how those observations, measurements, findings, and claims remain coherently connected.

The Architectural Problem

Computational systems increasingly operate through extended, history-bearing processes rather than isolated requests.

Models participate in conversations. Agents plan, act, use tools, receive results, revise their approach, and hand work to other agents or people. Retrieval systems reintroduce earlier material. External services change the operational state. Human decisions alter objectives, permissions, and constraints. Consequences may emerge many events after the activity that helped form them.

Conventional monitoring can record many of these events. Evaluation can score selected outputs. Tracing can expose execution paths. Model analysis can examine parameters, activations, or internal representations when privileged access is available.

Each provides useful information. None automatically reconstructs how observable behavior developed across the complete runtime.

• A log may preserve events without establishing their evidentiary authority.

• A trace may show execution order without reconstructing behavioral development.

• A metric may display change without declaring its reference or coordinate system.

• An instrument may classify a condition without exposing the method that produced it.

• A report may retain a conclusion while losing the source spans that supported it.

• An interface may change the apparent account when it adapts to a new audience or operational domain.

Computational Behavior Architecture treats these as one connected systems problem.

It is the architecture through which recorded activity becomes a canonical runtime, the runtime becomes a measurable trajectory, and the trajectory becomes a bounded body of evidence.

The Complete Computational Runtime

The object requiring reconstruction is not the model alone.

A long-horizon runtime may distribute state and influence across:

• model context;

• prompts and responses;

• external memory;

• retrieval systems;

• tool calls and results;

• workflow and orchestration state;

• agent handoffs;

• role assignments;

• human decisions and corrections;

• permissions and authority;

• environmental events;

• system-generated summaries;

• and preserved operational artifacts.

An individual model call may retain no persistent internal memory while the wider runtime remains history-bearing. Earlier activity can re-enter later computation through context, memory, tools, workflow state, and the actions of other participants.

This operational re-entry creates path dependence. Later behavior may reflect not only the current input but also the accumulated conditions carried forward by the runtime.

Runtime Intelligence names the organized behavior expressed through this process. It does not imply consciousness, subjective experience, intent, or an enduring internal self. It identifies a level of analysis: how available capability becomes organized through a particular operation and interaction history.

Computational Behavior Architecture makes that level representable without claiming access to internal mechanisms the record does not contain.

The Unit of Reconstruction

An output is an event.

A runtime trajectory is an ordered relationship among events.

The trajectory makes it possible to investigate whether:

• constraints persisted;

• corrections held;

• objectives remained stable or were legitimately revised;

• roles maintained continuity;

• tool states were integrated;

• contradictions recurred;

• drift accumulated or receded;

• pressure became coupled across dimensions;

• regimes persisted or changed;

• boundaries formed or were crossed;

• failure became observable;

• and recovery continued beyond one corrected response.

The architecture therefore changes the principal unit of analysis from the isolated response to the complete computational runtime.

Its canonical longitudinal representation is the worldline: an evidence-bound, time-indexed reconstruction of events, roles, dependencies, measurements, regimes, markers, transitions, and supported outcomes across a run.

A worldline is not a direct observation of hidden model state. It is not the runtime itself, and it is not a complete causal history. It is a reconstruction produced from qualified operational records under a declared method.

Its authority depends on:

• source coverage and provenance;

• event and role identity;

• temporal and dependency ordering;

• transformation methods;

• evidence availability;

• measurement and marker status;

• uncertainty and conflict;

• and explicit claim boundaries.

Formation, drift, transition, collapse, and recovery consequently become relationships that must be demonstrated across a trajectory—not labels attached to an isolated outcome.

The Governing Invariants

Computational Behavior Architecture is organized around several invariants.

Source Precedence

The originating record remains distinguishable from every observation, transformation, measurement, finding, interpretation, and export derived from it.

One Runtime Identity

All components refer to the same qualified run, canonical event identities, temporal coordinates, and evidence scope.

One Evidence Authority

Measurements, instruments, investigative views, summaries, and exports derive their authority from the same Current Evidence Run.
No surface may create an independent history of what occurred.

Typed Evidentiary Status

Source-observed, operator-declared, evaluator-supplied, computed, inferred, reviewed, conflicting, missing, and unavailable information remain distinguishable.

Deterministic Transformation

The same qualified source, method, configuration, and software version should reproduce the same governed computational core within its stated tolerance.

Non-Mutation by Presentation

Operational language, interface layout, visualization, sampling, and guided investigation may change how evidence is encountered.
They may not rewrite the underlying evidence.

Bounded Claims

No conclusion may exceed the authority of its source, method, support state, evidence horizon, or declared claim boundary.

Preserved Missingness

Unavailable evidence remains unavailable. The architecture does not convert absence into an inferred fact merely to complete a visualization or narrative.

Traceable Derivation

Every governed finding must remain traversable to the measurement, runtime coordinates, source spans, method, and evidence status that support it.
These invariants are not interface preferences. They are the conditions that allow a complex runtime reconstruction to remain internally coherent and externally challengeable.

The Architectural Lifecycle

Computational Behavior Architecture organizes evidence formation through nine connected layers.
Each layer performs a different operation. None may silently assume the authority of another.

01. Source Acquisition and Preservation

The architecture begins with operational records, not with an interpretation.

Sources may include:

• transcripts;

• agent traces;

• model interaction records;

• tool events;

• workflow histories;

• software and infrastructure logs;

• security records;

• service tickets;

• incident records;

• human annotations;

• and operator-supplied context.

The source is identified, retained, and associated with integrity information where available. Original content remains distinguishable from normalized or canonical representations.

At this stage, the material is a captured operational record. It is not yet Runtime Evidence.

02. Source-Family Detection and Qualification

Preflight qualification determines what the record contains and what it can support.

It examines:

• source family and format;

• event structure;

• available timestamps;

• ordering information;

• participants and role labels;

• tool and workflow fields;

• source coverage;

• duplicate or malformed events;

• optional evidence channels;

• missing and conflicting information;

• operator-declared context;

• and processing limits.

Qualification prevents absent information from being silently reconstructed as fact. It also establishes which fields can be treated as source-observed and which require transformation or interpretation.

03. Role-Aware Canonicalization and Transformation Provenance

Qualified source material is converted into canonical runtime units through a declared adapter and transformation path.

Canonicalization assigns stable identities to supported events, participants, roles, tool actions, dependencies, source spans, and temporal coordinates. Adapter provenance records how source-specific structures became canonical objects.

The architecture preserves:

• original source references;

• adapter and schema versions;

• normalization rules;

• role mappings;

• exclusions and repairs;

• ordering decisions;

• confidence and conflict states;

• and source-to-canonical mappings.

Canonicalization does not overwrite the source. It establishes a common representation through which the run can be computed consistently.

04. Current Evidence Run Establishment

Once the source is qualified, the architecture establishes a Current Evidence Run as the governing evidence context for the computation.

The Current Evidence Run begins with source identity, qualification state, processing configuration, evidence availability, and declared authority. It is progressively populated by the canonical runtime, measurements, markers, instrument models, findings, investigation state, and export-ready evidence structures.

It governs which evidence is eligible for the current computation. It does not own truth or certify that every resulting interpretation is scientifically valid.

The Current Evidence Run is the active authority for the investigation. It remains distinct from the sealed or preserved evidence record produced at the end of the governed lifecycle.

Every downstream component must read from and remain bound to this shared authority.

05. Canonical Runtime Construction

The architecture reconstructs the qualified run through shared runtime objects, which may include:

• the runtime event ledger;

• canonical runtime spine;

• ordered playback frames;

• source-to-frame mappings;

• role and interaction topology;

• tool and workflow relationships;

• temporal coordinates;

• dependency structures;

• runtime events and forensic markers;

• regime intervals;

• and replay references.

The runtime spine provides the common longitudinal axis. Playback frames expose the eligible state of the reconstruction at defined coordinates. The event ledger preserves the events and relationships from which the trajectory is formed.

Canonical construction prevents each instrument from reparsing the source and creating a different chronology, role structure, or event identity.

06. Measurement and Instrument Binding

The measurement layer computes defined temporal, behavioral, interaction, drift, pressure, and stability quantities from the Current Evidence Run.

Each measurement must declare:

• eligible evidence inputs;

• operational definition;

• reference condition where required;

• coordinate domain and resolution;

• comparison and persistence windows;

• transformation method;

• parameter and software versions;

• availability conditions;

• uncertainty and missingness behavior;

• validation status;

• and permitted interpretation.

Scientific instruments do not operate as independent analyzers. Each instrument receives a governed Instrument Model derived from the shared evidence authority, canonical metrics, markers, runtime spine, scientific registry, and instrument contract.

This allows multiple instruments to expose different dimensions of one runtime without producing competing versions of it.

07. Evaluation, Synthesis, and Human Read

Measurements become findings only through declared evaluation rules.

Evaluation determines whether persistence, threshold, comparison, or support conditions have been met. Synthesis relates compatible findings without erasing their distinct authority or uncertainty. Human Read presents an evidence-bound interpretive layer through which an investigator can understand the run without treating interpretive synthesis as a substitute for the record.

The architecture preserves the difference among:

• direct observation;

• computed measurement;

• classified condition;

• instrument projection;

• synthesized finding;

• operator interpretation;

• and admissible claim.

A reviewed interpretation may gain a new review status, but review does not transform it into raw source evidence.

08. Guided Investigation, Replay, and Adaptive Presentation

Investigation requires more than visualization.

Operators need to know:

• which questions the evidence can answer;

• which findings require direct inspection;

• which frames and source events support a transition;

• where evidence is incomplete or conflicting;

• and where interpretation must stop.

The Runtime Blackbox forms and maintains the source-bound evidence record. The Flight Recorder makes the reconstructed runtime navigable and replayable. Guided Investigation organizes the operator’s path through chapters, questions, findings, and source trails.

Operational World Mapping translates between domain-specific language and the canonical runtime. Morphic UX and the Adaptive Evidence Cockpit adjust the investigative environment to the run, evidence state, and operator context.

These layers may change emphasis, terminology, navigation, and presentation. They are not permitted to alter the source, canonical runtime, measurement, marker authority, or claim boundary.

An investigator should be able to traverse:

Claim → Finding → Instrument projection → Measurement → Runtime frame → Recorded event → Source record

This makes disagreement inspectable rather than allowing it to disappear behind a dashboard or summary.

0.9 Passport, Ledger, Sealing, Export, and Preservation

The Runtime Evidence Passport identifies the evidence record and makes its formation, integrity, disclosure state, and permitted interpretive scope inspectable.

The persistent evidence ledger records material formation and status events across the run. When preservation requirements are met, the resulting Certified Runtime Evidence Record can be sealed and exported with the information required to examine its lineage.

Certification in this context concerns declared evidence formation, computational integrity, and preservation status. It does not certify objective truth, hidden causation, or the universal validity of every scientific construct.

A preservation-ready artifact should retain sufficient information to identify:

• source identity and integrity references;

• qualification and disclosure state;

• canonical reconstruction;

• processing configuration;

• adapter, schema, method, and software versions;

• measurements and temporal markers;

• instrument findings;

• evidence status and missingness;

• review and interpretation state;

• claim boundaries;

• investigative lineage;

• and replay requirements.

Evidence loses authority when it is reduced to a screenshot or separated from its provenance.

Evidence is formed and preserved first. Presentation adapts second.

One Evidence Authority Across the System

The architecture preserves an essential separation:

• the source is not the canonical reconstruction;

• the reconstruction is not the measurement;

• the measurement is not the finding;

• the finding is not the claim;

• and the claim is not the operator’s interpretation.

These objects are connected, but they do not possess the same authority.

Without this separation, an analytical system can become internally incoherent. One instrument may place a transition at one event while another uses a different chronology. A report may declare failure even though the record contains no qualified failure marker. A domain-specific interface may rename a condition and inadvertently change its meaning. An export may retain the conclusion but omit the evidence that authorized it.

Computational Behavior Architecture addresses this through one governing principle:

One Runtime. One Evidence Authority. Multiple Bounded Scientific Projections.

Instruments may provide different views of the same runtime. They may not create competing histories, rewrite source conditions, or promote unsupported findings into authoritative facts.

This is the structural foundation of Evidence-Governed Computation™.

The Instrument Contract

Every scientific instrument operates through an explicit contract.

The contract identifies:

• the Current Evidence Run from which the instrument reads;

• required and optional evidence inputs;

• measurement and marker dependencies;

• computational methods and versions;

• projection logic;

• availability and no-signal conditions;

• uncertainty and disclosure requirements;

• permitted findings;

• prohibited interpretations;

• and export behavior.

An instrument may render No Signal, Unavailable, Unsupported, or Not Computed when its requirements are not met. These are valid evidentiary states, not interface failures.

The contract prevents an instrument from manufacturing authority simply because the interface expects a value. It also makes cross-instrument consistency testable: instruments reading the same governed objects must remain logically and numerically compatible with the shared runtime.

Deterministic Evidence Artifacts

Reproducibility begins with deterministic transformation.

Given the same:

• qualified source;

• canonicalization rules;

• adapter and schema versions;

• configuration;

• measurement methods;

• parameters and thresholds;

• evidence horizon;

• and software version,

the architecture should reproduce the same governed evidence core within its declared tolerance.

Hashes, manifests, version identifiers, provenance records, and integrity references make that consistency inspectable. They also reveal when a result changed because its source, configuration, method, or software changed.

Determinism is necessary for replay and conformance. It is not scientific validation.

A repeatable calculation may still measure the wrong construct. A deterministic regime classification may rely on poorly calibrated thresholds. A reproducible reconstruction may be based on an incomplete source.

Scientific validation requires:

• calibration;

• stable negative cases;

• null and baseline comparison;

• controlled perturbation;

• held-out evaluation;

• ablation;

• sensitivity analysis;

• prospective testing;

• cross-system comparison;

• and independent replication.

The architecture makes methods and claims executable, inspectable, and testable. It does not certify its own truth.

Temporal and Marker Authority

Computational Behavior Architecture carries the temporal requirements of Chronodynamics into every reconstruction and instrument.

Runtime behavior may be represented through:

• source time;

• normalized clock time;

• turn order;

• event order;

• dependency order;

• and symbolic time.

Every temporal claim must identify the coordinate it uses and the evidence horizon available at the point of computation.

The architecture also preserves distinct marker classes:

• t_aw — weakening or awareness marker;

• t_candidate — candidate boundary;

• t* — qualifying observable boundary crossing;

• tf — independently supplied or qualified observable failure marker;

• and the recovery marker — sustained re-entry or reorganization under declared criteria.

These markers cannot be collapsed into a single “instability onset.” A candidate boundary is not a confirmed crossing. A crossing is not automatically a failure. A failure label is not automatically ground truth. A corrected response is not sustained recovery.

Prospective claims require prefix invariance: a measurement presented as available at a particular point may use only the evidence available at that point. Later events cannot be used to make an earlier signal appear predictive.

Formal Lead-Time is available only when both t* and tf exist and satisfy the declared authority requirements. Otherwise, the architecture may report a candidate interval, warning window, or post-exit observation period. It may not invent an outcome marker.

Role and Interaction Architecture

Long-horizon behavior is frequently co-produced by multiple participants.

These may include:

• people;

• models;

• agents;

• tools;

• policies;

• evaluators;

• services;

• and operational systems.

Authority may transfer. Objectives may fragment. A correction introduced by one role may be weakened by another. Tool outputs may redirect the runtime. A workflow may preserve an error long after the event in which it originated.

Computational Behavior Architecture preserves role provenance and interaction topology alongside behavioral signals.

Role-aware reconstruction can support findings about:

• handoff continuity;

• role-boundary change;

• authority transfer;

• correction uptake;

• tool-state integration;

• phase lag among participants;

• cross-role propagation;

• and interaction shear.

It does not automatically establish hidden intent, responsibility, blame, identity, or unique causation. Where participant or role provenance is unavailable, attribution remains unavailable.

From Observability to Runtime Evidence

Observability and Runtime Evidence serve different purposes.

Observability helps operators determine what a system is doing. Runtime Evidence asks what the available record can support after source qualification, reconstruction, measurement, and claim governance.

Logs do not become evidence merely because they exist. Their provenance, structure, completeness, ordering, semantics, transformation history, and missingness must remain inspectable.

Computational Behavior Architecture preserves the chain:

Source → Observation → Canonical runtime → Measurement → Finding → Admissible claim → Projection → Export and preservation

An admissible claim is one permitted under the declared evidence rules. Admissibility does not prove that the claim is objectively true.

This architecture allows:

• researchers to reproduce and challenge a trajectory;

• operators to inspect how an incident developed;

• engineers to compare behavior across declared conditions;

• auditors to traverse from a conclusion back to its source;

• and institutions to preserve an evidence artifact without relying exclusively on the system provider’s explanation of what occurred.

SubstrateX Aperture™ as the Operational Expression

SubstrateX Aperture™ is the principal operational expression of Computational Behavior Architecture.

It brings together:

• source acquisition and qualification;

• source-family detection;

• role-aware ingestion;

• adapter and transformation provenance;

• canonical runtime construction;

• the Current Evidence Run;

• worldline and runtime-spine formation;

• deterministic behavioral telemetry;

• temporal and stability markers;

• nine scientific instruments;

• Runtime Blackbox reconstruction;

• Flight Recorder replay;

• evaluation, synthesis, and Human Read;

• Guided Investigation;

• Operational World Mapping;

• Morphic UX and the Adaptive Evidence Cockpit;

• Runtime Evidence Passports;

• evidence-ledger formation;

• sealing and export;

• and preservation-ready evidence artifacts.

Users may begin with guided operational samples, known validation cases, or their own supported records. Every path preserves the distinction among raw source, canonical runtime, evidence authority, instrument projection, and operator interpretation.

Operational Worlds adapt intake guidance, investigative language, examples, and emphasis. They do not change the underlying telemetry, canonical runtime, or deterministic evidence path.

SubstrateX Aperture therefore serves two connected roles:

• a working Runtime Evidence Observatory for reconstructing and investigating long-horizon computational behavior;

• and an experimental environment through which the scientific constructs of Longitudinal Computational Dynamics can be executed, tested, challenged, and refined.

Implementation closes the experimental loop. It does not convert implementation into proof.

Generality and Domain Boundaries

Computational Behavior Architecture is model-agnostic in its access requirements because it operates from observable operational records rather than requiring model weights, activations, gradients, private chain-of-thought, or hidden states.

The architecture may support sufficiently ordered records from:

• model-to-model interaction;

• human–machine workflows;

• agent and tool systems;

• multi-role operational processes;

• software and infrastructure events;

• security and incident workflows;

• and other history-bearing computational systems.

Architectural portability does not establish measurement validity across every domain.

A signal calibrated for an AI workflow cannot automatically be treated as a valid measure of human, organizational, animal, or biological behavior. Different systems require domain-appropriate constructs, baselines, ethics, calibration, external anchors, and independent validation.

The architecture may transfer. The meaning of a measurement must still be earned within its domain.

Claim Boundary

Computational Behavior Architecture can establish a structured and reproducible relationship among qualified operational records, canonical runtime objects, measurements, findings, and bounded claims.

It does not, from observable records alone:

• expose hidden model state;

• recover private reasoning;

• prove consciousness, intent, or subjective identity;

• establish unique causation from temporal order;

• certify that a source record is complete or authentic without supporting evidence;

• validate every measurement merely because it is deterministic;

• convert an instrument projection into ground truth;

• assign responsibility or blame;

• or guarantee that a finding generalizes beyond the conditions under which it was produced.

Its authority is architectural and evidentiary: it specifies how supported claims remain connected to their source, method, status, and limits.

The Foundational Contribution

Computational Behavior Architecture establishes the continuous structural relationship between operational records and defensible accounts of behavior through time.

Its distinctive contribution is not any one metric, interface, or instrument. It is the integration of:

• source qualification;

• canonical runtime identity;

• temporal and dependency structure;

• longitudinal behavioral reconstruction;

• drift, regime, role, and stability analysis;

• shared evidence authority;

• instrument contracts;

• bounded findings;

• guided investigation;

• adaptive presentation without evidence mutation;

• deterministic artifact formation;

• replay;

• and preservation.

These capabilities remain governed by the same source-bound evidence object.

The complete progression can be stated precisely:

Longitudinal Computational Dynamics defines the scientific domain.
Longitudinal Computational Behavior is its primary empirical object.
Chronodynamics defines the temporal structure of the trajectory.
Drift Dynamics measures its reference-relative motion.
Computational Behavior Architecture makes the runtime representable and investigable.
Runtime Evidence binds the reconstruction to its source and authority.
Evidence-Governed Computation™ constrains what may be claimed.
SubstrateX Aperture™ makes the complete architecture operational.

Its scientific value must be established through validation, falsification, and independent replication. Its architectural contribution is already concrete: it defines how computational behavior can become observable, measurable, reconstructable, challengeable, and preservable without separating conclusions from the evidence that supports them.