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

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.