Solar Voice · The Proof Spike — Cross-Operator Candidate Board

Reading the proof — validation lens2 🟦 Graph · real node/edge 🟪 Hybrid · grounded + rendered 🟨 LLM · voice, no fabrication 🟩 Data · own, not inflated ⬜ Fixed · static 🟥 Care · two-tier holds the Desk inherits the Bench's ink key — same house

The Proof Spike

— every compositor's nominated proof, on one spike

CROSS-OPERATOR NOMINATIONS · CAPABILITY 1

Govern the search over (prompt × corpus).

Compositors at the Bench set the type and nominate proofs1. The Desk reviews every nomination across operators — a live collectionGroup('iterations') read where nominated:true — reads each against readership response, and routes the winner to a print run or to press.

Advisory · not automatic

The sim-score (beat-fidelity) is a lens, never a ranker — it never auto-ranks or auto-promotes (I8 / I10). A human-initiated "sort by score" is fine; a machine picking a winner is not. Pick on outcome first, then sim. The one thing plumbed is the invariant floor — a flag, not a ranker: care · honesty · no-gate · no-fabrication · ≤55 words can hard-flag a proof ineligible.3

On the Spike

— all nominations · sort & filter · click a row for the full proof

Reading the spike — collectionGroup('iterations') where nominated…

Source · collectionGroup('iterations') where nominated:true (prompt) + corpora/* where nominated (corpus). Each iteration stamps promptVersionId AND corpusVersionId, its overrides, simScore, personas.1

On the spike today

Nominated · awaiting judgment—

Ineligible floor flag—

Compositors nominating—

Corpus versions nominated—

Reading the points

Live edition — the pinned pair Nominated — proof awaiting the spike Running — live on a % of readers Ineligible — floor release-blocker Superseded — a prior edition

The pinned edition

reading config/live…

Zero-variation

The engine chat path and the optimizer both read config/live — byte-identical, no deploy. One live pair at a time.6

Audit trail →

Off the Spike

— the freshest proofs worth pulling down · click to open the full proof

Loading nominations…

Corpus Stock on the Spike

— corpus versions nominated for review

CORPORA · WHERE NOMINATED:TRUE

Loading corpus stock…

Marginal Apparatus · Operational Anchors

1: The Proof Spike. Compositors at the Bench (operators / optimizers) nominate proofs from their own sandbox optimization/{uid}/iterations/{id} (a nominated:true flag); a collectionGroup('iterations') query surfaces every operator's nominees, and corpora/* supplies the corpus candidates. Each carries both version IDs, the prompt overrides, simScore, the personas.
2: Validation lens. Each surfaced component is coloured by what proves it true: 🟦 graph (a real node/edge), 🟪 hybrid (grounded + on-voice), 🟨 LLM (rendered language, no fabrication), 🟩 data (the user's own, never inflated), ⬜ fixed (static), 🟥 care (two-tier). The same ink key the Compositor's Bench uses — the Desk reads the proofs in the same colours.
3: Telemetry as the value function — advisory, never automatic. Two signals on the same beat-event axes: mechanism-fidelity (the sim-score — the cause-moments present in the transcript: did the run plant the return-hook → activation, land the attribution-receipt → committed, earn graduation? — the leading signal, not a metric forecast, uncalibrated until validated) vs outcome (real production / A-B telemetry, lagging). The score is view-only: it never auto-ranks or auto-promotes (I8 / I10); humans pick, on outcome first.
4: The invariant floor — the one thing plumbed. A flag, not a ranker. The sim-score's invariant sub-layer — care (I15) · honesty / no-inflation (I17) · no-gate (I9) · no-fabrication (I7) · ≤55 words — hard-flags a candidate ineligible (simScore.eligible:false), a release-blocker, regardless of judgment. So an activation lift that degrades graduation or trips an invariant is a reject, not a win.
5: The compatibility guard. Because prompt × corpus are coupled, a lock or A/B is allowed only if the prompt's required corpus fields ⊆ the corpus version's retrievalInterface. The guard runs server-side at the moment of the lock / print-run (compatible()) and refuses an incompatible pair with the exact mismatch — preventing a corpus go-live from silently breaking a prompt that assumed an earlier shape.
6: The coupling. Prompt × corpus are not independent — the prompt's Block-3 template formats whatever the corpus retrieval exposes through ground(retrieval). So what goes live is a pinned (prompt × corpus) pair, every iteration stamps both IDs, and zero-variation holds: the engine chat path and the optimizer both read config/live — byte-identical, no deploy, one live pair at a time.