portfolio-optimiser/shared/docs/plan/2026-07-26-v1-generated-felt-okf-v0.2.md

# V1 — hvilken form skal `generated` ha i ingest-spec etter OKF v0.2?

> **Status: AVGJORT 2026-07-31 — operatøren valgte O2** (`generated: { by: "process:<fast id>",
> at: <ingested_at> }`). Underlaget under står uendret som grunnlaget vedtaket ble tatt på;
> ingenting i §5–§7 er skrevet om i etterkant. Se **§4.1** for hva vedtaket utløser.
>
> **Vedtaket er IKKE utført.** `ingest-spec.md` står fortsatt uendret på `bfa5a9b`/`9801d35`.
> Utførelsen er gated — se §4.1.
>
> Opprinnelig status: beslutningsunderlag for operatøren, fire opsjoner med målt kostnad, ingen
> anbefaling. Utløst av `llm-ingestion-okf` (coord, 2026-07-26) som spør fordi authorship er
> vår: deres DEFAULT-profil staterer ingest-spec §5, og «ingen lokale spec-endringer» er deres
> stående non-goal.

Beslektet: `2026-07-25-amendment-underlag.md` (køen av ratifiserbare punkter — V1 hører hjemme
der hvis den ratifiseres), `2026-07-25-b1-nav-golden-normative-status.md` (samme form).

---

## 1. Det som ikke er oppe til vurdering

- **Ærlighetsregelen selv** (`ingest-spec.md:33-34`, avledet av `method-spec.md:26`) er
  *unwaivable*. Alle fire opsjoner under oppfyller den. Spørsmålet er hvilken **form**
  merkingen har, aldri **om** den finnes.
- **Eierskaps-stempelets funksjon** (`:70`, `:82`): at re-materialisering bare rører egne filer,
  og at en kurert skriver avviser det *komplette* stempelet. Ingen opsjon svekker den regelen.
- **`ingested_at` som eksplisitt påkrevd argument** (`:139-143`). Ingen opsjon innfører
  wall-clock. Der `at` finnes, bindes den til `ingested_at`.
- **Hastegrad.** `llm-ingestion-okf` er *ikke* blokkert: deres v0.2-støtte kommer som en ny
  profil ved siden av DEFAULT, additivt. Ingenting her er en brannslukking.

## 2. Premissene, verifisert

`llm-ingestion-okf`s to påstander er kontrollert mot kilden, ikke overtatt:

- **Oppstrøms:** OKF v0.2 (`GoogleCloudPlatform/knowledge-catalog`, `okf/SPEC.md`) definerer
  `generated: { by, at }`, og `generated.by` er **REQUIRED within `generated`**, typet som en
  aktør per §7. Aktørkonvensjonen har **tre** former: `<producer>/<version>` for agenter og
  verktøy, `human:<id>` for en person, `process:<id>` for en automatisert prosess.
- **Toleransen dekker det ikke.** v0.2 sier at konsumenter «MUST NOT reject documents with
  unrecognized fields» og ikke skal avvise for *manglende valgfrie* felter eller *ukjente*
  nøkler. Ingen setning pålegger en leser å svelge en **kjent nøkkel med feil type**.
  `llm-ingestion-okf`s lesning holder.
- **Historikken frikjenner valget.** `generated` var ikke reservert i v0.1. Ingen innførte en
  defekt; v0.2 tok navnet etterpå.

**Én forbeholdsrad:** deres egen plan (`okf-v0.2-alignment.md`) slår fast at spec-en er lest på
`main` — en gren, ikke en tag — og at «an enumeration read off a moving branch is a premise, not
a fact». Vår kontroll traff samme bevegelige gren. **Ingen frossen spec-tekst bør endres før
oppstrømsversjonen er pinnet til en commit.** Det gjelder O1, O2 og O3 likt.

## 3. `generated` bærer to laster i vår spec, ikke én

Dette er funnet som former underlaget, og grunnen til at opsjonssettet ikke er tre.

Nøkkelen opptrer 7 ganger som kontraktsreferanse, fordelt på fem seksjoner. De deler seg på
**to akser** som ingen av dem navngir:

| Last | Hvor | Hva den svarer på | Hvem leser den |
|---|---|---|---|
| **Ærlighetsmarkør** | §1 `:34`, §7 `:214` | «er dette maskingenerert?» | en leser/presentatør av bundelen |
| **Eierskapspredikat** | §3 `:70`, §3 `:82`, §11 `:275` | «hvilke filer eier ingest — og hva skal en kurert skriver avvise?» | materialiseringen og dør C |

Oppstrøms `generated { by, at }` er **provenance/attribusjon** — den første lasten, ikke den
andre. v0.2 har ingen skriveeierskaps-semantikk; feltet er valgfritt, konsument-skrivbart og
fritt for enhver aksesskontrollmening.

Konsekvensen er ikke at feltet ikke *kan* bære begge, men at en opsjon som flytter
eierskapspredikatet over på et oppstrømsdefinert felt **må uttale det**: predikatet går fra en
literal-sjekk (`generated == true`) til en parse-og-match på et felt hvis grammatikk oppstrøms
eier og fritt kan revidere. Konjunksjonen med `ingest_manifest` — vår egen nøkkel, ikke reservert
oppstrøms i noen versjon — bærer fortsatt uforfalskbarhet-mot-uhell, så stempelet kollapser
ikke. Men `:82`s «permitting either field alone» må omformuleres: under v0.2 vil *kurert*
innhold legitimt kunne bære en `generated`-mapping med en helt annen `by`.

> **Empirisk bekreftet 2026-07-26, ikke lenger bare utledet.** Oppstrøms skriver `generated` på
> **håndskrevet** innhold. Verifisert her:
> `generated: { by: human:jsmith@acme, at: 2024-01-15T10:00:00Z }`
> (`okf/bundles/acme_retail/metrics/gross-margin-legacy.md`, en menneskeskrevet metrikkdefinisjon).
>
> **Konsekvensen gjelder uansett hvilken opsjon som vedtas:** en implementasjon som utleder «er
> dette maskingenerert?» eller «eier vi denne fila?» fra at `generated` **finnes**, er feil under
> v0.2. Under O1/O2 må predikatet derfor være `generated.by == <vår aktør>` **og**
> `ingest_manifest` — aldri nøkkelens tilstedeværelse. Under O0 og O3 er poenget uten virkning,
> siden markøren vår da ikke deler navn med et oppstrømsfelt som brukes slik.

### 3.1 Målt i den pinnede implementasjonen — predikatet er KONJUNKSJONEN, og det er konformt

`portfolio-optimiser-claude` meldte 2026-07-26 at `generated` «er et eierskaps-predikat i den
pinnede v0.3.2», som en spenning mot oppstrøms' rene attribusjon. **Vi målte deres kilde. Funnet
er ekte, men konklusjonen er én hakk for sterk — og forskjellen er akkurat den V1 handler om.**

Lest i `llm_ingestion_okf/materialize.py` @ **0.3.2** (deres `.venv`, verifisert her):

```python
# :86-89   §3/§5 ownership: the ingest stamp is `generated: true` AND an
#          `ingest_manifest` reference.  ← deres egen kodekommentar
def _is_ingest_owned(path: Path) -> bool:
    frontmatter = _parse_frontmatter(path)
    return frontmatter.get("generated") == "true" and "ingest_manifest" in frontmatter
# :103     emitter:  "generated": "true"
# :258     eneste kaller → bygger eierskapsmengden
# :260-268 kollisjonsporten → MaterializationError(code="collision_unstamped")
```

Porten leser **konjunksjonen**, ikke feltet. Det er nøyaktig det frossen tekst krever, ordrett:

> **`ingest-spec.md` §3, «No other writer may forge the stamp»** — «the *complete* ownership
> stamp — `generated: true` together with an `ingest_manifest` reference — while permitting
> either field alone … **The check is on the complete stamp, never on the individual field
> names**»

