An Evidence-Governed Architecture for Runtime Intelligence

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

It connects source records, temporal measurement, behavioral analysis, investigation, and preservation under one evidence authority.

The architecture does not describe the internal construction of a model or attempt to replace transformer mechanics, mechanistic interpretability, software observability, or operational monitoring. It addresses a different question:

How can recorded computational activity be transformed into a defensible account of behavior across time?

Computational Behavior Architecture provides the structural bridge between Recursive Science and Runtime Evidence. Recursive Science defines why runtime behavior should be studied. Computational Behavior Architecture specifies how that behavior can be represented and investigated. Runtime Evidence determines how the resulting reconstruction becomes inspectable, reproducible, challengeable, and preservable.

Research Article · September 2026

The Architectural Problem

Computational systems increasingly operate through extended sequences rather than isolated requests.

Models respond across many turns. Agents plan, use tools, receive results, revise their approach, and interact with people or other systems. Operational outcomes emerge from the order and accumulation of these events.

Conventional monitoring records many individual events. Evaluation systems score selected outputs. Model analysis examines parameters, activations, or internal representations when access is available.

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

A log may record what occurred without establishing how its events relate.

A chart may display a metric without identifying the evidence that authorized it.

An instrument may assign a label without exposing the transformation that produced it.

An investigation may reach a plausible conclusion without preserving the limits of what the record supports.

Computational Behavior Architecture treats these as one connected systems problem.

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

From Computation to Runtime Behavior

Training establishes a model’s learned parameters, representations, capabilities, and constraints. During inference, those resources interact with active context, transient computational state, decoding policy, retrieval, external tools, memory, and orchestration.

The resulting response is produced through an ordered process in which earlier activity influences what follows.

This recursive relationship also operates across larger scales:

• a response becomes part of the next interaction;

• a tool result changes the next available action;

• a correction redirects the trajectory or fails to persist;

• a memory entry alters later context;

• a handoff preserves or weakens an objective;

• and role interactions introduce new constraints or competing interpretations.

The model’s learned parameters may remain fixed while the runtime becomes path dependent.

Runtime Intelligence names the organized behavior expressed through this process. It does not imply that capability appears independently of training or that a model possesses consciousness or an enduring internal self. It identifies a level of observation: the context-conditioned organization of behavior across time.

Computational Behavior Architecture makes that level available for systematic reconstruction and investigation.

The Unit of Investigation

An output is an event.

A runtime trajectory is an ordered relationship among events.

The trajectory reveals whether:

• constraints persisted;

• corrections held;

• objectives remained stable;

• roles maintained continuity;

• contradictions recurred;

• pressure accumulated;

• boundaries formed;

• or recovery continued beyond one corrected response.

The architecture therefore changes the principal unit of analysis from the individual response to the runtime.

Recursive Science represents this development through an evidence-bound worldline: an ordered reconstruction of events, roles, signals, regimes, and transitions across a run.

A worldline is not a direct observation of hidden model state. It is a representation reconstructed from the available operational record. Its authority depends on source coverage, qualification, temporal ordering, and the declared method used to produce it.

Formation, transition, failure, and recovery consequently become temporal questions rather than labels applied after an outcome.

The Core Architecture

Computational Behavior Architecture separates seven layers. Each has a distinct function, but all remain connected to the same evidence authority.

1. Source Evidence

The architecture begins with the record—not with an interpretation.

Source material may include:

• transcripts;

• agent traces;

• tool events;

• workflow histories;

• service tickets;

• software logs;

• security records;

• infrastructure events;

• incident records;

• and operator-supplied context.

The original source must remain distinguishable from every transformation performed after acquisition.

2. Source Qualification

Qualification determines what the record actually contains.

It identifies:

• event structure;

• timestamps and ordering;

• participants and role labels;

• available fields;

• missing information;

• optional evidence channels;

• operator-declared context;

• and coverage limitations.

