Score-series changes

This register identifies shipped changes that can alter a score series, its attribution, eligibility or statistical meaning. Use it when interpreting a before/after figure or re-deriving a historical period. It is a seed register, not proof that an installation's complete definition history is known. Eligibility-only changes must be recorded separately from scoring changes: a ranking gate can withdraw ranking or an interval without changing the points or headline. Attribution and inference changes are labelled separately below.

Comparison rule

Compare figures under the same measurement definition. If a scoring, pricing, attribution or eligibility change affects either period, label the comparison 'definition changed' and name the change. Historical sealed bytes remain unchanged; a revised live derivation is a separate observation. A comparison across a break names the break's row; a published comparison either names its applicable entries or states that the definition history is unknown.

Reading the register

All timestamps below identify shipment to main, not inferred deployment or operator activation times. Non-price rows use the merge commit's committer time, measured with git log --format='%H %cI' -1 <commit> and converted to UTC; price rows use gh pr view <PR> --json mergedAt, retaining the file-change SHA as a secondary citation. A table's effective_date is not its shipment timestamp. Cited SHAs and PRs are in the private development history; public readers cannot resolve them. Installation activation times are unknown unless separately recorded; #823 is opt-in and Event 3 scoring is OFF by default. The four Event 3 rows record shipped capabilities, not four activated score breaks. Price v1 is the baseline, with unchanged default values, included to account for every table version.

Effect types describe when the change reaches observations:

• prospective: new insertion/capture, or a newly priced scan, uses the shipped rule after deployment/opt-in. It does not by itself rewrite stored history.
• live-retroactive: reading existing inputs under a new method, re-ingesting earlier outcomes, or a guarded fill of earlier unsealed usage can change a live historical derivation.
• explicit-apply: an operator deliberately applies a historical change. A dry run is not activation. Record the actual apply time, scope and receipt in its own row; the shipped tool or price-table date is not that receipt.

Pricing surfaces

For each price row, headline and segments can move through cost; shares weighted by dollars and interval can move with the affected cost mix; flags about unknown/guessed rates can change when a model gains a row, while the token-count tripwire is unchanged by rates alone; eligibility can change at a cost floor. These are pricing changes, not changes to outcome weights. A row addition leaves previously listed rate values unchanged but can replace fallback pricing for matching usage. An existing-rate correction changes the pricing definition for an already listed model. At read time, premium-model share, fidelity unknown-model dollars and the unknown-pricing token share classify historical inputs against the active table without changing stored cost, so model coverage or premium-threshold changes can revise those live historical surfaces; even a rate-only version change can alter the unknown-pricing flag because the stored price version differs from the active version.

Neither kind of table revision automatically updates stored cost_micro. Ordinary re-shipping keeps the stored cost. Newly captured rows and fresh scans use the active table; changing historical stored prices requires an audited tierd reprice --commit operation with its own explicit-apply row. No such installation apply date has been established for this seed. At fixed points, lower total cost raises TIER and higher total cost lowers it; where token/model mix does not establish a direction, the table says unknown. See the reference price table and reproducibility contract.

Sealed-report treatment

Every row follows R-2026-09-29-11: sealed report bytes never change. Config changes apply from the first unsealed period and cross-config sealed comparison is refused. Recomputed live history is a separate observation, never a replacement of the sealed report. Earlier rows predate sealing; the same preservation rule governs their use today.

Shipped register

Shipped, inactive

Dormant shipments record capability availability. Activation adds a second row under the maintenance rules below.

Pending — added by their own PRs on activation

No activation dates are assigned here:

• Fix 1 exclude-reverts historical discovery/apply (#1277).
• Fix 2 trigger_event cutover.
• Fix 5 attribution floor (record eligibility/withholding separately from scoring).
• Event 3 RubricVersion activation (the default-off shipments above are not activation).
• U86 tripwire and its propagated scoring/sealing inputs.
• U84 inference method selected after the study.
• #489 read-time recovery.
• U93 correction overlays.
• Cost promotion and poller cutovers.

Maintaining this register

A PR that changes scoring, pricing, attribution or eligibility adds its own row in docs/score-series-changes.md.

This is an acceptance condition for every fix-plan PR, including an eligibility-only change. Dormant shipments get a shipped, inactive row; activation adds a second row. A default flip adds a row by PR. A per-install enablement is recorded with that install's time and receipt, never as a product-wide row here. Do not substitute a planned date for measured evidence. Retain measured shipment evidence; record actual activation/apply timestamps and receipts in the appropriate product-wide row or installation record when known. Record a rule id (or unknown), the six surfaces, direction, effect type, sealed treatment and comparison conditions. Keep prospective insertion, revised live derivation and explicit historical application distinct. Record each timestamp's measurement command in the commit message. A published comparison names its applicable rows or states that the definition history is unknown.