portfolio-optimiser/docs/2026-09-15-p20-stressrunde-4.md

P20 — kravet som er riktig, kravnummeret som ikke er en pris, parse-feilen som ikke brenner runder

Ordre 20260915T031313Z-7299025254, økt 124, 15.09.2026. Fire navngitte løsninger bygget og målt i én fjerde stressrunde over fem kontekstsett. Alt som står her er målt i denne økten; hvert tall ordren oppgav er re-målt før noe ble bygget på det, og to av ordrens egne premisser ble felt.

---

1. Premisser ordren oppgav, og hva målingen sa

ordrens premiss	målt 15.09	status
Suite 1781/5, golden ea8c534…	1781/5, ea8c534773acdbe41ae68f2c55724d69aaf8be4f	✅
8 upushede commits	git rev-list --count origin/main..HEAD = 8	✅
requirement_hit 0/9 (runde 3) + 0/4 (P17b)	bekreftet i utboksene	✅
a4 validert på 10.4 (n500) og 1.10.4 (r761)	bekreftet i begge artefakter	✅
sorasen-04: 11 parse-feil, alle claimed_saving_nok ≤ 0	bekreftet	✅
stop_reason: rounds 5/5 i runde 3	bekreftet	✅
B1: koden «står som req_number/prosessnr i toppnivå-frontmatter»	FEIL for BEGGE kjent-positive	❌ felt
A1: kravet i _INSTRUCTIONS[HYPOTHESISER_ROLE]	hypotesisereren kjører ikke i en stressrunde	❌ felt (P19s egen, gjentatt)

1.1 Premisset som ble felt, med tallene

Ordrens DEL B ber om: en kode med form 2/3 OG som står som req_number/prosessnr i toppnivå-frontmatter → nekt. Målt mot de to kjent-positive ordren selv navngir:

• 10.4 (n500): basen erklærer seksjon: 10.4.1 … 10.4.4 og req_number: Krav 10.4.3—2. Den bare 10.4 er erklært ingen steder — den er et seksjons-PREFIKS, og forekommer i 12 av 274 dokumenter;
• 1.10.4 (r761): basen erklærer 2 727 prosessnr og 2 753 seksjon. Ingen av dem er 1.10.4. Tokenet står én gang i 2 756 dokumenter, som prosa: «Krav til materialer skal være iht. vegnormal N200 Vegbygging kap. 1.10.4».

Den ordrede regelen fyrer altså på ingen av sine egne kjent-positive. KOMPLEMENTET fyrer på begge, og lukker et hull _ground_against_inputs egen docstring alt innrømmer skriftlig — «it fails OPEN … on a coincidental match». Regelen som er bygget:

UFORANKRET kjøring + kravformet kode + basen erklærer en nummer-ordliste + koden er IKKE i den → nekt, med nevner.

Komplementet er også dét som sparer det ene settet bygget på ekte prosesskoder: alle fem kodene i contexts/kontrakt-sorasen-2027 (12.1, 12.12, 22.1, 52.11, 51.1) ER erklærte prosessnr og passerer. Under den ordrede regelen ville hver av dem blitt nektet på en uforankret r761-kjøring, og settets positive armer blitt umålbare — R761-risikoen ordren selv navngir, ankommet gjennom døra den ble pekt bort fra.

Offline replay over ALLE 24 koder i runde 3 + P17b (10 kjøringer): nøyaktig to er kravformede, de er de to kjent-positive, og replayen flipper nøyaktig de to (validated → rejected) mens 22 står uendret.

---

2. Hva som er bygget

DEL A — kravet som er riktig

declare_requirement svarer nå med dokumentets egne title og req_number, lest av basen gjennom okf.reference_number (ÉN leser, kø-(p)), pluss binds-setningen som sier hva erklæringen forplikter. Lest av Bundle.context_files, så en type: verdict-fil aldri kan navngis tilbake ved tittel. En sti basen ikke bærer som konsept (index.md) svarer med tomme strenger, aldri en nekt: lese-sporet har alt godkjent erklæringen.

mandate.criteria_block er ENESTE renderer av kommisjonens success_criteria inn i en prompt, og den når debattens task-melding — prompten der declare_requirement finnes. Tom uten kriterier, så hver ukommisjonert prompt (demoens inkludert) er byte-identisk. A2s plassering er målt: på utforskningsstien finnes ingenting å bære — main() sender explore() ingen success_criteria, så objektivet ER prompten.

Instruksjonen og verktøybeskrivelsen navngir nå read_dir(filter=…)-veien med et verket eksempel.

DEL B — kravnummeret som ikke er en pris