**Så det finnes ingen «feltet ER to ting»-konflikt mellom oss og oppstrøms på predikat-nivå:**
`generated` alene har aldri båret eierskap, verken i vår tekst eller i deres implementasjon.
Aksefunnet i §3 står uendret — de to lastene er reelle — men eierskapslasten hviler på
konjunksjonen, og bare ærlighetsmarkør-lasten ligger på feltet alene.

**Det meldingen FAKTISK avdekker, og som er en ny kostnadsrad:** emitter (`:103`) og port
(`:89`) er koblet gjennom strengliteralen `"true"`. Blir `generated` en mapping, feiler
konjunksjonens **første ledd** — og da faller emitter og port samtidig, i samme fil. Det er en
migrasjonskostnad **under O1 og O2 likt**, og den er ikke synlig fra spec-teksten alene:

| Opsjon | Hva `_is_ingest_owned` må bli |
|---|---|
| O0 / O3 | uendret (`== "true"` består; under O3 med ny nøkkel) |
| O1 / O2 | `generated.by == <vår aktør>` **og** `ingest_manifest` — parse, ikke literal-sammenligning |

**Versjonsforskjellen som ingen av de to meldingene har sett** (målt her, i begge trær):

| Tre | `_is_ingest_owned`-signatur | Eierskapsporten er |
|---|---|---|
| v0.3.2 (det BEGGE konsumenter kjører) | `(path)` — `:84` | **global** over bundelen |
| `llm-ingestion-okf` HEAD | `(path, manifest_stem, *, profile)` — `:132`, kalt `:393` | **per manifest** |

`portfolio-optimiser-claude` beskriver v0.3.2-oppførsel; `llm-ingestion-okf` beskriver
HEAD-oppførsel (deres Q3-punkt om at «stemmen bærer per-manifest eierskap i kollisjonsporten»).
**Begge er sanne om hvert sitt tre, og de er ulike på nøyaktig det punktet begge meldingene
handler om.** Samme akseklasse som resten av dette dokumentet: «implementasjonen» er ikke én
ting når trærne ikke er pinnet til hverandre.

## 4. Spørsmålet

> Skal `generated` i ingest-spec §5/§7 forbli den literale `true`, anta v0.2-formen
> `{ by, at }` — og i så fall med hvilken aktørstreng — eller skal vår markør flytte til en
> nøkkel oppstrøms ikke eier?

### 4.1 Svaret, og hva det utløser (2026-07-31)

**Vedtatt: O2** — `generated: { by: "process:<fast id>", at: <ingested_at> }`, predikatet utledet
av `generated.by`. Aktørstrengen er specens, ikke produsentens.

**Hva vedtaket IKKE avgjør.** O2 ble valgt uten å ta stilling til `:29` — og trenger det ikke.
Det var nettopp O1 som ikke kunne vedtas alene (§6). O2 lar `:29` stå ordrett som den er, og
fasit-bytene forblir produsent-nøytrale. `:29` er dermed ikke i køen som følge av dette vedtaket.

**⛔ Utførelsen er gated, og gaten er ikke vår.** Ingen frossen tekst endres før
`llm-ingestion-okf` er **pinnet til en commit**. Vår forrige kryssgrense-kontroll traff `main` —
en bevegelig gren — og det ble korreksjonen i `ab0ea8f`. Gaten gjelder O2 som den gjaldt O1/O3.

**Køen dette legger seg i, når gaten åpner** (5 av 7 kontraktslinjer, uendret fra §5):
`:34`, `:70`, `:82`, `:214`, `:275`. `:152` og `:309` navngir bare nøkkelen og overlever.
V1 hører hjemme i `2026-07-25-amendment-underlag.md`s kø ved ratifisering.

**Varslingsplikten er utløst, ikke lenger betinget.** §9s formulering var «vedtas O2, skal
`llm-ingestion-okf` ha beskjed FØR de fryser en v0.2-fikstur som bærer `generated`». O2 ER
vedtatt, så plikten er live og forfaller ved deres neste fikstur-frys — ikke ved vår utførelse.
Varslet sendt 2026-07-31, samtidig som dette føres.

**Serialiseringsformen er BUNDET, og ikke av dette vedtaket** (tilført 2026-07-31 etter at
`portfolio-optimiser-claude` og deres måling reiste spørsmålet to ganger). Begge spurte om §4.1
binder inline flow normativt eller lar serialiseringen være implementasjonsvalg — forskjellen er
6 mot 7 sider hos dem. **Svaret er at spørsmålet allerede er avgjort av frossen tekst, og at V1
derfor ikke skal binde noe:**

- `ingest-spec.md:158` (inne i §5s frontmatter-punkt, som definerer det påkrevde ordnede
  prefikset `generated` ligger i): **«All values MUST be single-line»**. `MUST`, i kraft i dag,
  uendret siden `bfa5a9b`.
- Blokk-form er per definisjon flerlinjes. Den er derfor **allerede ikke-konform** — ikke som
  følge av O2, men som følge av en regel som har stått hele tiden.
- **Inline flow er den eneste konforme serialiseringen.** `generated: { by: …, at: … }` er
  single-line og line-oriented, og oppfyller `:150` og `:158` slik §5 allerede slår fast.

**Konsekvens: 6 er invariant, ikke betinget.** Den betingede raden (`O2, blokk-form → 7 sider`)
beskriver en form specen ikke tillater. V1 trenger ingen ny kontraktslinje for å binde formen,
og `:152`/`:309` overlever fortsatt. Samme klasse som D-B: **et spørsmål som ser åpent ut, men
er avgjort av tekst som allerede er frossen.** Målingen deres er likevel verdifull, og av en
annen grunn enn de sendte den: den viser at `test_provenance_keys_are_in_the_spec_order`
faktisk er en søm på `:158`-konformitet — den ville gått rød hvis noen emitterte blokk-form,
altså brøt `:158`. Det er en egenskap ingen hadde lagt merke til.

**Konsument-kostnaden er kjent på forhånd** (§5.1, målt @ `8a14137`): **6 sider** hos
`portfolio-optimiser-claude` — 4 byte-frosne fasit-blober + 2 verbatim likhets-assert. De 3
navn/orden-sidene rører O2 **ikke** (ordens-testen bygger nøkkelen med `ln.split(":", 1)[0]`, som
fortsatt gir `generated`). Fasit-blobene er en **fasit-endring, ikke en kodeendring** — method
spec §7 gjør goldenen til eneste fasit.

**Det som fortsatt er åpent og IKKE følger av dette vedtaket:** hvilken `<fast id>` strengen
skal bære. O2 fastslår formen (`process:<id>`, som v0.2 §7 eksplisitt tillater) og at aktøren
navngir prosessen specen definerer. Selve id-en er en redaksjonell avgjørelse som tas når
kontraktslinjene skrives, og bør avklares med `llm-ingestion-okf` i samme runde som pinnen.

### 4.2 Pinnen, id-en og siteringen — avgjort 2026-07-31 (økt 4)

`llm-ingestion-okf` svarte samme dag. Tre ting falt på plass, og ett premiss i §4.1 viste seg
for svakt formulert. Grunnlaget over står ordrett uendret; dette er status, ikke omskriving.

**Pinnen foreligger: `2504011`** — «feat(okf-v0.2): D5 — the v0.2 golden fixture, with
`okf_version` in root frontmatter», pushet til `open/llm-ingestion-okf`. Det er en PIN, sagt
eksplisitt som sådan. `6f42c10`/`ed08ac1` var siterte refs; skillet holdt.

**Deres v0.2-fikstur var aldri rammet, og det er målt, ikke antatt.** Den bar O2-formen fra
`c90171d` (07-27), vedtatt uavhengig av oss. Vår varsling traff et annet sett: de fire
DEFAULT-profil-fasitene (`ingest-golden-{file,sql,http}`, alle `:8`), som er VÅRT lag å endre.

**`<fast id>` = `process:okf-ingest`** (operatøren, 2026-07-31). Okfs eget forslag. De foreslo
først `process:llm-ingestion-okf` og argumenterte samtidig mot den — riktig, og strengere enn
de kunne se herfra:

