Solar Voice · The Limited Print Run — A/B Experiments (Pioneer Console)

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 limited run is judged in the same ink — readership response

The Limited Print Run

— A/B on a definable share of readers

CAPABILITY 3 · EXPERIMENTS

Set a proof on a fraction of the readership.

Before the imprimatur, the Desk orders a limited print run: route a definable % of users to a variant (prompt × corpus) pair, watch readership response on the same beat-event axes, and release-to-all only when it actually wins. Routing is deterministic and app-cached — no added latency.

No latency cost

resolveVersion(uid) buckets each user from a hashed uid, reads the cached config/live or the variant per experiments/{id}, and defaults to live when no experiment is active — zero per-turn Firestore hit.3

Order a Print Run

— variant · scope · share

writes experiments/{id}

Scope of the run — what moves between A and B

Prompt Corpus Pair

Pair — move both promptVersionId and corpusVersionId at once. A variant is always a coupled bundle; pair-scope changes the whole point.

Variant A — control = the live edition

reading config/live…

Variant B · the candidate — a nominated iteration (uid, id)

Variant B is materialized from a nominated proof's edited blocks on start (its promptVersionId is written then). Nominate candidates on the Proof Spike · the Bench.

Variant B · corpus — the stock it reads

Variant B pair pick a candidate

Share routed to Variant B — percentB · 1–50 cap

12%

1%10%25%50% (cap)

Variant A · the live pair Variant B · the candidate

Pre-flight · compatibility guard

the coupling guard runs server-side on start

The Routing Read-Path

— resolveVersion(uid)

deterministic · cached · zero added latency

incoming hash(uid) stable per user — same reader, same bucket, every turn

→

read · app-cached experiments/{id} active run? else fall through to config/live

↳ bucket lands in one of two editions

—

Variant A — the live edition (default)

reading config/live…

—

Variant B — the candidate pair

pick a candidate

Zero-variation

The engine chat path and the optimizer both resolve through this one read — so a bucketed reader gets the byte-identical pair the sim ran. The experiment is a config flip, no deploy.7

On the Press Now

— active runs · live readership monitor

Advisory · not automatic

Pick the winner on outcome first (real readership response — the lagging signal), then sim. The sim-score is a lens; it never auto-promotes a variant (I8 / I10). An activation lift that degrades graduation or trips an invariant is a reject, not a win — graduation is the North Star; activation is only its leading indicator.5

Loading active runs…

The Run Ledger

— every experiments/{id}

Run ↕	Variant pair (B)	Scope ↕	% B ↕	B turns ↕	B activation ↕	Status ↕
Loading the run ledger…

Activation is real version-stamped telemetry (joined days→run→arm); committed-30d / graduation depth accrue over time and are not fabricated here. One live pair at a time — releasing a winner supersedes the prior edition and routes everyone, subject to the imprimatur grant on the next screen.8

Marginal Apparatus · Operational Anchors

1: The limited print run. An A/B experiment: route a definable share (percentB) of users to a variant edition while the rest stay on the live one. Writes experiments/{id} { variantA, variantB, percentB, scope, status }. A variant is itself a coupled (promptVersionId, corpusVersionId) bundle — scope:'pair' moves both at once.
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 readership response in the same colours.
3: The routing read-path. resolveVersion(uid) deterministically buckets a user from a hashed uid into the live pair or an experiment variant per experiments/{id}, app-cached (module TTL, no per-turn Firestore hit), defaulting to config/live when no experiment is active. Same reader, same bucket, every turn — and no added latency.
4: The coupling. Prompt × corpus are not independent — the prompt's Block-3 template formats whatever the corpus retrieval exposes (ground(retrieval)). So a variant always stamps both IDs, and a run is compatibility-guarded server-side: route only if the prompt's required fields ⊆ the corpus's retrievalInterface. A blocked variant returns an HTTP 409 with the field reason before it can route a single reader.
5: Advisory, not automatic — and the reject-rule. The sim / beat-fidelity score is view-only; it never auto-ranks or auto-promotes a variant (no auto-mutating loop — I8 / I10). The pioneer picks on outcome first, then sim. Activation is the leading indicator of graduation, never a substitute — a variant that lifts activation but degrades the North Star (graduation) or trips an invariant is a reject, not a win.
6: Release-to-all. When a variant wins on real outcome (and the floor holds + the guard is ok), the pioneer flips the winner to config/live — every reader routes to the winner and experiments/{id}.status='released'. This becomes the live pair (its own audit entry). No deploy at any step.
7: Zero-variation. The engine chat path and the optimizer resolve the same way through resolveVersion / config/live, so a bucketed reader receives the byte-identical pair the simulation ran. If they could diverge, the experiment would be measuring a fiction.
8: One live edition at a time. Only a single config/live pair is in force; releasing a winner supersedes the prior edition. The backend allows exactly one active experiment against the live baseline — stop or release it before ordering the next.