When Evidence Changes, Know Which Decisions Need Review

A source changes after a decision has been made. Someone has to work out which conclusions relied on it, which investigations need another look and which work can continue.

That job is much easier when the dependencies are explicit. 8DB's research evidence twin records statements, their sources and the relationships that support a conclusion. Its change-impact query follows those relationships to identify the work affected by a withdrawn premise.

The practical benefit is a narrower review queue. Follow the changed support to the decisions that used it, and keep unrelated work in view.

Try withdrawing a premise

The September Navier-Stokes evidence fixture offers a concrete example. A recorded theorem supports the statements labelled Clay (C) and Clay (D). Its withdrawal query returns those dependents. A separately supported Euler result stays outside that cascade. A different source, the preprint links in a proposed route, has its own downstream dependency.

The interactive figure illustrates those selected relationships. It uses a browser fixture, with the same separation the implementation's query tests assert. It does not call the database or decide the mathematics.

An affected path needs reassessment. That does not establish that the conclusion is false. The query follows the support recorded in this graph; it cannot tell you that no independent proof or unrecorded source exists elsewhere.

Record why a connection exists

Two statements can discuss the same subject without one depending on the other. Connecting them casually would make change-impact analysis noisy or misleading.

In this twin, cascade edges represent recorded derivation dependence. The builder deliberately keeps independently supported results separate, even where a mathematical relationship could be discussed. That choice is what lets a withdrawal identify a useful review boundary.

Each statement also retains a source anchor with a URL, date, source class and commit where available. Verification events record what was checked and where that evidence came from. The graph gives a reviewer a route back to the material behind the claim.

This builds on established provenance concepts. W3C's PROV-O provides relationships for derivation, revision and invalidation. The additional question for 8DB is how those relationships can support executable checks and focused reassessment. W3C PROV-O ↗.

Make the support rule executable

The twin attaches confidence intervals as authored assessments of the recorded evidence. They are neither measured accuracy rates nor calibrated probabilities. Formal verification events remain separate, inspectable records.

For the fixture's declared dependency rule, a conclusion's upper confidence bound cannot exceed that of a required premise. The checked edge-insertion path audits available endpoints and rejects a hard violation. The builder and consistency checks give this rule a concrete place to operate; the claim is about that path and graph.

This is useful because a rule that exists only in prose is easy to forget during an update. Making it executable allows a deliberately inconsistent relationship to be refused and investigated.

The meaning of the relationship matters as much as the check. Jointly required premises and independently sufficient routes need different treatment. The fixture uses the former rule on its declared edges. A system evaluating alternative proofs must represent their separate support before deciding whether withdrawing one route affects the conclusion.

Keep evidence strength tied to events

The twin also derives a permitted evidence tier from recorded verification events. A requested tier must fit what those events support. Static review, rebuilds, axiom audits and comparison against a pinned statement have distinct roles in the formal ladder. Peer review is recorded separately.

A registry label alone does not replace the checks required by the ladder. A pending event contributes no completed verification. The origin of the event remains attached, so a registry report and a replay performed by our own system can be inspected separately.

The result is a record a reviewer can challenge precisely: this source, this check, this scope, this consequence. The database manages the evidence policy; a mathematical checker and domain review establish the claims within their respective limits.

Turn a gap into a next step

Missing evidence is useful information when it has a specific shape. The twin represents an open item with its unresolved question, a condition that could resolve or refute it, and a proposed follow-up or a reason human judgment is required.

That lets a research programme ask which uncertainty blocks a route and what evidence would move it forward. A recorded tool intent is a proposed action; execution and its outcome need their own records.

The same pattern is worth evaluating for engineering decisions, control assessments and AI-assisted investigations. These are applications of the architecture to test, rather than claims that the Navier-Stokes fixture has already qualified every domain.

Start with one decision worth revisiting

Choose a decision whose supporting evidence could change. Identify one source it requires and one independently supported conclusion that should remain unaffected. The useful test is simple to describe: withdraw that source and inspect the review queue.

Send us a non-confidential description of that decision. We can map the smallest evidence twin needed to test the dependency rules. You should be able to see why each item needs attention and what evidence would let it proceed.

Evidence scope Evidence-twin implementation and recorded fixture · scoped change-impact analysis. Explore the evidence.