Evidence Authority, Claim Admissibility, and Bounded Computational Projection

Computational systems increasingly transform records into measurements, classifications, visualizations, explanations, alerts, recommendations, and preserved reports. These outputs can appear authoritative even when their supporting evidence is incomplete, difficult to inspect, or disconnected from the surface presenting them.

Evidence-Governed Computation establishes the architectural discipline required to prevent computational capability from being mistaken for evidentiary authority.

It follows directly from the preceding foundations:

• 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 temporal structure and marker authority.

• Drift Dynamics measures reference-relative runtime motion.

• Computational Behavior Architecture makes the complete runtime representable and investigable.

• Runtime Evidence establishes what the source-bound reconstruction can legitimately support.

• Evidence-Governed Computation™ constrains what the system may compute, present, preserve, recommend, or export as an authoritative claim.

A computational system is evidence-governed when every authoritative output derives from an identified evidence object through declared methods, remains within an executable claim boundary, and preserves sufficient lineage for independent inspection and challenge.

Its governing law is:

No claim should exceed the authority of its evidence.

Foundational Architecture Page · September 2026 · Version 1.0

From Runtime Evidence to Computational Authority

Runtime Evidence defines the evidence object and discipline. It establishes how operational records become source-bound, longitudinal, reproducible, inspectable, and preservable reconstructions.

Evidence-Governed Computation defines what the rest of the system may do with that evidence.

The distinction is foundational:

Runtime Evidence establishes what the record supports.
Evidence-Governed Computation governs what the system may claim or emit from that support.

Conventional computation asks:

Can this result be produced?

Evidence-governed computation also asks:

Does the Current Evidence Run authorize this result to be computed, classified, presented, preserved, recommended, or exported as authoritative in this form?

The first question concerns technical execution. The second concerns evidentiary legitimacy.

The Constitutional Gap

A computational system can execute correctly and still produce an unsupported claim.

A classifier may apply its threshold exactly even though a required input is missing. A chart may display an accurate association while its title implies causation. An explanation may begin with supported findings and then introduce intent, responsibility, or root cause. An export may retain conclusions while omitting the sources, methods, uncertainties, and limitations needed to evaluate them.

This is the constitutional gap: the difference between what a system is technically capable of producing and what it is legitimately authorized to assert from the available evidence.

The gap widens as systems become modular. Separate components may calculate metrics, assign labels, generate summaries, issue alerts, recommend actions, and create reports. Each component may develop its own terminology, thresholds, fallback logic, and assumptions.

Without a common evidence authority, the system becomes a federation of local interpretations.

One panel may identify a boundary at a particular event while another assigns it elsewhere. One report may call a condition “failure” even though the record contains no qualified failure marker. One interface may silently convert missing evidence into zero. A downstream agent may treat a provisional interpretation as an established fact.

Evidence-Governed Computation makes authority part of the computational architecture itself.

The system must govern not only whether a computation can run, but whether its result may become an authoritative output.

From Evidence to Authoritative Output

Ordinary analytical software is often represented as:

Input → Computation → Output

Evidence-governed systems preserve a more complete relationship:

Current Evidence Run → Declared method → Measurement or finding → Admissible claim → Bounded projection → Governed surface → Preserved artifact

At every stage, the system must be able to answer:

• Which evidence object authorized this output?

• Which source records and derived fields support it?

• Which method and version produced it?

• What class of claim is being made?

• What temporal, operational, and evidentiary scope applies?

• Which assumptions, uncertainties, and conflicts remain?

• What stronger interpretations are prohibited?

• What happens when required evidence is missing?

• Has the result changed through presentation or export?

• Can it be reproduced, challenged, revised, and preserved?

Evidence is not attached after computation to justify a finished conclusion. It is the object from which computational authority is derived.

An authoritative output is any result the system presents as supported under the rules of the governing evidence object. Exploratory calculations may still be possible, but their status must remain explicit and they may not silently enter authoritative surfaces, reports, alerts, recommendations, or exports.

Evidence Authority

Evidence authority is the scoped permission to use an identified evidence object, under a declared contract, to support specified classes of claims.

It is not equivalent to truth.

A source may be incomplete, inaccurate, biased, selectively retained, or incorrectly labeled. A method may be deterministic but scientifically invalid. A claim may satisfy its computational rules while remaining conditional upon assumptions that later prove false.

Evidence-Governed Computation does not eliminate these limitations. It makes them explicit and prevents the system from silently asserting more than its sources and methods permit.

Authority is separated across several layers:

Source Authority

Establishes which material was supplied, preserved, observed, or attested. It does not automatically establish authenticity or completeness.

Method Authority

Establishes which declared procedure may operate on which eligible evidence, under which version and conditions.