This prevents absent information from being silently reconstructed as fact. It also preserves the distinction among source-observed, computed, inferred, and operator-supplied information.

3. Runtime Reconstruction

Qualified events are transformed into a canonical runtime representation.

This may include:

• an event ledger;

• canonical runtime spine;

• ordered frames;

• role topology;

• temporal coordinates;

• authoritative markers;

• source-to-frame mappings;

• and replay references.

Canonicalization prevents every instrument from parsing the source independently and creating a different version of the run.

The original source remains available for inspection. Analysis proceeds from a versioned reconstruction that establishes shared event identities, coordinates, and observational boundaries.

4. Runtime Measurement

The measurement layer computes defined temporal, behavioral, interaction, stability, and pressure signals from the canonical runtime.

Each signal must declare:

• its eligible evidence;

• operational definition;

• coordinate domain;

• computational method;

• availability conditions;

• uncertainty;

• and permitted interpretation.

A value does not become scientifically meaningful merely because it appears on a dashboard.

The architecture must preserve the difference among a computed quantity, a calibrated measurement, a classified condition, and an interpretation derived from it.

5. Evidence Authority

The evidence object is the governing center of the architecture.

It binds the run’s:

• source identity;

• canonical reconstruction;

• computations and versions;

• temporal markers;

• signal authority;

• instrument findings;

• provenance;

• integrity state;

• disclosures;

• and claim boundaries.

The Runtime Evidence Passport provides the identity through which these elements remain connected. It does not certify that every finding is true. It establishes which runtime is being examined, what evidence was supplied, what remained absent, and which methods and versions produced the record.

Evidence authority prevents dashboards, instruments, summaries, and exports from becoming independent sources of truth.

6. Investigation and Replay

Investigation requires more than visualization.

Operators need to know:

• which questions the evidence can answer;

• which findings require direct inspection;

• which source events support a transition;

• where uncertainty remains;

• and where interpretation must stop.

Guided investigation connects worldline formation, role dynamics, regime transitions, failure development, recovery, and evidence formation to their supporting frames and source events.

Replay preserves the relationship between the analytical view and the canonical event sequence.

An investigator can move from:

Claim
↓
Instrument Finding
↓
Measurement
↓
Runtime Frame
↓
Recorded Event
↓
Source Evidence

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

7. Preservation

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

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

• the source;

• canonical reconstruction;

• relevant computations;

• method and schema versions;

• instrument findings;

• evidence status;

• disclosures;

• claim boundaries;

• and investigative lineage.

Presentation may adapt to the size of a run. Large records may require sampled visualization or progressive replay. The underlying evidence should not be silently truncated merely to satisfy interface constraints.

Evidence is computed and preserved first. Presentation adapts second.

One Evidence Authority

The architecture preserves an essential separation:

• the source is not the reconstruction;

• the reconstruction is not the measurement;

• the measurement is not the claim;

• the claim is not the operator’s interpretation.

These objects are related, 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 anchor. A visualization may alter its labels when the operational lens changes. 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 or promote unsupported findings into authoritative facts.

This principle becomes the foundation of Evidence-Governed Computation.

Deterministic Evidence Artifacts

Reproducibility begins with deterministic transformation.

Given the same qualified source, configuration, parser, computation version, and method, the architecture should produce the same deterministic evidence core.

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

Determinism is necessary, but it is not scientific validation.

A repeatable calculation may still measure the wrong construct. Validation requires evidence that signals correspond to the behavioral properties they claim to represent.

That requires:

• calibration;

• null and baseline comparison;

• controlled perturbation;

• held-out evaluation;

• ablation;

• sensitivity analysis;

• prospective testing;

• cross-system comparison;

• and independent replication.

The architecture makes scientific claims executable. It does not certify its own scientific truth.

Temporal Authority and Lead Time

Runtime behavior may be measured through several temporal coordinates:

