Cascade stability
When one claim is reassessed, does the ripple die out or grow? Reconstructed from the run's own telemetry, free.
What it checks
A StewardThe agent that owns a claim: breaks it into the claims it depends on, weighs the evidence, and records a verdict.agent → that changes its verdict tells the Stewards of the claims that depend on it. Each of those judges for itself whether the change matters. If they mostly say no, a change dies out in a generation or two. If they mostly say yes, one edit becomes many, and the queue grows instead of draining.
The number is R: for each reassessment that materially changed a claim, how many of the reassessments it caused also materially changed theirs. Below 1 the ripple shrinks; at or above 1 it does not. A material change is a status change or a credence move of at least 0.1 (--material).
Alongside R: how fast notifications stop leading to runs, generation by generation (materiality decay); how much of a storm the pending-slot coalescing absorbed; the size and depth of every cascade; claims whose status went A to B and back to A; and whether the pending queue drained monotonically or re-inflated.
Detail
How it is computed, step by step
- Read the telemetry. every Steward run in the window (agent_runs), every Steward enqueue with who caused it and whether it joined an existing pending slot (enqueue_events), and every assessment written (assessments history).
- Attach each run to the event that woke it. a run's slot is the Steward events on its claim after the previous run on that claim started; the slot's creator names the parent. A run with no Steward parent (onboarding, an accepted contribution, a staleness sweep, a user order) is a root.
- Classify each run's change. first assessment, material, minor, or none, by comparing the assessment it wrote with the one before.
- Count per generation. notified, ran, materially changed; R over all generations and over reassessments alone.
- Read the shape. cascade sizes and depths, oscillations per claim, the pending-depth curve from queue_depth_snapshots when the sampler ran and otherwise reconstructed from enqueues and run starts (approximate, and marked so).
- Write and register. cascade.json in the run directory, a §22 block in the scorecard, and a row of kind cascade in the eval-run registry. Every corpus run prints the one-line summary at its end.
What it cannot show
- Lineage is reconstructed from timestamps, not carried as a cascade id; a telemetry gap makes an unattributed root, and the reading names how many.
- A newly minted subclaim is onboarded through the claim pipeline, so it counts as a root; R measures reassessment propagation, not decomposition fan-out.
- Oscillation is counted per claim over the window, not per tree.
- The reconstructed drain curve assumes an empty lane at the start of the window.
Run it
npm run corpus:cascade # the corpus DB, whole history
npm run corpus:cascade -- snap:<name> --since=<iso> --material=0.15
npm run corpus:run -- blackholes # prints the cascade line at the end