Measurement Authority

Establishes what a computation may report about a defined property, coordinate, reference, or interval.

Finding Authority

Establishes whether declared support, persistence, comparison, or classification criteria were satisfied.

Claim Authority

Establishes which proposition the evidence, method, and findings may support—and within which scope.

Presentation Authority

Permits a surface to render an admitted claim without strengthening, weakening, or changing its meaning.

Recommendation Authority

Permits a system to present an evidence-supported option under a declared decision policy.

Execution Authority

Determines whether a person, agent, or automated system may act upon a recommendation.

Preservation and Disclosure Authority

Governs what may be retained, sealed, exported, shared, or disclosed—and under which access conditions.
No lower layer automatically grants a higher one.

A source hash does not authorize a diagnosis. A measurement does not authorize a causal explanation. A supported claim does not automatically authorize a recommendation. A recommendation does not authorize autonomous action.

Claims as Computational Objects

In conventional software, claims often appear only as labels, sentences, scores, or summaries. Their evidentiary status remains implicit.

Evidence-Governed Computation represents the claim itself as a structured object.

A governed claim identifies:

• a stable claim identity;

• its normalized proposition;

• claim class;

• governing Current Evidence Run;

• temporal and operational scope;

• evidence horizon;

• supporting source spans, measurements, and findings;

• method and version;

• assumptions;

• uncertainty and conflict;

• claim boundary;

• prohibited extensions;

• review and challenge state;

• audience and disclosure restrictions where applicable;

• and current status.

This allows different surfaces to express the same claim without changing its meaning.

A chart may state that role fragmentation increased after a particular event. An operator brief may express the same finding in ordinary language. An API may expose the corresponding structured value. All can remain bound to the same claim identity.

If the brief changes the statement to role fragmentation caused the failure, it has introduced a stronger claim. That claim requires separate evidence, a different method, and independent authorization.

Fluent language, numerical precision, and visual confidence cannot create evidentiary authority.

Claim Admissibility

Claim admissibility is the rule-governed determination that a proposed claim may be produced as authoritative under the Current Evidence Run.

Admissibility may depend on:

• eligible source coverage;

• evidence class;

• method and version;

• reference authority;

• coordinate and temporal scope;

• persistence requirements;

• uncertainty bounds;

• marker status;

• validation status;

• audience and disclosure rules;

• and prohibited interpretations.

An admissibility decision does not establish objective truth. It establishes that the claim satisfies the declared conditions under which the system is permitted to assert it.

The distinction is precise:

Evidence supports. Methods transform. Rules admit. Surfaces project. People and institutions remain responsible for judgment and action.

Executable Claim Boundaries

A claim boundary specifies what a system may and may not conclude.

It can restrict:

• temporal scope;

• operational, system, or population scope;

• evidence class;

• method and validation status;

• uncertainty;

• causal interpretation;

• hidden-state inference;

• identity or intent attribution;

• audience;

• recommendation;

• execution;

• export;

• and disclosure.

A boundary is executable when the system enforces it before an output becomes authoritative.

If evidence is absent, the system returns the appropriate absence state. If a method is experimental, its output retains that status. If a record supports association but not causation, no instrument, summary, API, or export may silently cross that boundary.

Under Evidence-Governed Computation, refusing an unsupported conclusion is correct computation.

An operator may add context, dispute a finding, or make a separately authorized judgment. That intervention must remain identified as operator-declared or reviewed information. It cannot silently rewrite the source evidence or elevate a derived claim into a direct observation.

Computation and Instrument Contracts

Every authoritative computation operates under a versioned contract.

A computation contract defines:

• eligible inputs;

• evidence availability requirements;

• canonicalization and ordering rules;

• algorithms, references, thresholds, and dependencies;

• coordinate and window definitions;

• role-resolution and normalization policies;

• deterministic and variable state;

• uncertainty and missingness behavior;

• admissible claim classes;

• prohibited interpretations;

• validation status;

• output and surface requirements;

• and replay, export, and preservation conditions.

Individual scientific instruments operate through bounded instrument contracts. Each instrument must declare:

• what it reads;

• what it computes;

• what it projects;

• which evidence it requires;

• which findings it may produce;

• which claims those findings may support;

• when it must return No Signal or Unavailable;

• and how its results remain bound through export.

An instrument does not gain authority from its name, complexity, apparent precision, or visual appearance.

Its authority comes from its relationship to the Current Evidence Run and active computation contract.

Bounded Computational Projection

A projection is any view, transformation, summary, visualization, interpretation, or domain translation of authorized evidence.

A projection may:

• select;

• aggregate;

• organize;

• translate;

• summarize;

• visualize;

