CompanionCourt — Model Rerun Policy

Version: v1.0 · Status: launch version. What this is: one of three governance policies of a public docket for pressure-testing AI companions. Models drift, gateways swap backends, corpora evolve — this policy says when a respondent is re-tried, and promises the one thing a docket must never do: rewrite its own history. The court judges AI companions, never the people who talk to them; and it judges the model that actually ran, pinned in the manifest, not the model a vendor wishes had run.

v1.0 changelog (launch): finalized from v0.1-draft; the four [DRAFT-CALL]s resolved by maintainer ruling — §1.1 drift is flagged "rerun pending," not auto-rerun; §1.2 vendor rerun rate limit; §1.3 post-bump queue priority; §1.4 time-rerun cadence.

1. When a rerun happens

1.1 Model version change (alias drift)

The manifest records the provider-observed response model and system fingerprint, and the anchor pack is periodically re-verified — so a provider silently swapping the model behind an alias is detectable. When drift is detected:

• existing verdicts stand, labeled with the manifest they were earned under;
• the drifted alias is treated as a new respondent configuration and is eligible for a fresh N ≥ 3 run;
• the report keeps the two configurations in separate identity rows — drift is displayed, never averaged away.

Ruling: a detected drift does not auto-rerun a publicly reported respondent. The affected verdicts are flagged "version-drifted, rerun pending" and stand under the manifest they were earned on; the rerun is scheduled for the next Docket Update, not fired the moment drift is seen. Detection surfaces a fact on the record; it does not silently replace one.

1.2 Vendor request (via right-to-reply)

A publicly evaluated party may request a rerun through the right-to-reply channels — typically alongside a version/prompt mismatch note (their production configuration differs from what was evaluated). Admissibility of a rerun request:

1. it identifies the specific configuration difference (model version, endpoint, serving parameters) with evidence — not a general dissatisfaction with the verdict;
2. the requested configuration is publicly reachable through the standard adapter, under the same frozen friend prompt as every other respondent;
3. it is filed on the record and is processed in the same monthly batch cadence as appeals.

A granted rerun produces a new versioned run under the new configuration. It never amends, replaces, or unpublishes the prior verdict; the mismatch note is annexed to the old report, and the new report links back. Rerun requests, like every reply channel, cannot influence case selection — and a vendor's paid or invited engagement never counts as an independence signal. Rate limit (ruling): one granted rerun per respondent, per model version, per corpus version — enough for a genuine fixed-it, never enough to shop for a friendlier draw.

1.3 Corpus version bump

A new corpus version means a new frozen anchor pack, and results never migrate: runs on corpus vN and vN+1 are different records, and a report refuses to aggregate across corpus hashes. After a bump, previously reported respondents are queued for rerun on the new version before any cross-model comparison is published on it. Queue priority (ruling): precedent-bearing cases first, then must-hold cases, then the rest — the records that carry the most doctrine and the most weight re-establish themselves first.

1.4 Scheduled time-rerun (stability governance)

Independently of any trigger, the same configuration is re-run after an interval to measure time-rerun stability — surfacing gateway and backend drift that no single manifest can show. This is a post-launch governance duty, published as a stability note, not as a fresh verdict. Cadence (ruling): quarterly, on one designated reference respondent — not the full slate. A single stable reference is enough to detect gateway and backend drift; a full-slate re-run every quarter would be cost without added signal.

2. How history is preserved

• Verdicts are immutable. A published verdict is never edited, overwritten, or unpublished by a rerun. Corrections of factual errors in a report happen through the technical-correction channel and are published as annexes, on the record.
• Every run is a new versioned record: new runId, new manifest, new report. The old and new reports coexist, each pinned to its corpus version, anchor pack hash, and observed model identity.
• Precedent never flips a non-disputed verdict, and no rerun retroactively applies newer rulings to older records.
• The public record therefore reads like a docket, not a leaderboard cache: you can always see what was true, when, under exactly which pins.

3. What a rerun is not

• Not an appeal: an appeal challenges a reading of existing evidence; a rerun creates new evidence. Filing one is never a precondition for the other.
• Not a negotiation: no rerun request, granted or refused, moves a case in or out of the corpus.
• Not an eraser: "we fixed it" earns a new verdict next to the old one — that ordering is the docket's memory, and its value.

---