| Kilde | Ordrett | Frossen siden |
|---|---|---|
| `ingest-spec.md:8-9` | «The prose is framework-neutral by rule: it never names a concrete agent toolkit or vendor stack, and a guard test keeps it that way» | `7aa53fc` (07-03) |
| `ingest-spec.md:7-8` | «implemented **from this spec alone** — without reverse-engineering any existing implementation» | `7aa53fc` |
| `ingest-spec.md:282` (§11-seam «Spec integrity») | «this spec goes missing, **names a concrete agent toolkit**, or stops documenting a contract field» | `7aa53fc` |

**Presisjonsforbehold, så raden ikke føres for sterkt:** `llm-ingestion-okf` er en
ingest-implementasjon, ikke strengt tatt en «agent toolkit» — `:282` treffer derfor ikke
ordrett. Det er `:7-8` som treffer uten tolkningsrom: å normere produsentens repo-navn ville
tvunget enhver annen konform implementasjon til å skrive det navnet i sin egen output. Samme
klasse som `:29` tvang O1 ut på, bare svakere. **Utelukkelsen holder, men på `:7-8`, ikke `:282`.**

**Siteringen er IKKE normativ — formen er usitert.** Okf spurte om anførselstegnene i
`by: "process:<fast id>"` var normative eller illustrative. **Spørsmålet er avgjort av frossen
tekst — fjerde gang** (etter D-B, `:29`-vs-O1 og `:158`):

- `method-spec.md:90` (frossen `7d2b46c`, 07-03): «Frontmatter is the leading `---`-delimited
  block, **parsed line-oriented as `key: value` strings**».
- Vi parser altså ikke YAML. Verdien ER den rå teksten etter `key: `. Det finnes ingen
  transparent sitering i formatet: et anførselstegn er **et tegn i verdien**, ikke syntaks som
  en parser fjerner. Normert sitat ⇒ predikatet måtte matchet anførselstegnene som datainnhold.
- Målt bekreftelse: v0.3.2s port sammenligner mot **strengen** `"true"` (§3.1 `:100`), ikke mot
  en boolean — nøyaktig fordi parsingen er line-oriented.
- Oppstrøms er selv usitert **med kolon i verdien**: `by: human:jsmith@acme` (§3s empiri).

Kanonisk form, vedtatt: `generated: { by: process:okf-ingest, at: <ingested_at> }`

**⛔ KORREKSJON av §4.1: pin var ikke den siste gaten.** §4.1 skrev «Ingen frossen tekst endres
før `llm-ingestion-okf` er pinnet til en commit». Det er en nødvendig, ikke tilstrekkelig
betingelse, og formuleringen ville — lest alene — hjemlet å skrive de 5 linjene nå. Den er
korrigert av avstemt tekst i søsterunderlaget:

> `2026-07-25-amendment-underlag.md:495-496` — «vi forbereder underlaget, **operatøren
> ratifiserer**, og **frossen tekst endres ikke uten den ratifiseringen**»

Køens rad 8 er B1/D4 — **V1 står ennå ikke i køen**, slik §8 alltid har sagt («V1 er punkt
nummer 8 *hvis den ratifiseres*»). Pin + id lukket gaten for at V1 kan gå I KØ; ratifiseringen
er en separat, operatør-eid handling, og amendment-pakken er på bevisst hold. **`ingest-spec.md`
står uendret på `bfa5a9b`; de 5 linjene bærer fortsatt literal `generated: true`.**

**B1 er ikke presedens for det motsatte:** `8a7d430` rørte `README.md` («katalog, ikke
kontrakt») og to planfiler — null normative filer. Commit-meldingen sier det selv om V1: «Ingen
frossen tekst er rørt.»

**Varslet til okf er sendt** (07-31, som svar på pinnen): id + siteringsform vedtatt, og et
eksplisitt **ikke regenerer ennå** — regenerering mot ikke-ratifisert tekst ville pekt fasiten
deres på en spec som ikke finnes. Varslingsplikten ved faktisk tekstendring står fortsatt live.

## 5. Opsjonene, med målt kostnad

Kostnad er talt som **kontraktslinjer som må skrives om** av de 7 (`:34`, `:70`, `:82`, `:152`,
`:214`, `:275`, `:309`).

**Det som ikke koster noe i noen opsjon:** §5s formkrav overlever uendret **for `generated`**.
Prefikset er «OKF line-oriented `key: value`» (`:150`) og «All values MUST be single-line»
(`:158`) — v0.2s kanoniske form for `generated` er en **inline flow mapping** på én linje, så den
er single-line og line-oriented allerede (verifisert oppstrøms:
`generated: { by: reference_agent/gemini-2.5-pro, at: 2026-06-30T14:00:00Z }`). `:153`
(«additional frontmatter keys MAY follow») er heller ikke i veien. Ingen opsjon tvinger fram en
rikere frontmatter-modell i *specen*.

> **Presisering 2026-07-26** (`llm-ingestion-okf`): setningen over er målt på `generated` **alene**,
> og skal ikke leses som at `:158` overlever v0.2 i sin helhet. Det gjør den ikke. `sources` —
> et annet nytt v0.2-felt — er kanonisk en **blokkliste**, verifisert oppstrøms:
> ```yaml
> sources:
>   - id: margin-standard
>     resource: policies/margin-standard.md
>     author: human:jsmith@acme
> ```
> Den formen bryter `:158` direkte. Det er **utenfor V1**, som bare gjelder `generated`, og
> DEFAULT-profilen emitterer ikke `sources` — men det er et reelt §5-spørsmål den dagen noen vil
> emittere v0.2s øvrige felter, og det er commons' å svare på. Ikke i køen, ikke meldt videre.

### O0 — la `generated: true` stå, dokumentér avviket

**0 av 7 linjer.** Ingen frossen tekst røres; ingenting går i ratifiseringskøen. Eneste
tilføyelse er en merknad om at nøkkelen kolliderer med et v0.2-definert felt.

Kostnad: DEFAULT fortsetter å emittere en v0.2-definert nøkkel med v1-verdi. En v0.2-leser har
ingen plikt til å akseptere den (§2). Kollisjonen forsvinner ikke — den venter.

**Reverserbar.** Ja.

### O1 — v0.2-form med produsent-aktør (`llm-ingestion-okf`s anbefaling)

`generated: { by: "llm-ingestion-okf/<versjon>", at: <ingested_at> }`, predikatet utledet av
`generated.by`.

**5 av 7 linjer** (`:34`, `:70`, `:82`, `:214`, `:275`). `:152` og `:309` navngir bare nøkkelen
og overlever.

**Denne opsjonen kolliderer med en eksisterende normativ setning — se §6.** Kostnaden er ikke
bare fikstur-regenerering.

> **Evidens FOR O1, tilført 2026-07-26.** `llm-ingestion-okf` korrigerte sin egen anbefaling da de
> hadde lest oppstrøms' *bundles* og ikke bare SPEC.md: **oppstrøms referanseimplementasjon bruker
> selv produsent/versjon-formen.** Verifisert her, uavhengig:
> `generated: { by: reference_agent/gemini-2.5-pro, at: 2026-06-30T14:00:00Z }`
> (`okf/bundles/acme_retail/metrics/gross-margin.md`). `<produsent>/<versjon>` er altså ikke en
> avvikende lesning av §7 — det er den **kanoniske formen for et verktøy**, brukt av spec-eieren.
> O1 er dermed den v0.2-*idiomatiske* opsjonen, og O2 er det bevisste avviket fra idiomet.
> Funnet i §6 står uendret ved siden av dette: oppstrøms' bundles er utdata fra én agent, ikke
> delte konformansfiksturer, så de to fakta er ikke i motstrid. **Det er nettopp byttet
> operatøren skal ta stilling til:** v0.2-idiomatikk mot reproduserbar delt fasit.

