portfolio-optimiser/contexts/kontrakt-sorasen-2027/fasit.json
Kjell Tore Guttormsen 7b4f85d77c feat(p21): the PROJECT carries the price, so a run against a road normal can be anchored
Four paid stress rounds ran entirely UN-ANCHORED, all of them, because the one file
loader reads cost-baseline.json out of the BUNDLE and no vegnormal ships one: N100,
N200, N500 and R761 are knowledge, and knowledge carries requirements, never amounts.
The validator's stage 0 -- the one stage that tells an invented cost line from a line
this project actually buys -- was skipped in every single run, so "validated" could not
mean what it says. P20 G1/G2 measured real R761 process numbers (12.11 three times on
Soraasen, 1.1.1 on Lindaas) validating with amounts nobody had anywhere.

--cost-baseline FILE is PM decision (e), taken over the three alternatives P20 wrote
down. A LOADED object, never a path (prepass_payload's rule): the CLI owns the file and
loads it ONCE, so the notice, the stamp and every base of an --across-bundle pass all
descend from one read. ONE parse, two doors -- load_cost_baseline delegates to
load_cost_baseline_file -- while safe_resolve stays on the bundle door alone, because a
project's own schedule is legitimately outside every base. No tolerant twin: this path
exists only because an operator NAMED a file.

DEL B: five anchored context sets, a1-a3 with their line and a4 with none, so stage 0 is
what catches the falsification arm. THE ORDER'S OWN ARM (h) WAS FELLED BY MEASUREMENT:
"no baseline code is a requirement number the base declares" is measured 0 of 4 on the
project-coded sets and 5 of 5 on kontrakt-sorasen -- which is what R761 Prosesskoden IS,
a bill of quantities priced BY process code. The complement keeps both, and the order's
own mutation still bites.

DEL B3: the judge reports anchored (off the run's own stamp), priced per row, and WHICH
falsifier caught the falsification arm.

Load-bearing MEASURED, five mutations all red against the WHOLE suite, green control
1850/5 (from 1809/5, superset, 0 removed), golden byte-unchanged:
A3(i) the flag is read but the baseline is unused (3 red) . A3(ii) only the first base
gets it (1) . A3(iii) report_forbidden drops it (1) . B2(i) a4 gets a line (1, arm (g)
alone) . B2(ii) a code swapped to 12.11 (2, arms (f) and (h)).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-15 10:49:10 +02:00

70 lines
3.5 KiB
JSON

{
"project_id": "kontrakt-sorasen-2027",
"bundle": "r761-2025",
"bundle_id": "vegnormal-r761-2025",
"must_cite": [
{
"approach_id": "a1-rigg-omfang",
"rationale": "Rigg og drift er prissatt som rund sum over 22 måneder. Vi vil vite hva Prosesskoden legger i prosessen før vi kan kutte.",
"concepts": [
{
"path": "R761/12-1/_1_id-da516f46-786b-4e96-9511-da11ee07750f.md",
"title": "Rigg og midlertidige bygninger",
"ref": "12.1"
},
{
"path": "R761/12-12/_1_id-0d8e750e-18b1-49b9-b838-f5c29f21ff29.md",
"title": "Drift av rigg og midlertidige bygninger",
"ref": "12.12"
}
]
},
{
"approach_id": "a2-massebalanse",
"rationale": "Beskrivelsen har både uttak i linjen og tilkjørt filtermateriale. Spørsmålet er hva Prosesskoden krever av materialet i filterlaget.",
"concepts": [
{
"path": "R761/22-1/_2_id-54b5cb78-ba5e-4d30-a85d-d31facfde14d.md",
"title": "Sprengning i linjen",
"ref": "22.1"
},
{
"path": "R761/52-1/_5_id-d53022e6-0a09-4b02-bd37-21276fc2e51d.md",
"title": "Filterlag",
"ref": "52.1"
},
{
"path": "R761/52-11/_5_id-54270fce-705b-4f7c-fff0-0fea94ec0c08.md",
"title": "Filterlag av sand og grus",
"ref": "52.11"
}
]
},
{
"approach_id": "a3-planum-stabilisering",
"rationale": "Undergrunnen er beskrevet utskiftet. Vi vil vite hva prosessen for stabilisering av planum omfatter.",
"concepts": [
{
"path": "R761/51-1/_5_id-714020f6-3490-4dde-fe8f-c3d373f07d8f.md",
"title": "Stabilisering av planum",
"ref": "51.1"
}
]
}
],
"honesty": "Entreprisen Søråsen er KONSTRUERT av meg: kontraktsnavn, lengde, riggperiode og alle tre beløpene er oppdiktede størrelsesordener. Til forskjell fra de tre andre settene er affected_codes her EKTE prosessnumre fra R761 (12.1, 12.12, 22.1, 51.1, 52.11), lest ut av basens egen prosessnr-frontmatter — men R761 er en beskrivelsesstandard uten priser, så kodene er ekte mens beløpene ikke er det. must_cite er lest ordrett ut av basen. P16: den fjerde tilnaermingen a4-indeksregulering og dens kostkode INDEKS-01 er ogsaa KONSTRUERT, og med vilje: den er falsifiseringsarmen, en kostlinje basen ikke baerer grunnlaget for. Beloepet er en satt stoerrelsesorden. P21: settet har naa sin egen cost-baseline.json (5 linjer) — prosjektets prisskjema, kodet med de samme EKTE prosessnumrene, som er slik en norsk vegkontrakt faktisk prises. Mengdene og enhetsprisene er OPPDIKTEDE stoerrelsesordener; R761 baerer ingen priser, saa ingen av tallene er lest noe sted. a4s INDEKS-01 har ingen linje.",
"must_refuse": [
{
"approach_id": "a4-indeksregulering",
"anchors": [
"indeksregulering",
"kalkyle",
"kostnadsestimat",
"markedspris",
"nåverdi",
"prisstigning"
],
"rationale": "R761 er en prosesskode: den beskriver hva som skal utfores og males, ikke hva det koster. Kostnadsestimat, markedspris, prisstigning, indeksregulering og naverdi finnes ikke i basen. Spoersmaalene denne approachen staar for: Hvilket kostnadsestimat ligger til grunn for riggposten i denne kontrakten? | Hva er markedsprisen på tilkjørt filtermateriale i denne regionen i 2027? | Hvordan skal kontraktssummen indeksreguleres gjennom byggeperioden?"
}
]
}