• wall-clock time;

• event order;

• turn order;

• dependency order;

• and symbolic time.

Every temporal claim must identify which coordinate it uses.

Prospective claims require additional protection. An earlier marker must be calculated only from evidence available at that point in the runtime. Later events cannot be used to make an earlier measurement appear predictive.

Formal lead time requires two independently qualified anchors:

• an earlier confirmed boundary;

• and a later observable failure.

If no failure anchor exists, the architecture may report a candidate boundary, inspection window, or post-exit observation. It cannot manufacture formal lead time.

Role and Interaction Architecture

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

These may include:

• people;

• models;

• agents;

• tools;

• policies;

• evaluators;

• 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 or amplify an existing loop.

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

Role analysis does not establish hidden intent, identity, blame, or responsibility. It shows how recorded participants and exchanges relate to the evolving runtime.

From Observability to Runtime Evidence

Logs do not become evidence merely because they exist.

Their provenance, structure, completeness, ordering, semantics, and transformations must be established.

Computational Behavior Architecture preserves the chain:

Source
↓
Qualification
↓
Canonical Reconstruction
↓
Measurement
↓
Authorized Finding
↓
Investigation
↓
Preservation

This transforms operational records into a potential basis for scientific and forensic inquiry.

Researchers can reproduce a trajectory. Operators can inspect how an incident developed. Auditors can challenge the relationship between a claim and its source. Institutions can preserve an artifact without relying exclusively on the system provider’s explanation of what occurred.

Fieldglass® as the Operational Architecture

Fieldglass is the principal implementation of Computational Behavior Architecture.

Developed through the effort to test and instrument Recursive Science, it brings together:

• source qualification;

• role-aware ingestion;

• canonical runtime reconstruction;

• worldline formation;

• behavioral and temporal signals;

• scientific instruments;

• runtime replay;

• guided investigation;

• Runtime Evidence Passports;

• and evidence preservation.

Users can begin with guided operational samples, examine known validation cases, or introduce their own records. Each path keeps the raw source, canonical runtime, evidence object, instrument projections, and operator interpretation distinct.

Operational Worlds adjust examples, intake guidance, investigative language, and operator emphasis. They do not alter the deterministic evidence path or create a different runtime.

Fieldglass therefore serves two roles:

• a working Runtime Evidence Observatory;

• and an experimental architecture through which scientific constructs can be executed, tested, challenged, and refined.

It does not contain all of Recursive Science. It externalizes a substantial part of the research as a working reconstruction, measurement, investigation, and evidence system.

Generality and Domain Boundaries

Computational Behavior Architecture is model-agnostic because its primary object is the observable runtime record.

The architecture may support:

• model-to-model interaction;

• human–machine workflows;

• agent and tool systems;

• multi-role operational processes;

• software and infrastructure events;

• and other recursive systems that produce sufficiently ordered evidence.

Architectural portability does not establish measurement validity across every domain.

A signal calibrated for an AI incident workflow cannot automatically be treated as a valid measure of human, organizational, animal, or biological behavior. Each domain requires appropriate constructs, baselines, ethics, calibration, and independent validation.

The architecture may transfer.

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

The Research Contribution

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

Its central contribution is architectural coherence:

• reconstruction;

• temporal measurement;

• behavioral and regime analysis;

• role topology;

• instrument projection;

• investigation;

• claim authority;

• deterministic evidence formation;

• replay;

• and preservation

remain governed by the same source-bound evidence object.

It gives Runtime Intelligence a longitudinal unit of investigation, gives Runtime Evidence a canonical computational structure, and gives Evidence-Governed Computation an operational foundation.

Recursive Science explains why runtime behavior must be studied. Computational Behavior Architecture defines how it can be represented and investigated.

Its scientific value must be established through validation and replication. Its architectural value is already concrete: it specifies how behavioral findings can remain connected to the records, methods, authorities, and limits that produced them.