Evidence Authority, Claim Admissibility, and Bounded Computational Projection

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

Evidence-Governed Computation establishes an architectural rule for closing that gap.

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.

The governing commitment is simple:

No authoritative output may exceed the authority of its evidence.

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 absent. A chart may display an accurate value while its title implies causation. A generated explanation may begin with supported findings and then introduce intent, responsibility, or root cause. An export may preserve 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 problem becomes more serious as computational systems become modular. Separate components calculate metrics, assign labels, generate narratives, issue alerts, recommend actions, and create reports. Each surface may develop its own terminology, thresholds, fallback logic, and assumptions.

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

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

From Evidence to Claim

Ordinary analytical software is often understood as a transformation:

Input → Computation → Output

Evidence-governed systems must preserve a more complete relationship:

Evidence Object
→ Declared Method
→ 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 kind of claim is being made?

• What temporal and operational scope applies?

• Which assumptions and uncertainties remain?

• What stronger interpretations are prohibited?

• What happens when required evidence is missing?

• Can the result 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.

Evidence Authority

Evidence authority is the scoped permission to use an identified evidence object, under a declared contract, to support particular 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 remains separated across several layers:

• Source authority establishes what material was supplied, observed, or attested.

• Method authority establishes which procedure may operate on eligible evidence.

• Claim authority determines which proposition the evidence and method may support.

• Presentation authority permits a surface to render an admitted claim without changing it.

• Recommendation authority permits the system to present an evidence-supported option.

• Execution authority determines whether anyone or anything may act upon that recommendation.

• Preservation authority governs what may be retained, exported, or disclosed.

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 recommendation does not authorize autonomous action.

Claims as Computational Objects

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

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

A governed claim identifies:

• its normalized proposition;

• its claim class;

• its temporal and operational scope;

• the evidence and methods supporting it;

• its assumptions;

• its uncertainty and limitations;

• its prohibited extensions;

• and its current status.

This allows different surfaces to express the same claim without altering 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. Both can bind to the same underlying claim identity.

If the brief changes that statement to role fragmentation caused the failure, it has introduced a stronger claim requiring different evidence and separate authorization.

Fluent language cannot create evidentiary authority.

Claim Classes and Status

Evidence-Governed Computation distinguishes among different forms of assertion:

• Source statements report what a record contains.

• Derived measurements report the result of a declared computation.

• Protocol classifications state that specified criteria were satisfied.

• Supported interpretations connect admitted findings through an authorized interpretive rule.

• Contextual assertions depend on separately supplied or attested information.

• Recommendations combine admitted evidence with a declared decision policy.

Each class requires a different form of support.

Claims also retain explicit status:

• Admissible

• Conditional

• Provisional

• Disputed

• Superseded

• Withheld

• Not computable

• Prohibited

These states are part of the evidence architecture, not visual decoration. A blank field, zero, hidden panel, unavailable value, and prohibited conclusion do not mean the same thing.

Executable Claim Boundaries

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

It can restrict:

• temporal scope;

• operational or population scope;

• audience;

• evidence class;

• uncertainty;

• causal interpretation;

• hidden-state inference;

• identity or intent attribution;

• recommendations;

• and export or 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, or export may silently cross that boundary.

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

Computation and Instrument Contracts

Every authoritative computation operates under a versioned contract.

A computation contract defines:

• eligible inputs;

• canonicalization and ordering rules;

• algorithms, thresholds, and dependencies;

• role-resolution and normalization policies;

• deterministic and variable state;

• uncertainty and missingness behavior;

• admissible claim classes;

• prohibited interpretations;

• validation status;

• and replay, export, and preservation requirements.

Individual instruments operate through their own bounded contracts. Each instrument must declare what it reads, what it computes, what it produces, what evidence it requires, and what its output may legitimately support.

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

Its authority comes from its relationship to the evidence object and active computation contract.

Bounded Computational Projection

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

A projection may:

• select;

• aggregate;

• organize;

• translate;

• summarize;

• or visualize 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.

A visualization cannot convert correlation into cause. A summary cannot convert a candidate boundary into a confirmed failure. A role label cannot become verified identity. An experimental classifier cannot become a certified 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 can reach a person or another system:

• a chart;

• a dashboard;

• an instrument;

• a tooltip;

• an operator brief;

• an API;

• an alert;

• a generated explanation;

• a recommendation;

• or an exported report.

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

• the evidence object;

• the admitted claim;

• the source and derivation path;

• the governing method;

• its scope and status;

• and the relevant version.

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, or removing limitations.

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 controls. This includes interfaces, APIs, generated narratives, alerts, recommendations, reports, downloads, and transfers to downstream agents or decision systems.

An unsupported claim cannot become acceptable merely because it was produced by a different component.

Logging an overreaching conclusion after it has already been issued is not evidence governance. The claim must be evaluated before the system presents it as authoritative.

Challenge and 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.

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:

• Evidence revision — the underlying source material changed.

• Method revision — an algorithm, threshold, ontology, or dependency changed.

• Policy revision — the rules governing admissibility, audience, or action changed.

A disputed claim can 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 three essential planes:

• Evidence plane — preserves sources, canonical records, provenance, derivations, methods, and evidence states.

• Authority plane — evaluates claim admissibility, scope, uncertainty, prohibition, audience, and revision.

• Presentation plane — exposes bounded projections through instruments, investigations, narratives, APIs, and exports.

The presentation plane must never become an independent authority plane.

An implementation may place these responsibilities inside one browser-local application or distribute them across enterprise services. The deployment model can change. The evidence relationships and authority boundaries must remain intact.

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, and preservable reconstructions.

Evidence-Governed Computation defines the governing architecture.

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

The distinction is foundational:

Runtime Evidence establishes what the system knows from the record.
Evidence-Governed Computation governs what the system may do or claim with that knowledge.

Fieldglass as the Reference Implementation

Fieldglass® is the first integrated implementation of Evidence-Governed Computation within longitudinal runtime analysis.

It binds source qualification, canonical reconstruction, behavioral telemetry, role and interaction analysis, scientific instruments, guided investigation, Runtime Evidence Passports, replay, and preservation to one Current Evidence Run.

Multiple instruments may observe different properties of the runtime, but none owns an independent evidence reality. Operational Worlds may change terminology, examples, investigative questions, and operator guidance while the canonical evidence object remains unchanged.

Fieldglass makes the governing principles testable:

• Do all surfaces resolve to the same evidence authority?

• Are missing and prohibited states preserved?

• Can claims be traced back to sources and methods?

• Do interfaces and exports preserve the same boundaries?

• Does a method change create a distinguishable version?

• Can unsupported explanations be blocked?

• Can an evidence artifact be exported, reopened, challenged, and compared?

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

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.

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

• one identified evidence authority;

• typed claims and executable admissibility;

• declared computation and instrument contracts;

• bounded projections;

• surface-level evidence binding;

• egress-wide enforcement;

• explicit uncertainty and absence;

• challengeable lineage;

• non-destructive revision;

• and preservation across export and re-import.

The framework establishes an important 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, 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, and how can that authority be independently inspected and challenged?