Ordrens fase 1: mal hvor SavingsProposal-feltene kommer fra i dag, og hvilke som
kan avledes deterministisk fra mandatet, den deriverte baselinen eller den rutede
tilnaermingen.
PREMISSET ER FELT FOER NOE BLE BYGGET PAA DET. Symptomet er bekreftet - en base
uten validator-input.json nekter med FileNotFoundError foer foerste modellkall.
Men forslaget har aldri blitt lest fra den fila: SavingsProposal konstrueres av
generate._parse_ir fra MODELLENS svar. Fila er en fasit ved siden av kjoerestien.
Det som blokkerer er at den er en paakrevd inngangsbetingelse for prosjekt-
IDENTITETEN. Skillet avgjoer at S7b er TO soemmer, ikke en.
NEVNEREN: tre kallsteder leser IR-projeksjonen, ikke ett - run.py:453
(hver bundle-kjoering), verdicts.py:507 (kun naar storen er ikke-tom) og
run.py:1662, dispatcherens rutingsnoekkel, som bevisst ikke tar project_id fordi
den leser den derfra. En ingestert base kan derfor ikke rutes i det hele tatt.
MAALT som IKKE i veien: derive_cost_baseline trenger ingen validator-input.json
(3 linjer ut av MAJOR-4-fixturen, 2 ut av en syntetisk base uten fila; det
uprisede skjemaet nekter fortsatt i sin helhet). Forankringen er paa plass; det
som mangler er en kandidat aa forankre.
TABELLEN tvinger fram tre ting fase 2 maa avgjoere: anslaget og kostkodene
finnes IKKE paa Approach eller Mandate i dag (maalt: fire hhv. fire felt, null
tallfelt); measure er ikke bare prosa men METHOD_CAPS-oppslagsnoekkelen, saa en
label treffer aldri metode-cap-en; og tom assumptions gjoer Monte Carlo inert
(P10 == P50 == P90) mens persentiler fortsatt printes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Kjell Tore Guttormsen
19badcd0fe