The graph's self-test

I pitched this lesson as "validation — the inline cousin of chainref." Reading the code corrects that, and the correction is the lesson: pkg/validation isn't inline at all. It's a second periodic monitor, running its own loop, asking a different question than chainref. Two quality systems, two altitudes — and knowing which answers which is the point.

1 · A catalog of numbered checks

Validation is a flat registry of small CheckFuncs, each with a stable ID, a category, and a graded severity. A check returns Finding{Severity, Category, CheckID, Message, Count, Examples}. The catalog reads like a linter for the graph:

Severity is graded per finding, not binary — a check computes info warn error from how bad the result is (e.g. B01 is info when clean, warn on minor drift, error on a real mismatch). The suite is a dashboard of dozens of these, each a fresh gauge every cycle.

2 · The two-tier cadence — separate by cost

The core design decision: checks are split into two independent tiers by what they touch, each with its own loop and cadence, so a cheap check never waits on an expensive one.

Two registries, two goroutines (RunFast / RunSlow). The reasoning is exactly L24/L29's RPC-budget tension: RPC checks are slow and rate-limited, so isolating them means the cheap graph checks give fast feedback every few minutes instead of being dragged to the hourly RPC cadence. Cost dictates cadence; cadence dictates the loop.

3 · Per-check isolation — a check that breaks is itself a finding

Here's the robustness move. Each check runs in its own goroutine under a per-check timeout, and the runner converts its own failures into findings:

go func() {
    defer func() { if r := recover(); r != nil { out.panicVal = r } }()  // a panic is caught…
    out.findings = check(checkCtx, deps)
}()
select {
case out := <-done:    // panic → emit a CHECK_PANIC finding (SeverityError), keep going
case <-checkCtx.Done(): // timeout → emit a CHECK_TIMEOUT finding (SeverityError), keep going
}

4 · Monitor, not control loop

The deepest contrast with chainref: validation has no actuator. Findings flow to telemetry gauges (per check, per category, per severity) and structured logs — and stop there. No streak, no Linear ticket, no healer. Humans read the dashboard and decide.

5 · The deliberate overlap with chainref

Notice B03 here — Σ HOLDS ≤ totalSupply — is the same invariant as L32's BalanceConservationVerifier. That's not duplication by accident; it's the same fact checked at two altitudes:

Defense in depth: the cheap monitor flags it fast; the precise harness confirms, grades, and acts. Real systems check the same critical invariant in more than one place, on purpose.

What you can now do

• State validation's question (internal coherence / own-rules) versus chainref's (chain truth) and parity's (Python match).
• Read the numbered-check catalog (S / C / B / R) and the graded-severity Finding shape.
• Explain the fast/slow tier split as cost-dictates-cadence, and why two independent loops matter.
• Explain per-check isolation and how a panic/timeout becomes a first-class self-reported finding.
• Explain monitor-vs-control-loop, the zero-count gauge habit, and the deliberate B03 ↔ chainref overlap.