Traceable Evidence Admission and Lifecycle Control
Long-running agents risk relying on untraceable or outdated statements; an EvidenceBank admits statements tied to inspected passages and explicitly supersedes or retracts them as evidence changes.
Read the paper ↗What it is
- Source-linked admission A statement enters the evidence store only when it points to passages the agent has already inspected; the controller checks that the references are registered.
- Evidence lifecycle A correction becomes a new active entry and marks the old one superseded. A retraction makes an entry inactive without replacing it; both changes remain recorded.
Why it matters
Long-running agents need to reuse evidence without losing where it came from or quietly relying on a statement that has since been corrected or withdrawn.
Before we get into the mechanics, here is the basic idea: an agent needs a durable place for evidence it has already checked, but that place cannot be a pile of untraceable notes. LongHarness ties each stored statement to a passage the agent read, then gives corrections and withdrawals explicit status changes. That matters because an old statement may already have influenced later reasoning.
-
Traceability: the canonical example is a statement extracted from a particular report passage. The agent can keep the statement, but it must carry a reference to a source passage registered by a prior read. The controller can check that the reference exists; it cannot decide whether the statement is a faithful account of the passage. This is like a notebook entry with a page citation, not a guarantee that your interpretation is right. What should happen when you discover the note was wrong?
-
Persistence: admitted statements remain available across later interactions, so the agent can reuse them instead of reconstructing them from earlier observations. Think of a working evidence notebook that travels with the task. The analogy has a limit: this is structured state with identifiers and validation, not a free-form notebook. How can the notebook change without rewriting its past?
-
Explicit revision: the agent can replace an active statement or withdraw it. In ordinary terms, a correction gets a new entry and the old one is labeled superseded; a withdrawal makes the old entry inactive without adding a replacement. The old record stays in the revision history, but it is no longer citeable as active evidence. So a correction preserves an updated claim, while a retraction says, “don’t use this”—what about conclusions that already relied on it?
The important boundary is that evidence and conclusions are separate. After an EvidenceBank update, the agent observes what happened and then revises affected claims and references. The runtime does not automatically repair those conclusions for it. I like this explicit split because it makes stale reasoning a visible maintenance problem rather than pretending a storage update has fixed the whole chain of thought. But who checks that a final answer now points to current evidence?
Read the deep dive
Why People Wanted It
An agent that reads a large corpus needs more than a place to store useful facts. It needs to know which passage each statement came from, keep accepted statements available across interactions, and stop treating a correction as if nothing changed. Otherwise, an old or unsupported statement can keep circulating after the source record has moved on.
So the real question is not just how to remember evidence. It is how to admit it with a traceable source and then change its status without erasing the history of what happened.
The Core Move
LongHarness keeps source-linked statements in a persistent EvidenceBank and changes their lifecycle explicitly: admit validated entries, supersede corrected ones, and retract entries that should no longer be active.
The paper gives this mechanism as operations and state changes, not as a mathematical formula; no formula is needed to describe the lifecycle.
Why Admission Needs a Registered Source
Now the version for readers who want more of the machinery: admission depends on a prior read action, not merely on an agent’s assertion that a source exists. A candidate statement must cite source references registered by earlier reads. The controller checks that those references are valid; the agent is responsible for whether the statement faithfully represents the referenced text.
Upsert accepts proposed source-linked statements as active EvidenceBank entries. Validation is independent for each proposed statement, so a batch can be partially accepted. This separates two checks that are easy to conflate: a reference can be registered and still be used to support a badly phrased statement. What remains the agent’s responsibility after the reference check?
Why Corrections Create a New Active Entry
Here is the part that gets technical: accepted entries have immutable identifiers, so a correction is not an in-place edit. A revise operation names an active evidence identifier and supplies either a replacement statement or a null replacement. With a replacement, the corrected statement becomes a new active entry and the old entry is marked superseded. With a null replacement, the old entry is retracted and no replacement is created.
Superseded and retracted entries remain in the revision record, but they are no longer active evidence and cannot be cited in compute or final requests. This makes the distinction consequential: correction preserves a successor, while retraction removes the statement from the active set without one. What happens to conclusions that already referred to the old entry?
Why Updating Evidence Does Not Update Conclusions
Now one layer deeper: an EvidenceBank mutation and a conclusion update are separate state changes. The agent observes the result of the evidence update before revising affected conclusions, so it can point those conclusions at entries that were actually accepted. Superseding or retracting an entry does not automatically rewrite dependent claims; transition logs can flag affected references, but the runtime does not delete or repair those claims for the agent.
At compute and final submission, declared evidence identifiers are checked against active entries, and final references must resolve to active evidence and underlying source passages. The controller validates references and structure; it does not take over the agent’s job of deciding whether the evidence supports its conclusion. Who, then, is accountable for repairing a conclusion after its evidence changes?
Minimal Causal Code
# Illustrative lifecycle only: validation details belong to the controller.
bank = {} # active evidence: id -> statement and source references
history = {} # inactive entries remain auditable
next_id = 0
def upsert(statement, source_refs, registered_refs):
global next_id
if not source_refs or any(ref not in registered_refs for ref in source_refs):
return None
evidence_id = f"e{next_id}"
next_id += 1
bank[evidence_id] = {"statement": statement, "sources": source_refs}
return evidence_id
def revise(old_id, replacement=None):
old = bank.pop(old_id)
history[old_id] = {**old, "status": "retracted"}
if replacement is None:
return None
new_id = upsert(
replacement["statement"], replacement["sources"], replacement["registered_refs"]
)
if new_id is None:
bank[old_id] = old # failed validation: do not apply this illustrative update
history.pop(old_id)
return None
history[old_id]["status"] = "superseded"
return new_id
What You Gain, and What You Lose
You gain traceability from an active statement back to inspected source text, persistence across interactions, and an explicit record of corrections and withdrawals. Immutable identifiers make the lifecycle legible instead of silently changing what an earlier reference meant.
You also take on bookkeeping. A corrected or retracted entry can leave conclusions with stale references, because evidence changes do not automatically revise those conclusions. The controller can check that references resolve to active entries and sources, but source fidelity and inferential support remain the agent’s responsibility. This is controlled evidence maintenance, not automatic truth maintenance.
A trustworthy evidence store does not just remember statements: it remembers where they came from and how their active status changed.