**Reverserbar.** Nei — frossen normativ tekst.

### O2 — v0.2-form med produsent-nøytral aktør

`generated: { by: "process:<fast id>", at: <ingested_at> }`. v0.2 §7 tillater eksplisitt
`process:<id>` for en automatisert prosess (verifisert, §2). Aktøren navngir da **prosessen
specen definerer**, ikke verktøyet som kjørte den.

**5 av 7 linjer** — nøyaktig samme som O1. Den eneste tekstlige forskjellen mot O1 er
aktørstrengen; den avgjør til gjengjeld §6.

Kostnad: `generated.by` identifiserer ikke lenger *hvilket* verktøy som produserte filen.
Produsent-identitet må da bo i implementasjonens egen logg. Om det er et tap eller et krav
avhenger av §6.

**Reverserbar.** Nei.

### O3 — døp om vår markør, la `generated` være fri

Vår markør flyttes til en nøkkel oppstrøms ikke eier; `generated` overlates til v0.2-semantikk.

**7 av 7 linjer** — også `:152` (prefiks-lista) og `:309` (kryss-sjekk-tabellen), fordi nøkkelen
selv skifter navn. Dyrest i tekst.

Til gjengjeld: predikatet bevares **eksakt** som en literal-sjekk, aksene i §3 skilles ved
konstruksjon, og kollisjonen kan ikke gjenoppstå ved neste oppstrømsrevisjon. v0.2 forbyr det
ikke — de nye feltene er valgfrie oppstrøms.

Kostnad: interop-tapet er reelt. En v0.2-leser som spør «er dette maskingenerert?» via
`generated` får ikke svar. Ærlighetsregelen er oppfylt internt, men ikke lesbar for formatets
egne lesere — som er en del av hvorfor vi ligger i OKF i det hele tatt.

**Reverserbar.** Nei.

### 5.1 Konsument-kostnaden, målt i `portfolio-optimiser-claude` @ `8a14137`

Tallene over teller **commons' egne kontraktslinjer**. De sier ingenting om hva en opsjon koster
der specen konsumeres. `portfolio-optimiser-claude` meldte 2026-07-31 hva raden koster hos EN
konsument. **Hele målingen er reprodusert her, read-only i deres tre, pinnet til `8a14137`
(2026-07-26)** — den føres derfor som *målt*, ikke som referert. (Pinnet, ikke `main`: forrige
kryssgrense-sjekk traff en bevegelig gren, og det ble korreksjonen i `ab0ea8f`.)

> Nummerering: meldingen kaller dette «kø-punkt 8». **Vårt** kø-punkt 8 er B1/D4 nav-golden
> (`2026-07-25-amendment-underlag.md` §9), og V1 ligger ikke i den køen i det hele tatt. Hvilken
> liste deres 8 tilhører, vet vi ikke — og gjetter ikke.

**To lag, og de faller ikke sammen.** Verdi-laget bærer strengliteralen `"true"`; navn/orden-laget
bærer nøkkelnavnet `generated` og plassen det har i §5-prefikset. Mapping-form rører bare det
første. En omdøping rører begge.

| Sted (konsumenten) | Lag | O0 | O1 / O2 | O3 |
|---|---|---|---|---|
| 4 byte-frosne fasit-blober | verdi | — | RØD | RØD |
| 2 verbatim likhets-assert | verdi | — | RØD | RØD (`KeyError`) |
| 3 navn/orden-sider | navn/orden | — | — | RØD |
| **Sum sider som må endres** | | **0** | **6** | **9** |

**Fasit-blobene** (`generated: true` på linje 8 i det byte-sammenlignede prefikset, alle fire):
`examples/ingest-golden-file/expected-bundle/ingest-costs.md` · `.../ingest-edge.md` ·
`examples/ingest-golden-sql/expected-bundle/ingest-costs.md` · `.../ingest-meta.md`.
Mekanismen er `tests/test_ingest_golden.py:36` — `read_bytes() == read_bytes()` per fil. Method
spec §7 gjør goldenen til eneste fasit, så dette er en **fasit-endring, ikke en kodeendring**.

**Verdi-assertene:** `tests/test_ingest_loadbearing.py:59` og
`tests/test_ingest_sql_loadbearing.py:84` — begge `frontmatter["generated"] == "true"`, begge på
§11-sømmen «Provenance stamping». Under O1/O2 feiler sammenligningen; under O3 finnes ikke
nøkkelen.

**Navn/orden-sidene — den raden konsumenten selv ikke priset:**
`tests/test_ingest_loadbearing.py:32` og `tests/test_ingest_sql_loadbearing.py:34`
(`_PROVENANCE_KEYS`-tuplene), samt `tests/test_ingest_loadbearing.py:67-75`
(`test_provenance_keys_are_in_the_spec_order`, navnet på `:74`). Ordens-testen bygger nøklene med
`ln.split(":", 1)[0]`, så `generated: { by: …, at: … }` gir fortsatt `generated` — **mapping-form
bryter ingen av de tre**, ordrett som meldingen sier. En **omdøping** bryter alle tre. Meldingen
tok ikke stilling til O3; denne raden er målt her.

**Presisjon på det fjerde stedet meldingen fører opp.**
`tests/test_ingest_spec_loadbearing.py:49` enumererer navnet `generated` — men i
`_CONTRACT_FIELDS`, og testen (`:68-71`) er `assert field in text` over **spec-teksten**, ikke
over frontmatter. Den kan derfor ikke bli rød under **noen** opsjon: prosaen «machine-generated»
(`ingest-spec.md:33`, `:214`, m.fl.) metter delstrengen selv om begge felt-radene slettes. Annen
mekanisme, og for akkurat dette feltet nær vakuøs. Om det er verdt en søm, er konsumentens
operatørs sak, ikke vår.

**Det meldingen bekrefter uten å legge til kostnad:** deres `shared/ingest-spec.md:186` («`generated`
| Literally `true` — the machine-generated marker») er vår `:214` — én av de 5 av 7 linjene O1/O2
allerede betaler. Normativ tekst må endres i SAMME amendment, ja; den er talt. Prosa-treffene
(`docs/extending.md:96,98`, `docs/oppskrift-kunnskapsbase.md:109`) er dokumentasjon, ikke sømmer,
og telles ikke.

**Forholdet til §3.1 — to akser, ikke to tabeller som er uenige.** §3.1 teller hva
`_is_ingest_owned` må *bli* (predikatets form: literal-sammenligning vs. parse) og sier O0/O3
lar den stå uendret. §5.1 teller hvilke *sider* som blir røde. O3 lar predikatets form stå og
flytter kostnaden til navn/orden-laget; O1/O2 gjør det motsatte.

**Dette er en pris, ikke en dom.** Argumentene for O3 i §5 står uendret — predikatet bevares som
literal-sjekk, aksene i §3 skilles ved konstruksjon. Raden sier bare at O3 er dyrest **også** hos
konsumenten, ikke bare i commons' tekst. Valget er operatørens.

## 6. Funnet som omformer opsjonssettet (ikke en anbefaling)

**O1 som formulert kolliderer med konformansleddet i §1.**

- `ingest-spec.md:29`: en konform implementasjon MUST «reproduce the shared golden extractions
  (§11) byte for byte».
- `ingest-spec.md:267`: `expected-bundle/` er «compared file by file, **byte for byte**».
- `ingest-spec.md:280`: sømmen `Golden regression` fyrer når «any byte of a golden extraction's
  expected bundle diverges».
- `generated` ligger i det **obligatoriske ordnede prefikset** (`:149-152`) — altså inne i de
  bytene.

Med `by: "llm-ingestion-okf/<versjon>"` bærer en **delt** fasit én produsents navn og
versjonsnummer. Da følger to ting mekanisk:

1. **Ingen annen konform implementasjon kan reprodusere fasiten byte for byte.** Kravet i `:29`
   gjelder enhver konform implementasjon, ikke den som lagde fikstursettet. Kravet blir
   uoppfyllbart ved konstruksjon for alle andre enn én.
