# Ticket #000059 — Admission discipline: claim-graveyard query + self-providence quarantine

**Status:** open · awaiting go/no-go
**Opened:** 2026-05-20
**Scope:** Two coupled write-path mechanisms that decide what may
*re-enter* durable state: (1) a graveyard-check that raises proof
burden when a previously-failed claim is re-asked; (2) a
self-providence guard that detects and quarantines model-output
masquerading as independent evidence.
**Audience:** fox + a Dav1d de-novo review of the
"accepted-state-transition" admission boundary + maintainers of
`arborist/qa/runner.py`, `arborist/store.py`, the `ingest-self`
family.
**Hard constraint:** verifier stays binary; these are admission /
burden sidecars, not new verifier output fields. No write to
`providence_cache` semantic columns beyond the existing
`falsification_state` machine. Cores never evict. **The graveyard
MUST be bounded — it reaches a steady-state size proportional to the
*recurring*-error surface, never to queries-ever (see §7). If it can't
be bounded, it doesn't get built.**

---

## 1. Origin

Dav1dPrometheus, *Protocol-Layer AGI, Recursive Falsification, and the
Final Bet* (2026-05-20 working report; held outside the repo per fox).
This is the report's **§11 Priority 2** ("claim graveyard +
self-providence quarantine") and the strongest concrete arborist gaps
under its central thesis (**§57**): *mature cognition is admissible
state transition — what is allowed to enter durable state — not output
generation.*

## 2. Why these two together (clears don't-proliferate)

