docs(plan): S3 — comparison protocol (pinned ref, metrics, liveness asymmetry)

Defines the S11 yardstick BEFORE either stack exists: pinned commons-ref
as identical input, metrics M1-M4, the verbatim liveness-asymmetry
declaration, five binding LLM non-determinism rules for S10/S11, and a
ban on comparing offline numbers with live numbers.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AaQCFnfsh3tfq1VfzdJpoi

docs/plan/2026-07-03-sammenligningsprotokoll.md

@@ -0,0 +1,68 @@
+# Sammenligningsprotokoll — to stacker på identisk delt kjerne (S3 → S11)
+
+> **Hva dette er:** Målestokken for programmets sluttleveranse (målbilde §1: rettferdig
+> sammenligning av to uavhengige implementasjoner av samme metode). Protokollen defineres FØR
+> ekstraksjon (S4) og FØR søskenrepoet finnes (S5), slik at ingen av stackene kan forme
+> målestokken etter eget resultat. Metrikkene er definert uavhengig av rammeverkenes interne
+> begreper — begge stacker måles på samme kontrakter (delt kjerne + golden-suite + spec).
+
+## 1. Identisk input: pinned commons-ref
+
+- Sammenligningen (S11) kjøres mot **én pinned ref** (commit-hash eller tag) av den delte kjernen
+  (`portfolio-optimiser-commons` etter S4): OKF-bundle, `golden.json`/`validator-input.json`,
+  expert-reviewer-personaen og `method-spec.md` — 13 filer per 2026-07-03.
+- Begge repo skal peke på samme ref (subtree-commit / dokumentert hash), og hashen føres i
+  S11-rapportens verifiseringslogg. Endres kjernen etter pinning, re-pinnes og re-kjøres begge
+  sider — aldri én.
+- Konsummekanisme: hver stack leser kjernen via sin egen resolver (MAF-siden:
+  `PORTFOLIO_SHARED_ROOT`, S3); ingen stack får en privat, avvikende kopi.
+
+## 2. Metrikker
+
+| # | Metrikk | Type | Kilde |
+|---|---------|------|-------|
+| M1 | **Validator-samsvar mot golden** — alle besluttede felt i `golden.json` reproduseres av stackens deterministiske validator på `validator-input.json` (inkl. MC-prosedyren i spec §7) | Kvantitativ, reproduserbar | Testsuiter begge repo, pinned ref |
+| M2 | **Konvergens/runder** — antall genererings-forsøk til validert forslag, antall debatt-runder, om refinement-sløyfa (forrige avslagsgrunn inn i neste forsøk) ble utløst | Kvantitativ | Kjøringslogg/provenance begge sider |
+| M3 | **Tokenforbruk** — forbruk mot forhåndssatt tak | Kvantitativ | MAF-siden: syntetiske tellinger (skriptet klient) — måler KUN at takene håndheves; Claude-siden: faktisk API-forbruk i S10 |
+| M4 | **Kvalitativ vurdering** — implementasjonskompleksitet (LOC kjerne, antall moduler), spec-troskap (avvik fra `method-spec.md` §12-tabellen), load-bearing-dekning (hvilke sømmer er detach-bevist), utvikleropplevelse | Kvalitativ, begrunnet prosa | Kode + testsuiter + STATE-logger |
+
+M2/M3-tall fra offline-kjøringer (skriptede stand-ins) måler **plumbing og takhåndhevelse**, aldri
+modellatferd — de sammenlignes bare med samme kategori på motparten. Kryss-kategori-sammenligning
+(offline-tall mot live-tall) er forbudt i rapporten.
+
+## 3. Liveness-asymmetri-erklæring
+
+Følgende erklæring gjengis ordrett i S11-rapporten:
+
+> **Liveness-asymmetri-erklæring:** De to stackene har ulik bevis-liveness, valgt av kostnadshensyn
+> (D6). MAF-siden kjøres ALDRI mot en ekte modell; dens bevis er et skriptet offline-bevis av
+> plumbing, deterministisk ryggrad og lukket læringssløyfe. Claude-siden kjører ÉN minimal ekte
+> API-kjøring (S10) som programmets eneste genuine modell-atferdsbevis. Sammenligningen påstår
+> derfor ALDRI noe om modellatferd på MAF-siden; enhver live-observasjon gjelder kun Claude-siden
+> og merkes slik der den siteres.
+
+## 4. Håndtering av LLM-ikke-determinisme (S10/S11)
+
+S10 er én enkelt kjøring, ikke et utvalg. Konsekvenser, bindende for S11:
+
+1. **Ingen statistiske påstander** om modellatferd (ingen «typisk», «gjennomsnittlig», «stabilt»).
+   Én kjøring beviser eksistens («modellen produserte et gyldig/ugyldig forslag under denne
+   konfigurasjonen»), ikke tendens.
+2. **Artefakter er fasit:** S10 persisterer forslag-JSON, checker-dom, tokentelling og
+   validator-utfall i output-laget. S11 analyserer de FANGEDE artefaktene — aldri en frisk
+   re-kjøring for å «bekrefte» eller forbedre et resultat.
+3. **Konfigurasjon loggføres:** modell-id, parametre, dato og forhåndssatt token-tak føres i
+   rapporten, slik at kjøringen er beskrevet selv om den ikke er reproduserbar bit for bit.
+4. **Deterministisk kjerne skiller lagene:** M1 (validator mot golden) er reproduserbar på begge
+   sider uansett LLM-utfall — ikke-determinismen er innkapslet i genererings-/domsleddet og
+   krysser aldri inn i valideringsmetrikken.
+5. **Utfall re-rulles ikke:** feiler S10-kjøringen på innhold (avvist forslag, checker-REJECT,
+   tak nådd), er DET resultatet som rapporteres. Én re-kjøring er tillatt kun ved teknisk
+   transportfeil (nettverk/auth), og re-kjøringen loggføres eksplisitt.
+
+## 5. Rapportkrav (S11)
+
+- Norsk forretningsdokument med **verifiseringslogg**: hver tallpåstand → kommandoen/kilden som
+  reproduserer den (jf. sesjonsplanens S11-kriterier).
+- Begge repo grønne på pinned ref; asymmetri-erklæringen (§3) ordrett; ingen påstand om
+  live-atferd på MAF-siden.