# 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.