50 KiB
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.mdstå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 avmethod-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_atsom eksplisitt påkrevd argument (:139-143). Ingen opsjon innfører wall-clock. Deratfinnes, bindes den tilingested_at.- Hastegrad.
llm-ingestion-okfer 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-okfs to påstander er kontrollert mot kilden, ikke overtatt:
- Oppstrøms: OKF v0.2 (
GoogleCloudPlatform/knowledge-catalog,okf/SPEC.md) definerergenerated: { by, at }, oggenerated.byer REQUIRED withingenerated, 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-okfs lesning holder. - Historikken frikjenner valget.
generatedvar 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 :82s «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
generatedpå 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
generatedfinnes, er feil under v0.2. Under O1/O2 må predikatet derfor væregenerated.by == <vår aktør>ogingest_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):
# :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: truetogether with aningest_manifestreference — 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
generatedi ingest-spec §5/§7 forbli den literaletrue, 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.mds 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 prefiksetgeneratedligger i): «All values MUST be single-line».MUST, i kraft i dag, uendret sidenbfa5a9b.- 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:150og:158slik §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(frossen7d2b46c, 07-03): «Frontmatter is the leading----delimited block, parsed line-oriented askey: valuestrings».- 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ågeneratedalene, og skal ikke leses som at:158overlever v0.2 i sin helhet. Det gjør den ikke.sources— et annet nytt v0.2-felt — er kanonisk en blokkliste, verifisert oppstrøms:sources: - id: margin-standard resource: policies/margin-standard.md author: human:jsmith@acmeDen formen bryter
:158direkte. Det er utenfor V1, som bare gjeldergenerated, og DEFAULT-profilen emitterer ikkesources— 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-okfs 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-okfkorrigerte 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ømmenGolden regressionfyrer når «any byte of a golden extraction's expected bundle diverges».generatedligger 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:
- Ingen annen konform implementasjon kan reprodusere fasiten byte for byte. Kravet i
:29gjelder enhver konform implementasjon, ikke den som lagde fikstursettet. Kravet blir uoppfyllbart ved konstruksjon for alle andre enn én. Golden regressionfyrer 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
generatedligger i bytene: fire filer hosllm-ingestion-okf, alle på:8, inne i prefikset. Del (ii) av funnet — atGolden 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 :29s 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-claudes
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:
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.mdog fortrenger ingen av dem. - Hva
llm-ingestion-okfgjø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 :214blant 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.mds 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.