Lumen
Understand the system

Provenance, validity, and currentness

Trace research claims to exact immutable inputs without confusing history with current selection.

Provenance connects a claim revision to exact evidence: block revision, execution, output, artifact, dataset digest, variable version, environment, and producing attempt where applicable. A message or search result is not evidence merely because it sounds conclusive.

The same rule applies inside an attempt sandbox: a local file, shell transcript, scratch-Python value, or ephemeral subagent report is not canonical evidence. The attempt must publish immutable bytes and use the trusted research-recording surface to create the exact output/evidence/claim link.

Three separate questions

  • Review status: has a human or policy accepted this claim revision?
  • Validity: is it supported for its pinned inputs, invalidated, or retracted?
  • Currentness: does it match the project's selected live inputs now?

A newer dataset can make an old claim outdated while the old result remains valid for its pinned dataset. A failed replication can invalidate it. Neither case permits rewriting historical evidence.

Reverse invalidation

Evidence references and live anchors are project-owned, versioned records. Changing a selected live variable or anchor can mark dependent claim revisions and reports outdated without changing their pinned evidence. A validator can instead mark a claim invalidated; retraction remains an explicit historical decision. Reverse dependency traversal is bounded and recorded as canonical events, so a client can reload affected objects from the returned cursor rather than guessing from presentation state.

The deterministic story is the smallest example: one accepted, current claim valid for pinned inputs and backed by one immutable artifact. The same query and invalidation contracts apply to multi-source claims, variables, and reports.

On this page