Both answer the same question on the **write / re-ask path**: *should
this be admitted?* They share the same audit seam and the same
`falsification_state` machine, and the report groups them as one
priority. Splitting them would fragment one admission-discipline review.
They are a distinct Dav1d-reviewable audience from the *measurement*
work (#000060) and the *cache-identity* call (#000058).

## 3. Sub-item A — Graveyard-check (burden-shift on re-ask)

**What exists.** `falsification_state ∈ {live, failed, stale,
quarantined}` already preserves rejected claims in `providence_cache`
(audit-preserving `make falsify`, not delete). Cache lookups filter to
`state='live'`. So the *graveyard storage* already exists — failed /
stale / quarantined records are the graveyard.

**The gap.** There is no **GraveyardCheck**: when a new question
canonicalizes to a claim family that previously `failed`, the runner
does not raise the proof burden. The report's point (§42.9, §62-63):
errors repeat; a claim with a known failure history should require
*stronger* evidence, not start fresh.

**Sketch (read-only sidecar first — five-step #5, automate last):**
- On `ask()`, after canonicalizing the question/claim, query the
  shard(s) for prior `failed`/`quarantined` records in the same
  canonical/predicate/source-root family.
- Emit an advisory `graveyard_status` + `required_proof_burden` on the
  run-DAG (NOT into `providence_cache` / `audit_events`), mirroring the
  existing `arborist inspect` sidecar discipline.
- A demote-only verifier hook (raise the warrant threshold for a
  graveyard hit) is possible but, like the coherence sidecar, stays
  **deliberately unwired** until a bench shows it nets positive — wiring
  it would fold into `governance_policy_hash`.

## 4. Sub-item B — Self-providence quarantine

**What exists — and why it's a live risk.** `make
ingest-self-providence` (Makefile:769) deliberately promotes STRICT
live providence records back into the document corpus. That is the
exact recursive self-confirmation loop the report warns about (§70):

```
model output → promoted to corpus → retrieved later as evidence
→ supports related model output → recursive self-confirmation
```

Arborist ships the mechanism that *creates* the risk and **no guard
against it**. That asymmetry is the strongest single motivation in this
ticket — it is not a hypothetical.

**The gap → guard.** Detect when a retrieved evidence chunk's
`source_root` descends from a prior-model-output root (i.e. was ingested
via the self-providence path) with no independent corroborating source,
and lower its warrant / quarantine it for high-impact claims.

**Sketch:**
- Tag self-providence-ingested documents at ingest time with a
  provenance marker (an edge / source-role: `self_providence_edges`, or
  reuse the existing edge/`supersedes` machinery) so the lineage is
  queryable without scanning text.
- At retrieval/verify time, compute `SelfProvenanceRisk` = high when a
  cited evidence root descends from a self-providence root AND no
  independent source root supports the same claim.
- Response: lower warrant; require an independent source; quarantine if
  used for a high-impact claim. Advisory-first (sidecar), demote-hook
  bench-gated like §3.

**Warrant adjustment (report §70), as a *soft* ranking signal only —
never in the hard proof path:**
`WarrantAdjusted = WarrantBase − λ·SelfProvenanceDepth + μ·IndependentSourceDiversity`.

## 5. Scope boundaries

- Advisory sidecars first; any demote-hook is a separate bench-gated
  flag that folds into `governance_policy_hash`.
- No new semantic `providence_cache` columns; reuse
  `falsification_state` + edges + run-DAG advisory fields.
- Soft signals (similarity, depth, diversity) never enter the hard
  hash / proof path (CLAUDE.md soft-vs-hard invariant).
- Burn/delete stays scratch-only; default is falsify / quarantine /
  stale (report §8 fail-safe hierarchy = arborist's existing one).

## 6. Done when

GraveyardCheck emits an advisory burden signal on the run-DAG for
re-asked failed-claim families; self-providence-ingested documents are
lineage-tagged and a `SelfProvenanceRisk` sidecar flags
self-confirming evidence; both behind read-only sidecars with
bench-gated demote-hooks left unwired pending a measured net win.
Tests + `make chain-check-shards` clean (0 per shard).

---

## 7. Bounded ingestion — the graveyard must not grow like cancer (fox, 2026-05-20)

**The deletion test first (five-step #2).** The report (§62) claims the
claim graveyard is *more valuable than the knowledge graph* and that "a
system without memory of its rejected beliefs is not fully learning."
Read literally that means store every wrong answer forever — unbounded
accumulation bolted onto a system whose entire premise is **constraint
optimization**. That is self-contradicting: the hot path is lean by
design; an ever-growing tombstone archive beside it is exactly the waste
fox flagged. So the constraint is binding: **the graveyard earns its
existence only if it stays bounded. If it cannot be bounded to a
steady state, it is not built.**

**What the graveyard is actually for.** Preventing *recurring* error
cheaply — NOT archiving every error. A failure that never recurs costs
storage for zero benefit. Value ∝ recurrence, so ingestion must be
gated on recurrence.

**BTC is the right model, but for the right reason.** BTC's lesson is
not "store everything" — it is **bounded, self-regulating ingestion**:
difficulty adjustment holds a stable block rate regardless of hashpower;
supply is capped; nodes validate against a compact UTXO set, not full
history. Port those three properties, not the ledger.

### 7.1 Four bounding mechanisms

1. **Earn-to-enter (recurrence-gated).** A failure earns a tombstone
   only when the same canonical claim-family **re-fails** (or is
   re-asked and re-fails). One-offs are dropped. Ingestion rate ∝
   recurrence rate — naturally small. This is BTC's "costs work to
   enter the permanent record" property applied to epistemic state.
2. **Fingerprints, not transcripts (UTXO-set analogy).** Store a hash
   of `canonical_claim_family | falsifier_root | failure_class` in a
   compact set / Bloom filter — enough for GraveyardCheck's burden
   shift (§3). Prune the bulk answer text; it is not load-bearing for
   the burden check.
3. **Decay to steady-state.** `retest_after` + reputation decay (both
   already named in the report). A tombstone whose retest window passes
   without recurrence is evicted or compacted; failure families merge.
   The graveyard **evicts like a surface, never like a core** — it is a
   *cache of lessons*, and caches evict. Steady-state size tracks the
   recurring-error surface, not total queries.
4. **Off the hot path.** A dedicated graveyard shard (report §9.1),
   queried only as a Bloom-filter burden check — never inside hot
   retrieval. Reads stay lean; the lessons-cache is consulted, not
   traversed.

### 7.2 Gossip-group inheritance (cross-link → #000012 / `mesh/`)

fox: *"arborist gossip groups need something similar."* The shared
falsifier/claim-root admission in gossip groups inherits the same
discipline so shared state does not grow unbounded across peers:

- **Difficulty-adjusted stable-rate admission** — the rate at which new
  falsifier/claim roots enter shared group state is throttled by a
  difficulty parameter that rises with spam / invalid-proof /
  poison-survival and falls with replay-success (report §67's update
  rule). Stable target rate regardless of peer count — BTC's ~10-min
  block target, applied to epistemic admission.
- **Per-window admission budget** — ties into the existing
  `docs/soft-hash-channel-t3-bound.md` per-window budget bound (#000036)
  and its `t3_bound_calculator`. A group admits at most a bounded number
  of new roots per window; the rest wait or are dropped.
- **Earn-to-enter at the mesh too** — a falsifier enters the *shared*
  graveyard root only when replay-verified by independent peers (the
  report's "reward accepted, replayed falsifiers"), not on first
  assertion. This is the mesh analogue of §7.1(1).

This subsection is the home for the principle; the consensus/Sybil
mechanics that enforce it live in **#000012** (v8 selection/consensus)
and the wire-level state machine in `arborist/mesh/`. Cross-linked, not
spawned as a separate ticket — it is a bounding *constraint* on existing
work, not a new audience.

### 7.3 Acceptance addition

The graveyard ships only if a steady-state-size demonstration exists:
under a synthetic recurring + non-recurring failure stream, the
graveyard footprint converges (bounded) rather than growing linearly
with query count. A linear-growth result kills the feature (§7 opening).
