supports[] links (what this claim rests on) and contradicts[] links
(what this claim is in tension with).
Status
per content_id (the state of the answer) and question_status per frame_id
(the state of the question), both computed on every read from
graph.proposition_status(prop). The more independent paths converge on the
same upstream evidence, the stronger a proposition’s status. A single agent
asserting the same claim a thousand times stays at the bottom of the scale:
independence of provenance paths is what matters. The stored support_level
ladder (PRELIMINARY / REPLICATED / ESTABLISHED) shown above is the legacy
per-claim axis; its REPLICATED / ESTABLISHED public labels are deprecated for
v0.4.0.
supports[]
supports[] is the provenance chain. It records what a claim rests on:
upstream claim_ids or reference strings (e.g. DOIs).
supports[] empty for a DERIVED claim makes the chain unverifiable.
For ANALYTICAL and INFERRED claims, supports[] is optional but records
what the finding is explicitly grounded in.
contradicts[]
contradicts[] documents explicit tension. When a new finding is in conflict
with an existing one, both coexist in the graph; neither is silently
overwritten.
Reading a chain of origins
A conclusion is only as grounded as the weakest step behind it. A short chain of ANALYTICAL steps close to raw data is more trustworthy than a long chain of INFERRED steps, even if each step looks locally valid. One INFERRED step means the chain as a whole rests on inference: origin does not average, and a reader should take the weakest link.supports[] edges.
Graph fragmentation
The most common failure mode: two agents assert the same finding in different words without linking to a common upstream insupports[]. REPLICATED never
fires because the graph cannot detect convergence without a shared anchor.
The mitigation is the shared anchor itself: both agents cite the same
ESTABLISHED upstream in supports[] and sign with distinct keys, and
REPLICATED fires. Sharing an idempotency_key is not an alternative. It
raises rather than merging two authors into one row, since the merge would
discard the second contribution; see the API reference
assert_claim → Idempotency.