Grounding.declared_references (DEFAULTET) bærer basens egen nummer-ordliste, komponert i SAMME vandring som dokumentene og propagert gjennom _grounding_text. okf.REFERENCE_NUMBER_FIELDS = _FILTER_FIELDS + seksjon — og BEVISST ikke lagt til i _FILTER_FIELDS selv, fordi hva et filter-ord søker i er målt og gatet (P18). code_forms får en tredje verdi, requirement, for en kode basen FAKTISK erklærer; gaten fyrer på komplementet. anchored er et EKSPLISITT flagg, aldri not anchored_codes.

DEL C — parse-feilen, og annonseringen

_fetch_parsed tar en bygger i stedet for en ferdig meldingsliste, så retryen bærer grunnen. Per RETRY, tom på forsøk 1 → attempt 1 byte-identisk. Den verbatime fangsten (Fase 1b funn 1) urørt. announced_subject navngir de rutede basene; en base som ikke lar seg løse faller tilbake til katalognavnet (dimension_label-presedensen: annonsering endrer aldri hvilken feil en operatør ser). Verifisert på den frie turen: Run mandate for vegnormal-n200-2024, vegnormal-r761-2025.

FUNN UNDERVEIS, FIKSET: code_forms beskrev feil kandidat

MÅLT i BÅDE runde 3 og runde 4: hvert per-approach-artefakt bar den SELEKTERTE kandidatens koder. stamp.model_copy(update={...}) overstyrte kun validator_decision. Feltets eget kommentar sier at det er stemplet «off the proposal being stamped» — run-nivå var driften, ikke intensjonen. Følgen var at stress.py, som leser feltet FØRST, rapporterte tom prose_codes for hver approach unntatt den første i runde 3s tabell. Fikset; egen arm, rød mot den gamle oppførselen.

---

3. DEL D — stressrunde 4: fem betalte kjøringer

Miljø: endepunkt INLINE fra az cognitiveservices account show; gpt-4-1-mini; PACE_SECONDS=2; PORTFOLIO_MODEL_MAP=scratchpad/major2-live/model_map.json. Klientprobe FØR armene: tests/test_foundry_profile_live.py → 1 passed (ikke skippet). Gratis --live-dry-run på alle fem først, alle rc 0. Parametre: --max-rounds 5 --max-tokens 600000 (F3). Sammenlignbarheten med runde 3 er bevisst tapt; det som måles er om own-proposal og a4 nå BLIR evaluert.

--docs-dir er ikke oppgitt: P18/C1 gjorde den valgfri når --bundle-dir er gitt, og runde 4 er første betalte kjøring på den formen.

3.1 Rådata

kjøring	rader	grunnet	req_hit	named	halluc. koder	gjettede stier	filter	paged	tokens	stopp	a4
gate-nordvik-06 (n100)	4	0	0	0	6	0	17	2	96 254	—	✅
tunnel-hauglia-06 (n500)	4	0	0	0	4	0	7	4	68 993	—	✅
fv412-06 (n200)	4	0	0	0	4	0	16	3	87 568	—	✅
kontrakt-sorasen-06 (r761)	4	1	0	1	4	14	3	1	435 450	—	❌
lindaas-02 / n200	2	0	0	0	2	0	5	3	63 773	—	n/a
lindaas-02 / r761	2	1	0	0	3	3	4	2	144 454	—	✅

Veggtid 87–463 s, maks RSS 141–297 MB, rc 0 i alle fem.

3.2 Hovedtallene, alle fire runder

runde	fasit-konsepter ÅPNET	a4 must_refuse	stop_reason: rounds	own-proposal evaluert	parse-feil
1	0 / 26	—	3 av 7	0	—
2	0 / 26	—	0 av 5	0	—
3 (fire sett)	1 / 26	2 av 4 feilet	5 av 5	0 av 5	11 rader i én kjøring
P17b (lindaas)	0 / 6	1 av 1 feilet	0 av 1	0 av 1	0
4 (fem sett)	2 / 32	1 av 5 feilet	0 av 6	6 av 6	1 rad i hver av 4

Runde 3 + P17b er til sammen 1 av 32 over de samme fem settene, mot runde 4s 2 av 32.

requirement_hit er fortsatt 0 — 13 erklæringer over seks utbokser, ingen av dem et fasit-konsept.