2. **`Golden regression` fyrer på hver versjonsbump av biblioteket** — uten at noen kontrakt har
   endret seg. Sømmen slutter å måle det den er satt til å måle.

O2 unngår begge: aktørstrengen er da specens, ikke produsentens, og bytene forblir
produsent-nøytrale. O0 og O3 berører ikke spørsmålet.

**Merk hva funnet ikke er.** Det er ikke et argument for O2 og mot O1 i seg selv. Operatøren kan
gyldig svare at fasit-klassen aldri får mer enn én produsent, eller at `generated` skal ut av
det byte-sammenlignede prefikset. Men da er *det* valget som må ratifiseres — funnet sier bare
at O1 ikke kan vedtas uten samtidig å ta stilling til `:29`.

### 6.1 Rekkevidde-forbeholdet, korrigert 2026-07-26

Første utgave skrev at konflikten er «normativ, ikke observerbar — den utløses den dagen commons
publiserer sin første ingest-fasit». **Det var for snevert, og `llm-ingestion-okf` korrigerte
det med en måling.** Riktig bilde, etter kontroll i alle tre trær:

- `examples/ingest-golden-*` finnes fortsatt **ikke i commons** — og har aldri gjort det
  (`git log --all -- 'examples/ingest-golden-*'` → tomt).
- Men fikstursettene **finnes hos implementasjonene**, og `generated` ligger i bytene:
  fire filer hos `llm-ingestion-okf`, alle på `:8`, inne i prefikset. **Del (ii) av funnet —
  at `Golden regression` (`:280`) ville fyre på hver versjonsbump — er derfor observerbar i
  dag, ikke i framtiden.** Den utløses ved deres neste release.

### 6.2 Funnet under funnet: «the shared golden extractions» har ingen referent

Kontrollen for 6.1 avdekket noe som gjelder uavhengig av hele V1-spørsmålet, og som ingen har
meldt:

| Repo | `examples/ingest-golden-*/expected-bundle/` |
|---|---|
| commons | finnes ikke, har aldri funnes |
| `llm-ingestion-okf` | `ingest-orders.md`, `ingest-products.md`, `ingest-metrics.md`, `ingest-status.md` (+ 3 `index.md`) |
| `portfolio-optimiser-claude` | `ingest-costs.md` ×2, `ingest-edge.md`, `ingest-meta.md` (+ 2 `index.md`) |

**Overlappet i innholdsfiler er null.** De eneste sammenfallende navnene er `index.md`, og de er
byte-ulike (ulik oppsummering, ulike lenkemål — verifisert med `cmp`).

`ingest-spec.md:29` krever at en konform implementasjon reproduserer «**the shared** golden
extractions (§11) byte for byte». Bestemt form forutsetter ett sett. Det finnes to, begge
lovlig navngitt etter konvensjonen i `:259-260`, ingen av dem publisert her. **Konformansleddet
er dermed ikke-testbart i dag** — ikke fordi fasiten mangler, men fordi det er to av dem, og
hver implementasjon reproduserer sin egen per konstruksjon.

Dette er et **selvstendig punkt**, ikke en del av V1, og det er ikke i køen. Det er tatt med
her fordi det avgjør hvor tungt `:29`-argumentet i §6 veier: argumentet er ikke «dette bryter
en delt fasit vi har», men «dette sementerer at en delt fasit aldri kan oppstå».

#### 6.2.1 Svar fra `llm-ingestion-okf` (2026-07-26) — tre målte, én åpen

Fire spørsmål ble sendt. **Deres målinger er ført som DERES, ikke foldet inn i våre tall** —
sømmene under er lest i fiksturer vi ikke har, og en dekningstelling som mater et
konformansargument kan ikke blande målt og referert evidens.

**Q1 — INTENSJON: nei, settet var aldri ment som `:29`s fasit.** Målt i deres egen historikk
(`9dd86b1`, «ship the 11 golden fixtures with byte-exact conformance»): bygget som *deres*
verifikasjonssett mot §11s FORMAT, uten koordinering med commons noe sted i historikken.
**Konsekvens for oss:** dette er en **misforståelse i spec-teksten, ikke en drift som skal
lukkes**. Bestemt form — «**the shared** golden extractions» — beskriver noe som aldri ble
opprettet, av noen. Det styrker §6.2s konklusjon og gjør den billigere å rette: `:29` beskriver
en artefakt som ikke finnes, ikke en artefakt som har kommet i utakt.

**Q2 — vår dekningstelling var riktig så langt den gikk, men fire sømmer er ikke talt** (okfs
måling, lest i fiksturene):

| # | Søm | Hvorfor den ikke var i vår telling |
|---|---|---|
| 1 | **NULL ⊥ tom celle er TO sømmer** | vi talte «tom celle» én gang; `products.csv` C-3 har `''`, `metrics.db` rad 2–3 har `NULL` (`None` fra DB-API) — ulike kodestier, ulik rendering |
| 2 | **Kredensial-indireksjon** | `connection_ref: OKF_GOLDEN_SQL_DB` resolves ved kjøring; golden-kjøringen beviser at ingen kredensial når output. Finnes i ingen av de to settene ellers |
| 3 | **Fler-ekstraksjon i én bundle** | file-caset har to ekstraksjoner → indeks med to oppføringer. Indeksgenerering med N>1 er en egen søm, kun i file-caset |
| 4 | **`http` er HERMETISK** | fiksturen er et mock-payload på disk, åpner aldri en socket. Dette er en **betingelse på FORMEN til et delt sett**, ikke en case i det — brytes den, blir conformance-suiten nettverksavhengig for alle |

Søm 4 er den som endrer hva et delt sett *er*: den er et krav til konstruksjonen, ikke en rad i
dekningstabellen. De presiserer at de **ikke** har gått gjennom `portfolio-optimiser-claude`s
`ingest-costs.md`/`ingest-meta.md` og ikke påstår noe om den halvdelen av dekningen.

**Q3 — bekreftet, og verre enn vi skrev: stampen bærer FILNAVNET.** Vi skrev at
`ingest_manifest` hashes av manifestets rå bytes. Verifisert her, i begge trær:

```python
stamp = f"{manifest_file.stem}@{hashlib.sha256(raw).hexdigest()[:16]}"
#   v0.3.2 :191   |   llm-ingestion-okf HEAD :326
```

Et delt sett krever altså at commons eier og publiserer **manifestets bytes OG hva fila heter**.
To implementasjoner som lastet ned samme manifest og lagret det som `ingest.json` vs.
`manifest.json` ville fått ulike stamper av identiske bytes. I okfs HEAD bærer stemmen dessuten
**per-manifest eierskap** i kollisjonsporten (§3.1 over) — et delt manifest med et annet filnavn
ville endre hvilke filer en kjøring mener å eie.

**Veien rundt, som de peker på uten å anbefale:** konvergens er ikke nødvendig på HELE bundelen.
`ingest_manifest` er én linje i frontmatteret; et delt sett kunne kreve byte-likhet på alt
UNNTATT den linja, og da er kravet oppfyllbart uten et delt manifest — mot at `:29` ikke lenger
kan si «byte-identisk bundle» uten forbehold. **Valget står mellom å eie manifestet og å svekke
kravet. Ingen av dem er gratis, og det er operatørens, ikke vårt.**

**Q4 — ikke målt, og de svarer ikke.** Vi ba om målt kostnad, ikke overslag; de holdt den
disiplinen begge veier. Målingen som er utestående: bytte manifestene i de tre casene til et
hypotetisk commons-eid sett, kjøre conformance-suiten, telle hvilke expected-bundle-bytes som
endrer seg og hvilke av de elleve sømmene som forsvinner. **Kjørbar måling, ikke en vurdering.**
Ikke gjort fordi kvoten deres er lav og fordi den bare er verdt å gjøre hvis operatøren
køplasserer konvergens over v0.2-arbeidet. De står klare til å ta den først neste økt hvis vi
sier fra. **Svart tilbake: ikke bestilt ennå — køplasseringen er operatørens, og den er ikke
tatt.**

