Your team finds a promising result. The next report describes its potential. A later presentation turns that potential into a recommendation. Which step established that the recommendation actually follows?
That question matters to research leads, technical reviewers and anyone asking an AI to build on earlier work. Keeping the source document helps. Keeping the precise inference, its assumptions and the check that supports it makes the decision much easier to examine.
This is the job of a claim ledger in 8DB's evidence graph: give the observation and the proposed conclusion separate identities, then make their connection inspectable. The useful research can remain available even when one attempted inference fails.
A promising improvement, and the step it still needs
Our research-governance work uses an example from the study of fluid equations. The mathematical question is specialized; the reasoning mistake is familiar: an improvement is assumed to be sufficient because it is an improvement.
Suppose a positive quantity grows according to a quadratic law, M². Dividing by a logarithm slows that growth for large M. It is tempting to jump from “slower growth” to “the quantity can no longer become infinite in finite time.”
The second statement needs its own check. For the ordinary differential equation M′ = M² / log(M), starting at M = e, separation of variables gives a finite time to infinity: 2/e. Slower than quadratic still leaves room for finite-time blow-up. The calculation appears below so the reader can check the exact claim.
This is an example about an ordinary differential equation, not a solution or counterexample to Navier-Stokes. Its value here is the boundary it exposes: the growth estimate and the desired conclusion are different claims.
Observation → inference → decision
Keep the useful result. Check the leap.
A mathematical example of the distinction a research ledger should preserve.
The growth is slower
Dividing quadratic growth by a logarithm slows it for sufficiently large values.
A useful comparison.It stays finite forever
That conclusion requires more than the comparison. Give the inference its own check.
A separate obligation.This route is insufficient
The stated ordinary differential equation still reaches infinity in finite time.
Reject this inference; preserve the observation.The promising estimate and the exact reason this attempted use fails stay connected.
Give the inference its own record
A useful ledger would retain the observation, record the proposed implication and attach the counterexample to that implication. A later reviewer could keep exploring the promising estimate while immediately seeing why this particular route does not establish the conclusion.
The same pattern appears outside mathematics. A model's accuracy improves on a test set; a recommendation assumes it will improve the live workflow. A material performs better in a laboratory assay; a design assumes it will survive the field conditions. Each connection needs evidence appropriate to the decision.
For an AI-assisted investigation, that creates a concrete opportunity: retrieve the useful result and the condition that limited its use, rather than repeat a polished summary with the limitation missing. Whether a particular agent reliably uses those records must still be evaluated in that workflow.
What the implementation supports
The source-reviewed evidence twin provides three building blocks:
- Separate evidence states. Its records distinguish source-attested material from stronger verification events. The event and its scope remain relevant to interpreting the label.
- Checked dependency insertion. On the checked path, a
ConfidenceMinrestriction can reject an edge whose conclusion has a higher assigned upper bound than its premise. That is a declared consistency rule for this graph, not a calibrated probability of truth or a proof that the implication is valid. - Dependency inspection. Queries expose direct premises, a path through the lowest assigned premise bounds, and recorded downstream dependencies. The downstream query is read-only: it identifies work to review rather than automatically deciding which conclusions are false.
Those mechanisms operate on the claims and relationships supplied to them. A reviewer or application still has to express the missing implication and choose the right check. The checked insertion path also has a specific scope; migration and fixture paths in the reviewed code can insert unchecked edges. Deployment needs to make the appropriate path mandatory for its workflow.
This is why we use small, explicit acceptance cases. “The database contains a graph” is a starting point. “A consumer can retrieve this claim, its exact support and the reason a proposed use fails” is a behavior a team can test.
Keep different kinds of evidence distinct
Use the following review cases as acceptance criteria for your workflow: which missing steps should the system catch, and what should the reviewer see next?
| What the record contains | What a reviewer should be able to tell |
|---|---|
| A counterexample | Which exact implication it defeats, and which observation remains useful |
| An unfinished argument | Which assumption or proof obligation is still open |
| A theorem with conditions | Whether those conditions hold in this proposed use |
| A signed source artifact | That its identity is intact, separately from whether its claims are correct |
| An approximate calculation | Its error contract and the decision it can support |
| A changed or unavailable source | Which recorded dependencies need review and which have separate support |
Provenance already has an established vocabulary. W3C PROV represents entities, activities, agents and derivations. Our aim is to connect that record of how information was produced with explicit checks on how a research claim may be used. The benefit should be demonstrated in the reader's workflow; graph storage alone does not establish it.
The calculation behind the example
For readers who want the mathematical detail, take M′ = M² / log(M) with M(0) = e. Separating variables gives:
time to infinity = ∫[e,∞] log(M) / M² dM = 2/e < ∞
An antiderivative is −(log(M) + 1) / M. The accumulated quantity also diverges along this solution:
∫ M dt = ∫[e,∞] log(M) / M dM = ∞
More generally, the time integral with (log M)^α / M² converges for any fixed positive α. Substituting u = log M gives an exponentially decaying tail u^α e^(−u). A logarithmic improvement to quadratic growth therefore does not, by itself, supply a global bound.
The Beale–Kato–Majda paper concerns the continuation of smooth three-dimensional Euler solutions through control of vorticity. It supplies the research background; the elementary calculation above checks only the stated differential-equation implication. Applying a continuation criterion to a fluid equation requires its own hypotheses and estimates.
Start with one decision your team must defend
Choose one research conclusion that a team or an AI already relies on. Write down its source, the inference connecting it to a decision, and the evidence that would justify or defeat that inference. Then ask whether another reviewer can recover all three without reconstructing the conversation.
Bring us one non-confidential claim and the decision it supports. We can use that example to scope an evidence-graph evaluation: preserve the useful work, expose the uncertain step and make the next review easier to perform.
Implementation scope: source inspection at 8DB commit d5d0f58e. This article does not report a fresh execution, an automatic falsifier generator or a measured reduction in research errors. The earlier article's research chronology is retained in the editorial archive; this revision bases its explanation on the explicit calculation and inspected implementation.
Evidence scope Worked mathematical example · Pinned implementation review · Proposed acceptance workflow. Explore the evidence. Methods and retained scope notes.