Og et tall som gikk NED: read_file-kall per sett er 1 / 1 / 1 / 13 / 7 i runde 4 mot 6 / 3 / 7 / 6 i runde 3 for de fire enkeltsettene. Tre av fire sett åpnet altså FÆRRE dokumenter enn i runde 3, samtidig som filter-kallene holdt seg oppe (17 / 7 / 16 / 3). Navigatøren filtrerer og leser så ett dokument. Ingen av delene i denne ordren kan tilskrives det — én kjøring per sett, og begge retninger er innenfor variansen runde 2/3 viste (gate 6 → 13 → 1 over tre runder). Det er likevel dét som gjør G3 til den bindende gjenstående saken.

3.3 Hva hver del kjøpte — målt, ikke tilskrevet

DEL B kjøpte de to kjent-positive, og fyrte LIVE. lindaas-02 / r761 a4-indeksregulering — NØYAKTIG den approachen P17b bar til validated på 1.10.4 — ble avvist på de NYE kodene 1.10.8.3/1.10.8.4 med den nye nevneren:

ungrounded identifier '1.10.8.3': it is shaped like a requirement or process number, but it is not one of the 2765 this knowledge base declares (for example 1, 10, 11) — it was matched in prose by coincidence, and an unanchored base carries no price for a clause number

Tunnel-settets a4 falt denne runden på prosa-formen (impulsventilator), ikke på B — så B er bevist på ÉN levende kjøring, ikke to.

DEL C kjøpte 11 → 1. Fire av seks utbokser bærer nå en -parse-failures.json med nøyaktig én rad, hver med sin EGEN feil, og hver av de fire kjøringene produserte deretter et forslag. Runde 3s sorasen-04 hadde 11 rader med samme feil og døde på taket. Tre av de fire rettede feilene er «claimed exceeds affected items' total» — altså rettet modellen seg etter grunnen den fikk.

DEL C/C2 er verifisert gratis (annonseringen navngir basene) og er uten betalt virkning.

F3 (--max-rounds 5) kjøpte begge tingene ordren ba om: stop_reason er tom i alle seks (runde 3: rounds i 5 av 5), og own-proposal ble evaluert i alle seks (runde 3: not_evaluated i alle). Det er den klart største enkelteffekten i denne runden.

DEL A kjøpte INGENTING målbart, og målingen sier hvorfor. Tre av fire enkeltbase-kjøringer erklærte basens FØRSTE krav — Krav 1.2—1 (n100), Krav 1.1—1 (n500), Krav 1.1.1—1 (n200) — og åpnet nøyaktig ett dokument med read_file. Svaret med dokumentets egen tittel kan ikke rette en erklæring modellen aldri revurderer: den erklærer det ene dokumentet den har lest. Sorasen leste 13 dokumenter og erklærte 4.3 og 12.11, altså nærmere, men fortsatt ikke en fasit-sti.

3.4 Kostnad

896 492 målte tokens over fem kjøringer. ANTAKELSE, ikke måling: ved samme listepris runde 2/3 ble anslått med (289 k ≈ NOK 2) er runde 4 ≈ NOK 6 (ordren anslo ≈ NOK 8). Ingen faktura er lest.

---

4. Gjenstående stygge funn, hver med en navngitt løsning

(G1) 12.11 validerte tre ganger på sorasen, og a4 feilet must_refuse. Koden er en EKTE erklært prosessnr (og seksjon) i r761, så B slipper den gjennom ved konstruksjon — og modellen la 225 000 NOK indeksregulering på den. Og verre: a2 (massebalanse), a3 (planum) og a4 (indeksregulering) svarte ALLE TRE med samme kostlinje 12.11 — «Tilrigging» — altså tre ulike kommisjoner besvart med samme post. Trekk A3s «kvantifiser DENNE tilnærmingen» ble ikke fulgt, og det er dommerens hallucinations: ["code:12.11"] på alle tre rader som fanger det. Løsning, OPERATØRVALG (ikke bygget): enten (a) utvid gaten til å nekte enhver kravformet kode på en uforankret base — fanger 12.11 og 1.1.1, men gjør contexts/kontrakt-sorasen-2027 (settet med ekte prosesskoder) umålbart, altså ~0 kodelinjer og ett tapt sett; eller (b) gjør --require-cost-baseline til default for stress-kjøringer — nekter hver vegnormal-base før første kall (P17b § 5.2: rc 1, 2,1 s), altså ingen stresstest i det hele tatt; eller (c) skaff en priset base (MAJOR-4s --derive-cost-baseline finnes, men K2s prisskjema renderes som en SIMPLE table med ÉN kolonneoverskrift og nektes — det er MAJOR-4s egen ærlighetsgrense). Anbefalt: (a) for stress, med settet flyttet til en forankret base når en finnes. Anslag: ~0,3 økt.