## 7. Rutet hit: aktørkonvensjonen for intervju-født innhold — og hvorfor den ikke blokkerer V1

`llm-ingestion-okf` rutet 2026-07-26 et spørsmål fra `ms-ai-architect` hit, «fordi spec §7s
aktørkonvensjon er deres tekst». **Spørsmålet er reelt. Rutingen hviler på en navnekollisjon,
og den er verdt å rette før noen bygger på den.**

**Spørsmålet:** hva skal en produsent skrive når innholdet er *intervju-født* — et menneske
svarer, en LLM strukturerer svarene og skriver fila, og mennesket leser ikke nødvendigvis
resultatet? Substansen er menneskets, formuleringen er modellens. `process:`/`<produsent>/<versjon>`
**underrapporterer** (bare et menneske kan ha visst det organisasjonsspesifikke); `human:<id>`
**overrapporterer** (ingen har verifisert at formuleringen gjengir svaret riktig — et
tillitssignal ingen har fortjent). Deres tre alternativer: (a) maskin-aktør ved skriving +
separat `verified`-oppføring med `human:<id>` først når mennesket faktisk har lest; (b)
`human:<id>` direkte; (c) en egen aktørform. Deres lesning, uttalt som lesning: (a).

### 7.1 To ulike §7-er — kollisjonen, målt

| «§7» | Dokument | Innhold |
|---|---|---|
| Aktørkonvensjonen med tre former | **OKF `SPEC.md` §7** (Google, oppstrøms) | `<producer>/<version>` / `human:<id>` / `process:<id>` |
| **Vår** §7 | `ingest-spec.md` «Provenance — a separate layer» | `generated` = «**Literally `true`** — the machine-generated marker» |

Målt i vår frosne tekst: `grep -n "human:\|process:\|by: " ingest-spec.md method-spec.md
CONCEPT.md` → **0 treff**. **Commons har ingen aktørkonvensjon å endre.** Vår markør er boolsk
og aktørløs. Å be commons avgjøre aktørformen i dag er å be om en verdi vi ikke har — og å
levere en ville vært å foregripe nettopp det V1 legger fram for operatøren.

### 7.2 Og et lag-skille som gjelder uansett opsjon

Ingest-spec §7 stempler **filer materialisert av ingest-pipelinen fra en manifest-definert
kilde**. Intervju-født innhold er ikke ingest-materialisert — det er **kurert** innhold skrevet
gjennom en authoring-primitiv, og vår §3 krever eksplisitt at den primitiven **avviser** det
komplette ingest-stempelet. Vårt lag kan altså ikke stemple det uansett, og for filer vårt lag
FAKTISK stempler er aktøren maskinell per konstruksjon — det finnes ingen intervju-født variant
av en manifest-drevet ekstraksjon.

**Konsekvens for opsjonene, som er det operatøren trenger:**

| Opsjon | Arver vi spørsmålet? |
|---|---|
| **O0** | Nei — ingen aktørakse i markøren i det hele tatt |
| **O1** | Nei for vårt lag — aktøren er alltid `llm-ingestion-okf/<versjon>` (materialiseringen skrev fila) |
| **O2** | Nei — aktøren er en fast prosess-id uavhengig av opphav, per konstruksjon |
| **O3** | Nei — `generated` frigjøres til oppstrøms' form, og hvem som skriver den er ikke vår tekst |

> **Derfor: operatøren trenger IKKE å løse dette for å løse V1.** Ingen av de fire opsjonene
> endrer svaret, og ingen av dem blir billigere eller dyrere av det. Spørsmålet er ikke en
> femte kostnadsrad — det er en sak i et annet lag som deler et seksjonsnummer med vårt.

### 7.3 Hva vi faktisk kan si, som lesning og ikke vedtak

Aksehygienisk er okfs (a) den eneste av de tre som ikke lyver i noen retning, og grunnen er
den samme aksen dette repoet har ført ni ganger: (a) gjør tillitssignalet til en funksjon av en
**handling** (noen leste det) i stedet for av en **opprinnelse** (noen sa det). `generated` ⊥
`verified` er samme skille som ærlighetsmarkør ⊥ eierskapspredikat i §3. (c) koster nytt
vokabular for et skille som allerede kan uttrykkes. **(a) er dessuten kompatibel med både O1 og
O2** — den flytter tillitssignalet UT av `generated` og inn i `verified`, og rører derfor ikke
V1s valg i noen retning.

Én målt ting som støtter (a)s gjennomførbarhet, gjort av okf mot guard 0.2.0 og referert som
**deres** måling: `verified` som blokkliste går allerede gjennom persist-gaten
(`verified:\n  - human:ktg` parses som `['human:ktg']`), mens en `generated`-**mapping** ikke gjør
det i noen form (flow feiler på `{`, blokk på nested mappings, punktnøkler på key-regexen).
Ikke et argument for (a) i seg selv — men (a)s ene nye mekanisme møter ingen vegg der v0.2s
`generated` møter en. **Ikke verifisert av oss; deres tre, deres måling.**

**Rett respondent:** aktørkonvensjonen er OKFs. Skal en fjerde form eller en (a)-konvensjon
ratifiseres, hører den hjemme oppstrøms i `SPEC.md` §7 — ikke i ingest-spec. Meldt tilbake med
den lesningen, uten vedtak.

## 8. Det som ikke er commons' å avgjøre

- **Hvilken opsjon som velges.** Spec-teksten er frossen; endringer går gjennom
  ratifiseringskøen. V1 er punkt nummer 8 hvis den ratifiseres — den står **utenfor** de 7 i
  `2026-07-25-amendment-underlag.md` og fortrenger ingen av dem.
- **Hva `llm-ingestion-okf` gjør i sin egen v0.2-profil.** Den er additiv og deres authorship.
  Bare DEFAULT staterer vårt lag.
- **Om produsent-identitet skal logges et annet sted** (O2s pris). Implementasjonens valg.

## 9. Det som ikke endres uansett utfall

Ærlighetsregelen, eierskapsstempelets funksjon, `ingested_at`-argumentet, §5s single-line- og
line-oriented-krav, og `ingest_manifest` som stempelets andre halvdel. Ingen opsjon rører
`method-spec.md` — nøkkelen forekommer ikke der (`grep -c '\`generated' method-spec.md` → 0).

---

## Verifiseringslogg

