Skip to content
All RFCs
RFC-0001acceptedopened 2026-04-25

Rubric versioning policy (v1.x cadence + diff format)

How the Lyric Scoring Standard versions: when a bump happens, what gets published with it, and how third parties verify which rubric scored their lyrics.

Motivation

The Lyric Scoring Standard ships as v1.0 with a CC BY 4.0 license. That published surface is now load-bearing — third parties cite it, the model card references it, the reproducibility seal in `/api/v1/score` embeds the version in every response.

What's missing: a public policy on how the version actually moves. A rubric change without a version bump silently breaks every cited score. This RFC pins the policy.

Proposal

Versioning scheme

The standard follows semantic versioning with rubric-specific semantics:

  • **MAJOR** (e.g. 1.0 → 2.0): a metric is added, removed, or has its definition changed in a way that alters scores by more than 5 points on the golden-eval corpus.
  • **MINOR** (e.g. 1.0 → 1.1): a metric's evidence requirements or scoring band labels are clarified, or anti-inflation rules are refined. Score deltas under 5 points on golden-eval.
  • **PATCH** (e.g. 1.0.0 → 1.0.1): typo fixes, expanded examples, or any change with zero score delta.

Cadence

  • MAJOR bumps require an accepted RFC and a 30-day notice window before they take effect on the public scoring API.
  • MINOR bumps require an accepted RFC and a 7-day notice window.
  • PATCH bumps ship inline with the docs change.

What ships with every bump

  • Updated `public/scoring-standard.json` with new `version` and `changelog` entries
  • Updated `/scoring/standard` page with the new version chip
  • Updated golden-eval baseline so the regression gate locks the new behavior
  • Migration note in the RFC's "resolution" section explaining what changed and why

Reproducibility consequence

The seal field already in every `/api/v1/score` response carries `rubricVersion`. After a bump, third parties caching scores under the old version remain reproducible by querying the `/api/v1/score?rubricVersion=1.0` endpoint (future addition — out of scope for this RFC, will be its own RFC).

Out of scope

  • The actual content of v1.1 (separate RFC when proposed)
  • A pinned-version query parameter on the score API (future)
  • Rubric forking / community variants (future)

Comment window

This RFC is open for comment until 2026-05-02. Email support@songforgeai.com with the subject `RFC-0001` to leave a comment. All received comments will be summarized in this document's resolution section.

Resolution

**Accepted as-written, 2026-05-02.**

Comment window closed without proposed amendments. One clarifying question received via support@songforgeai.com:

Q: Does a PATCH bump (1.0.0 → 1.0.1) require any public artifact, or is a commit message sufficient? A: Commit message + a one-line entry in the scoring-standard.json changelog block. No RFC required. The artifact requirement is what distinguishes MAJOR/MINOR from PATCH.

The policy is now load-bearing. Every score response since B1818 (when the reproducibility seal was repaired) carries `rubricVersion` per this contract; every future rubric bump ships under this discipline. RFC-0002 (Anti-Platitude rule) is the first MINOR bump shipped under this policy + closes in parallel with this one.