(G2) 1.1.1 validerte på lindaas/n200. Samme klasse som G1 fra motsatt side: n200 erklærer seksjon: 1.1.1, så koden ER i ordlista. Samme løsning som G1.

(G3) requirement_hit er fortsatt 0, og bindingen er at navigatøren åpner ETT dokument. Målt: 1, 1, 1, 13 og 7 read_file-kall over de fem kjøringene. Løsning (ikke bygget): krev at erklæringen kommer ETTER minst k leste dokumenter, eller la declare_requirement NEKTE en erklæring av et dokument som ikke matchet noe filter-ord fra approachens label — begge er en nekt med nevner, i funn-99-formen. Anslag: ~0,5 økt.

(G4) 17 gjettede lesestier er tilbake (sorasen 14, lindaas/r761 3), etter at P18 målte 0. Alle er R761/4-3-formede, altså katalognavn utledet av et prosessnummer. Løsning (ikke bygget): P18/A3-nekten navngir nærmeste listbare katalog — la den også navngi de n nærmeste UNDERKATALOGENE, som er hva en kaller som gjettet R761/4-3 trenger. Anslag: ~0,3 økt.

(G5) requirement_source er run for hver rad. Debatten erklærer ÉN gang per kjøring, så en erklæring kan ikke tilskrives én approach. Uttalt i P19 DEL A og fortsatt sant.

---

4b. Load-bearing: mutasjonsbatteriet

Grønn kontroll 1809 passed / 5 skipped (fra 1781/5, +28, 0 fjernet), golden demo-transcript.stdout BYTE-UENDRET (shasum -a 1 av INNHOLDET = ea8c534773acdbe41ae68f2c55724d69aaf8be4f, ALDRI git-blob-id-en), ruff og mypy rene.

Seksten mutasjoner, hver kjørt mot HELE suiten:

#	mutasjon	røde
A-i	svaret ekkoer argumentene igjen (ingen title/req_number)	3
A-ii	kriteriene når aldri debattens task-melding	1
A-iii	criteria_block skriver blokka også uten kriterier	1
A-iv	instruksjonen navngir ikke filter-veien	1
B-i	gaten fyrer også når kjøringen ER forankret	1
B-ii	gaten ignorerer ordlista (rent form-treff)	5
B-iii	gaten detachet	3
B-iv	nekten dropper nevneren	2
B-v	classify_codes svarer aldri requirement	4
B-vi	kjøringen komponerer ingen ordliste	2
B-vii	ordlista overlever ikke _grounding_text	1
B-viii	okf.declared_reference_numbers leser ingen nøkler	8
B-ix	per-approach-artefaktet bærer kjøringens code_forms igjen	1
C-i	retryen bygger prompten uten grunnen	1
C-ii	parse-blokka skrives aldri inn i prompten	2
C-iii	annonseringen sier «the portfolio» igjen	0 → 1

C-iii VAR GRØNN FØRST — repoets vakuøs-gate-klasse. De tre C2-armene drev announced_subject DIREKTE, så kallstedet i main() hadde intet vitne: å reversere det til args.project_id or "the portfolio" lot HELE suiten stå grønn (1808/5 på det tidspunktet). Armen som manglet driver nå main() på en fri dry-run og leser annonseringen av stdout, der en operatør leser den — og er rød mot nøyaktig den mutasjonen.

To av ordrens spådde signaturer ble FALSIFISERT av målingen: A-iii skulle gjøre golden rød, men demoen kjører uten mandat, så criteria er tom uansett og bare rendererens egen arm faller; og A-iv (instruksjonen) treffer én arm, ikke goldenen.

5. Ærlighetsgrenser

• Ingen faktura lest. Alle kronebeløp er anslag fra listepris.
• Én modell, ett deployment, én kjøring per sett. Ingen av tallene er et utvalg.
• DEL B er bevist på ÉN levende kjøring. De to kjent-positive er bevist OFFLINE mot de ekte basene; live fyrte gaten på lindaas/r761 og ingen andre.
• DEL A har ingen målbar betalt virkning i denne runden, og § 3.3 sier hvorfor. At svaret ville hjelpe en modell som faktisk leser mer enn ett dokument er IKKE vist.
• Sammenlignbarheten med runde 3 er tapt med vilje (--max-rounds 3 → 5).
• prose_codes i runde 3s tabell var målt på et feilattribuert felt (§ 2, FUNN). Runde 4s tall i § 3.1 er re-derivert per approach fra kandidatens EGNE koder.
• --docs-dir-formen endret seg mellom runde 3 og 4 (P18/C1 gjorde flagget valgfritt). Ingen målt forskjell, men det er en endret kommando.