| Påstand | Sjekk | Resultat |
|---|---|---|
| v0.2 definerer `generated: { by, at }` | `okf/SPEC.md` @ `main`, hentet 2026-07-26 | «generated: { by: reference_agent/gemini-2.5-pro, at: 2026-06-20T22:53:05Z }» |
| `by` er påkrevd | samme | «generated.by: REQUIRED within `generated`. An actor (§7).» |
| Aktørkonvensjonen har tre former | samme, §7 | `<producer>/<version>` / `human:<id>` / `process:<id>` |
| `timestamp` er superseded | samme | «`timestamp` is superseded by `generated.at`» |
| Toleransen gjelder ukjente, ikke feiltypede | samme | «MUST NOT reject documents with unrecognized fields»; lista dekker manglende valgfrie + ukjente |
| Oppstrøms er lest på en gren, ikke en tag | `llm-ingestion-okf/docs/plan/okf-v0.2-alignment.md` | «`main` on 2026-07-26 — a branch, not a tag» |
| Kontraktsreferanser til nøkkelen | `grep -n '\`generated' ingest-spec.md` | 7 linjer: `:34 :70 :82 :152 :214 :275 :309` |
| Nøkkelen finnes ikke i method-spec | `grep -c '\`generated' method-spec.md` | 0 |
| Ærlighetsregelen er unwaivable | `ingest-spec.md:33-34`, `method-spec.md:26` | «unwaivable» begge steder |
| Stempelet er `generated: true` + `ingest_manifest` | `ingest-spec.md:70`, `:82` | ordrett sitert over |
| Dør C avviser kun det komplette stempelet | `ingest-spec.md:82-85` | «while permitting either field alone» |
| `generated` ligger i det ordnede prefikset | `ingest-spec.md:149-152` | 7 nøkler, `generated` er den sjuende |
| Prefikset er åpent bakover | `ingest-spec.md:153` | «additional frontmatter keys MAY follow it» |
| Single-line-kravet holder for flow mapping | `ingest-spec.md:150`, `:158` | «line-oriented `key: value`» / «All values MUST be single-line» |
| Konformans krever byte-lik delt fasit | `ingest-spec.md:29` | «reproduce the shared golden extractions (§11) byte for byte» |
| Fasiten sammenlignes byte for byte | `ingest-spec.md:267`, `:280` | «byte for byte» / «any byte … diverges» |
| Ingen ingest-fasit finnes i commons | `ls -d examples/ingest-golden-*` | ingen treff |
| …og har aldri funnes | `git log --all -- 'examples/ingest-golden-*'` | tomt |
| `generated` ligger i fasit-bytene hos okf | `grep -rn '^generated' llm-ingestion-okf/examples/ingest-golden-*/expected-bundle/*.md` | 4 filer, alle `:8` |
| …inne i det ordnede prefikset | `sed -n '1,9p' .../ingest-orders.md` | 7 nøkler `:2-8`, `generated` sist |
| Predikatet nøkler på literalen i dag | `materialize.py:131-150` **@ `llm-ingestion-okf` HEAD** (ref tilføyd 07-27 — raden var ref-løs) | `frontmatter.get("generated") != "true"` + stem-match |
| To disjunkte fasitsett finnes | `comm -12` over begge trærs `expected-bundle/*.md` | kun `index.md`-navn felles |
| …og de felles `index.md` er ulike | `cmp` på `ingest-golden-file/.../index.md` | ULIKE |
| §1 sier «**the shared** golden extractions» | `ingest-spec.md:29` | bestemt form, én mengde forutsatt |
| Oppstrøms bruker selv `<produsent>/<versjon>` | `okf/bundles/acme_retail/metrics/gross-margin.md` | `by: reference_agent/gemini-2.5-pro` |
| Oppstrøms skriver `generated` på HÅNDSKREVET fil | `…/gross-margin-legacy.md` | `by: human:jsmith@acme` |
| `sources` er blokkliste, ikke inline flow | samme fil, `sources:` | `- id:` + 4 nøkler, flerlinjes → bryter `:158` |
| Konsument-treet er pinnet for §5.1 | `git -C ~/repos/portfolio-optimiser-claude log -1` | `8a14137` (2026-07-26) — ikke `main` |
| 4 fasit-blober bærer `generated: true` | `grep -rn generated examples/ingest-golden-*/expected-bundle/*.md` @ `8a14137` | 4 filer, alle `:8` |
| Fasiten er byte-sammenligning per fil | `tests/test_ingest_golden.py:36` | `read_bytes() == read_bytes()` |
| 2 verbatim verdi-assert | `tests/test_ingest_loadbearing.py:59`, `tests/test_ingest_sql_loadbearing.py:84` | `frontmatter["generated"] == "true"` |
| 3 navn/orden-sider, ikke 4 | `_PROVENANCE_KEYS` `:32` + `:34` (sql) + ordens-lista `:67-75` | sql-fila har INGEN ordens-test |
| Ordens-testen overlever mapping-form | `tests/test_ingest_loadbearing.py:67` | `ln.split(":", 1)[0]` → `generated` uansett verdi |
| `:49` er delstreng over spec-tekst | `tests/test_ingest_spec_loadbearing.py:68-71` | `assert field in text` — ikke frontmatter, kan ikke bli rød |
| …og «machine-generated» metter den | `grep -n generated ingest-spec.md` | `:33`, `:214` m.fl. — prosa alene holder |
| Deres `:186` er vår `:214` | `sed -n '186p' …/shared/ingest-spec.md` | «Literally `true`» — samme rad, én commit bak |
| Vårt kø-punkt 8 er ikke deres | `2026-07-25-amendment-underlag.md` §9 | rad 8 = B1/D4 nav-golden; V1 står ikke i køen |
| SPEC.md er endret ETTER v0.2-migreringen | okf-melding, deres pin `3fcbb9f` | «v0.2-commiten» ≠ «dagens spec-tekst» — uverifisert av oss |
| `ingested_at` har ingen wall-clock-default | `ingest-spec.md:141` | «there is NO wall-clock default» |
| Spec-tekst uendret siden 07-21 | `git log --oneline -- ingest-spec.md` | `bfa5a9b`, forrige `7aa53fc` — ingen commit etter |

**Tilført 2026-07-27** (innboksrunden — fire meldinger, alle premiss målt mot kilden):

| Påstand | Sjekk | Resultat |
|---|---|---|
| v0.3.2s eierskapsport er en KONJUNKSJON | `materialize.py:86-89` @ `portfolio-optimiser-claude/.venv` (0.3.2) | `generated == "true" AND "ingest_manifest" in frontmatter` — deres kodekommentar sier «AND» eksplisitt |
| …og det er konformt med frossen tekst | `ingest-spec.md` §3 | «The check is on the complete stamp, never on the individual field names» |
| Emitter og port kobles av literalen `"true"` | `materialize.py:103` (emitter) vs. `:89` (port) | samme strengliteral begge steder |
| Porten er GLOBAL i v0.3.2 | `grep -n _is_ingest_owned` @ 0.3.2 (289 linjer) | def `:84`, ENESTE kall `:258`, signatur `(path)` |
| Porten er PER MANIFEST i okfs HEAD | samme grep @ `~/repos/llm-ingestion-okf` (424 linjer) | def `:132`, kall `:393`, signatur `(path, manifest_stem, *, profile)` |
| Stampen bærer FILNAVNET (okfs Q3) | `stamp = f"{manifest_file.stem}@{sha256(raw)[:16]}"` | v0.3.2 `:191`; okf HEAD `:326` — bekreftet i BEGGE trær |
| okfs egne `:251`/`:318` peker i intet av de to trærne | `wc -l` + `grep -n` begge trær | substansen bekreftet, linjenumrene ikke — ref ikke oppgitt i meldingen |
| Commons har INGEN aktørkonvensjon | `grep -n "human:\|process:\|by: " ingest-spec.md method-spec.md CONCEPT.md` | **0 treff** |
| Vår §7 definerer `generated` som boolsk | `ingest-spec.md` §7, felt-tabellen | «Literally `true` — the machine-generated marker (§1 honesty rule)» |
| De tre aktørformene er OKFs §7, ikke vår | V1 §2 + `okf/SPEC.md` §7 | navnekollisjon mellom to ulike §7-er |
| Begge konsumenter står på `7aa53fc` | `diff <(git show 7aa53fc:ingest-spec.md) ~/repos/<konsument>/shared/ingest-spec.md` | **IDENTISK** for `portfolio-optimiser` OG `portfolio-optimiser-claude` |
| …altså ÉN commit bak, ikke to | `git rev-list --count 7aa53fc..HEAD -- ingest-spec.md` | **1** (`bfa5a9b`) |
| MCP-ankeret finnes i den pinnede kopien | `git show 7aa53fc:ingest-spec.md \| grep -n "An MCP-based"` | `:101` — S2.2/S2.4-ugatingen henger ikke på en pull |
| `:112-114` hos konsumenten er IKKE tomt | `git show 7aa53fc:ingest-spec.md \| sed -n '112,114p'` | felt-tabellen: `id` / `title` / `query` (`okf_type`/`max_rows` er `:115-116`) |

**Tilført 2026-07-31 (økt 4 — pin, id, sitering, ratifiseringsgaten):**