• or contextualize admitted claims.

It may not strengthen them.

This is the principle of projection non-amplification:

A projection may reveal less than the evidence authorizes, but it may never claim more.

Authority can be preserved or reduced as a claim moves downstream. It cannot be increased by presentation alone.

A visualization cannot convert association into cause. A summary cannot convert a candidate boundary into a confirmed crossing. A confirmed crossing cannot become an observed failure without tf. A role label cannot become verified identity. An experimental classifier cannot become a validated diagnosis. The absence of an observed event cannot become proof that it never occurred.

Different instruments and interfaces may present the same evidence differently, but their authoritative content must remain semantically congruent.

Surface Binding

A surface is any location through which a computational claim reaches a person or another system:

• a chart;

• dashboard;

• instrument;

• tooltip;

• operator brief;

• Human Read;

• guided investigation;

• API;

• alert;

• explanation;

• recommendation;

• export;

• or preserved report.

Every authoritative output must retain an inspectable surface binding connecting it to:

• the Current Evidence Run;

• admitted claim identity;

• source and derivation path;

• governing method;

• scope and status;

• uncertainty and missingness;

• relevant version;

• and claim boundary.

A surface has no independent evidentiary authority.

The interface may change how evidence is explored or understood. It cannot become a second authority capable of inventing facts, redefining classifications, removing limitations, or converting unavailable evidence into an apparent result.

Egress Closure

Evidence governance fails if even one output channel can bypass the claim boundary.

Egress closure requires every authoritative path leaving the computational core to pass through the same admissibility and boundary controls.

This includes:

• instruments and dashboards;

• explanations and summaries;

• alerts and notifications;

• APIs and integrations;

• recommendations;

• reports and downloads;

• exports and preserved artifacts;

• downstream agents;

• and automated decision systems.

An unsupported claim cannot become acceptable because it was produced by a different component or transmitted through a less visible channel.

Logging an overreaching conclusion after it has already been issued is not evidence governance. The proposed claim must be evaluated before the system presents, transmits, preserves, or acts upon it as authoritative.

Egress closure also requires that downstream systems receive the status, uncertainty, provenance, and claim boundary—not merely the value or sentence produced upstream.

Governance Is Not Autonomous Decision Authority

Evidence-Governed Computation governs computational assertion. It does not automatically determine what action should follow.

Evidence may support a finding. A declared decision policy may transform that finding into a recommendation. A separate authority structure must determine whether a person or system may act.

This separation matters because action can depend on considerations beyond the evidence object:

• law and regulation;

• institutional policy;

• risk tolerance;

• human values;

• operational constraints;

• affected stakeholders;

• reversibility;

• and consequences of error.

The telemetry layer does not authorize intervention merely because it detects a condition. The evidence layer does not authorize enforcement merely because a claim is admissible.

Evidence can constrain a decision without making the decision.

Decision theory, policy, and control architectures may build upon Evidence-Governed Computation. They must not be collapsed into it.

Challenge and Non-Destructive Revision

Evidence governance does not make conclusions permanent.

New source material may appear. A parser may be corrected. A threshold may change. A measurement may fail validation. An investigator may dispute a role assignment or introduce counterevidence. A policy may change which audiences can receive a claim.

Evidence-Governed Computation preserves these changes without erasing history.

A challenge remains attached to the source, method, claim, projection, or artifact it contests. Revised claims receive distinguishable identities and retain their relationship to previous versions.

The architecture separates:

• source revision — the supplied evidence changed or expanded;

• method revision — an algorithm, threshold, ontology, or dependency changed;

• claim revision — the proposition, scope, support, or status changed;

• policy revision — admissibility, audience, recommendation, action, or disclosure rules changed;

• and presentation revision — wording or interface changed without changing the governed claim.

A disputed claim may become superseded or withdrawn while its earlier state remains available for inspection.

Accountability requires correction without historical erasure.

The Evidence Architecture Framework

Evidence-Governed Computation defines the constitutional rules. The Evidence Architecture Framework defines how those rules are implemented in software.

The framework separates five functional planes.

1. Evidence Plane

Preserves source identity, qualification, canonical runtime objects, provenance, evidence states, missingness, integrity references, and the Current Evidence Run.

2. Computation Plane

Applies versioned methods, measurement contracts, instrument contracts, temporal rules, evaluation criteria, and deterministic transformations to eligible evidence.

3. Authority Plane

Evaluates claim class, admissibility, status, scope, uncertainty, prohibition, audience, recommendation, revision, and disclosure.

4. Projection and Egress Plane

Exposes bounded claims through instruments, worldlines, guided investigations, Human Read, interfaces, APIs, alerts, recommendations, and exports while enforcing surface binding and egress closure.

5. Preservation Plane

Maintains Passports, evidence ledgers, seals, manifests, version lineage, replay requirements, and preserved evidence artifacts.

The planes remain connected through the same Current Evidence Run. The deployment model may be browser-local, distributed across enterprise services, or implemented through another technical architecture. The evidence relationships and authority boundaries must remain intact.

The presentation or egress plane must never become an independent authority plane.

Runtime Evidence and Evidence-Governed Computation

Runtime Evidence and Evidence-Governed Computation solve related but distinct problems.

Runtime Evidence defines the evidence object and discipline.

It establishes how operational records become source-bound, longitudinal, reproducible, inspectable, challengeable, and preservable reconstructions.

Evidence-Governed Computation defines the governing architecture.

It determines what measurements, classifications, interpretations, explanations, recommendations, surfaces, and exports that evidence may authorize.

The relationship is:

Runtime Evidence establishes what can be known from the record under a declared method.
Evidence-Governed Computation governs what the system may assert, project, preserve, or recommend from that knowledge.

Neither makes the resulting claim universally true. Together, they make its basis, authority, limitations, and lineage inspectable.

SubstrateX Aperture™ as the Reference Implementation

SubstrateX Aperture™ is the principal reference implementation of Evidence-Governed Computation within longitudinal runtime analysis.

It binds source qualification, canonical reconstruction, deterministic behavioral telemetry, temporal and role analysis, scientific instruments, Guided Investigation, Runtime Evidence Passports, replay, export, and preservation to one Current Evidence Run.

Multiple instruments may expose different properties of the runtime, but none owns an independent evidence reality. Operational Worlds may adapt domain language, examples, questions, and operator guidance. Morphic UX may alter presentation and investigative flow. Neither is permitted to change the canonical runtime, measurement authority, marker status, or claim boundary.

SubstrateX Aperture makes the governing principles testable:

• Do all authoritative surfaces resolve to the same evidence object?

• Are source-observed, computed, interpreted, missing, and prohibited states preserved?

• Can every claim be traced to eligible sources and declared methods?

• Do instruments and exports preserve the same marker and regime authority?

• Does a method or source change create a distinguishable version?

• Can unsupported explanations be blocked before egress?

• Can a preserved artifact be reopened, replayed, challenged, and compared?

• Does adaptive presentation leave the evidence unchanged?

The implementation does not prove that every scientific measurement is valid. It demonstrates that measurements, findings, and interpretations can be made executable, inspectable, bounded, versioned, and available for independent evaluation.

Research Status and Claim Boundaries

Evidence-Governed Computation is an architectural discipline and implementation program. Its mechanisms can be tested for internal consistency, conformance, reproducibility, boundary enforcement, lineage preservation, and resistance to unsupported egress.

It does not, by itself:

• authenticate every source;

• validate every measurement;

• make admissible claims objectively true;

• establish unique causation;

• eliminate interpretation or judgment;

• resolve conflicting evidence automatically;

• determine legal admissibility;

• assign responsibility or blame;

• authorize autonomous intervention;

• or guarantee that downstream systems will respect preserved boundaries.

Those limitations require external evidence, validation, governance, policy, institutional authority, or enforcement beyond the architecture itself.

The framework remains falsifiable at the architectural level. A conforming implementation should fail if:

• unsupported claims can reach authoritative surfaces;

• instruments create incompatible runtime histories;

• missing evidence is converted into a substantive value;

• projection strengthens a claim;

• revision erases prior lineage;

• export removes the claim boundary;

• or the same declared evidence and method produce irreconcilable governed results outside stated tolerance.

The Foundational Contribution

Evidence-Governed Computation does not claim invention of evidence, provenance, audit trails, runtime verification, information-flow control, digital signatures, reproducible computation, or assurance cases as individual concepts.

Its distinctive contribution is their integration into a constitutional architecture for computational assertion:

• one identified evidence authority;

• typed claims and executable admissibility;

• layered authority that separates evidence, recommendation, and action;

• declared computation and instrument contracts;

• bounded projections;

• projection non-amplification;

• surface-level evidence binding;

• egress-wide enforcement;

• explicit uncertainty, missingness, and prohibition;

• challengeable lineage;

• non-destructive revision;

• and preservation across export and re-entry.

The framework establishes an essential distinction:

A computational result becomes authoritative not because it is displayed, repeated, signed, or generated by an advanced model, but because the system can demonstrate the evidence, method, scope, boundary, status, and lineage under which that result is admissible.

Its ultimate question is the one every consequential computational system should be able to answer:

What evidence authorized this claim, through which method, within which boundary, for which purpose—and how can that authority be independently inspected and challenged?