| Påstand | Sjekk | Resultat |
|---|---|---|
| Frontmatter parses som STRENGER, ikke YAML | `method-spec.md:90` | «parsed line-oriented as `key: value` **strings**» — derav er sitering datainnhold, ikke syntaks |
| …og har vært frossen hele veien | `git log -1 -S 'parsed line-oriented as' -- method-spec.md` | `7d2b46c` (2026-07-03) — eldste spec-commit |
| Prosaen er framework-nøytral ved regel | `ingest-spec.md:8-9` | «never names a concrete agent toolkit or vendor stack, and a guard test keeps it that way» |
| …håndhevet som §11-seam | `ingest-spec.md:282` | «Spec integrity \| this spec … names a concrete agent toolkit …» |
| …men `:282` treffer ikke okf ordrett | lesning: okf er ingest-impl., ikke «agent toolkit» | **utelukkelsen hviler på `:7-8`**, ikke `:282` — ført som forbehold, ikke som treff |
| Commons har fortsatt INGEN aktørkonvensjon | `grep -n "human:\|process:\|by: " ingest-spec.md method-spec.md CONCEPT.md \| wc -l` | **0** (uendret fra 07-27) |
| Spec-en kaller laget «ingest», prosessen «materialization» | `grep -io 'materializ[a-z]*' ingest-spec.md \| wc -l` + `:1`, `:18`, `:28` | 27 forekomster; tittel + §1 bruker «Ingest» som lagets navn → `okf-ingest` |
| `ingest-spec.md` er URØRT | `git log --oneline -2 -- ingest-spec.md` | `bfa5a9b`, forrige `7aa53fc` — ingen commit i økt 3 eller 4 |
| De 5 linjene er urørte — men bærer IKKE samme form | `grep -n '\`generated' ingest-spec.md` | **4 av 5** bærer `generated: true` ordrett (`:34`, `:70`, `:82`, `:275`). `:214` er §7-feltradstabellens rad («\`generated\` … Literally \`true\` — the machine-generated marker») og bærer ikke literalen. Se raden under |
| …og `:214` er derfor IKKE en strengerstatning | O2-formen (`generated: { by: …, at: … }`) vs. radens «Literally `true`» | raden **beskriver feltets verdi**. Under O2 er verdien et objekt med `by`/`at`, så raden må skrives om (evt. splittes), ikke søk-og-erstattes. **Egen redigering, samme amendment** |
| Frossen tekst krever RATIFISERING, ikke bare pin | `2026-07-25-amendment-underlag.md:495-496` | «operatøren ratifiserer, og frossen tekst endres ikke uten den ratifiseringen» |
| V1 står ikke i køen | samme fil §9, rad 8 | rad 8 = **B1/D4**, ikke V1 — uendret fra 07-27 |
| B1 rørte ingen normativ fil | `git show 8a7d430 --name-only` | `README.md` + 2 planfiler; **0** normative filer |
| Pinnen er en pin, ikke en ref | okf-melding 07-31, `2504011` | sagt eksplisitt som pin; skillet fra `6f42c10`/`ed08ac1` holdt |
| Deres v0.2-fikstur bar O2-formen allerede | okfs måling, `c90171d` (07-27) | **ført som DERES**, ikke reprodusert her |

**Korreksjon 2026-07-31 (økt 6) — «de 5 linjene» er ikke homogene.** Raden «De 5 linjene bærer
fortsatt literalen» påsto at alle fem bar `generated: true` ordrett. Det er feil, og planen
motsa seg selv: §5.1 fører `:214` korrekt opp som «Literally `true`»-raden, og
verifiseringstabellens egen `grep -n '\`generated'`-rad lister `:214` blant de 7 uten å skille
form. Målt nå: `grep -n 'generated: true' ingest-spec.md` gir **4** treff (`:34`, `:70`, `:82`,
`:275`) — ikke 5.

Feilen var arvet ordrett inn i `STATE.md`s NESTE-blokk («skriv om de 5 kontraktslinjene … fra
literal `generated: true`»). Konsekvensen er ikke kosmetisk: en økt som utfører V1 mekanisk
etter den formuleringen finner 4 av 5 treff og står igjen med to like sannsynlige feiltolkninger
— (a) drift i frossen tekst, eller (b) `:214` hoppes over, som etterlater **ærlighetsmarkørens
§7-halvdel** (§3s ærlighetsmarkør-rad: «§1 `:34`, §7 `:214`») ukonvertert mens §1-halvdelen er
O2. Tellingen «5 av 7» (§4.1, §5) står uendret — det var formen, ikke antallet, som var feil ført.

*Ingen normativ fil rørt av denne korreksjonen; `ingest-spec.md` står fortsatt på `bfa5a9b`.*

---

## 10. RATIFISERT 2026-08-02 — og en andre tabellrad som økt 6 ikke fanget

**Operatøren ratifiserte V1 2026-08-02**, ordrett: *«Jeg kan ta okf-kostnaden nå, men vi må
starte i en ny sesjon.»* Utførelsen ligger dermed hos neste økt, ikke hos den som mottok
vedtaket.

**Begge gater er oppløst, og den andre falt av seg selv.** okf-gaten var lukket fra før (pin
`2504011`, økt 4). Ratifiseringsgaten er nå gitt. Den tredje betingelsen som har ligget i
STATE — at V1 skulle vente på §9-amendment-pakken — var aldri en gate i egen rett: den var
**batching** mot at endringen utløser `llm-ingestion-okf`s regenerering av fire DEFAULT-fasiter.
Når operatøren tar den kostnaden nå, har batchingen ingenting å batche mot. V1 er frikoblet fra
pakken, og S2.3 (`{type: "doc"}`, spurt `20260802T191837Z`) endrer ikke utfallet.

### Ankere re-målt 2026-08-02 (vår egen ferskvare-regel)

| Sted | Seksjon | Ordrett i dag | Behandling |
|---|---|---|---|
| `:34` | §1 Scope | «such (`generated: true` plus a manifest reference, §7) everywhere it is presented.» | prosa — mekanisk |
| `:70` | §3 Layer separation | «the ingest stamp (`generated: true` plus an `ingest_manifest` reference, §7) and MUST NOT» | prosa — mekanisk |
| `:82` | §3 Layer separation | «ownership stamp — `generated: true` together with an `ingest_manifest` reference — while» | prosa — mekanisk |
| `:214` | §7 Provenance | «\| `generated` \| Literally `true` — the machine-generated marker (§1 honesty rule). \|» | feltrad — skriv om/splitt |
| `:275` | §11 Load-bearing | «\| Stamp integrity (curated writers) \| … the complete ownership stamp (`generated: true` with `ingest_manifest`) stops being rejected … \|» | **rød-betingelse** |

### Korreksjonen: det er TO tabellrader, ikke én

Økt 6 korrigerte «de 5 linjene» fra homogene til 4 + 1 og pekte ut `:214`. Re-målingen viser at
korreksjonen selv var ufullstendig: **`:275` er også en tabellrad, og den står i §11s
load-bearing-tabell.** Det er ikke prosa som beskriver stempelet — det er en **rød-betingelse i
konformanskontrakten**. Å endre den endrer hva en konformant implementasjon må bevise, og er
derfor en sterkere handling enn å redigere §1- og §3-prosaen.

De «fire mekaniske» er i praksis **tre** (`:34`, `:70`, `:82`). `:214` og `:275` krever hver sin
vurdering. `:152` og `:309` overlever (feltnavn, ikke literal).

Dette er andre gang en verifiseringsrad i denne planen påsto homogenitet som ikke fantes. Regelen
står: **sjekk hva linjene FAKTISK bærer — og hvilken tabell de står i — før noe føres som
mekanisk.**

### Varslingsplikt, utløst av utførelsen

Endringen utløser den lovede meldingen til `llm-ingestion-okf` — den setter i gang deres
regenerering av de fire DEFAULT-fasitene. Den sendes i **samme økt** som tekstendringen, ikke
senere. `portfolio-optimiser-claude` varsles samtidig; de vet ennå ikke at id-en er
`process:okf-ingest`.

*`ingest-spec.md` er fortsatt urørt på `bfa5a9b` i det dette skrives.*