docs(plan): innboksrunden — V1 utvidet med tre målte funn, §7.2-siteringen ref-bundet
Fire innkomne meldinger, hvert premiss målt mot kilden før noe ble skrevet.
V1 (§3.1, ny): po-claudes «generated er et eierskaps-predikat i v0.3.2» er
målt. Porten er en KONJUNKSJON (generated=="true" AND ingest_manifest) — deres
egen kodekommentar sier det, og det er ordrett hva §3 krever («the check is on
the complete stamp, never on the individual field names»). Ingen predikat-
konflikt; V1-blokkeringen er dermed oppløst ved måling. Det meldingen FAKTISK
avdekker er en migrasjonskostnad: emitter (:103) og port (:89) kobles av
strengliteralen "true", så en mapping-form feller begge samtidig — under O1 og
O2 likt. Og en versjonsforskjell ingen av meldingene så: porten er GLOBAL i
v0.3.2 (som begge konsumenter kjører) men PER MANIFEST i okfs HEAD.
V1 (§6.2.1, ny): okfs fire svar, ført som DERES måling og ikke foldet inn i
våre tall. Q1 gjør :29 til en misforståelse i spec-teksten, ikke en drift som
skal lukkes — settet var aldri ment som den delte fasiten. Q2 gir fire utalte
sømmer (NULL ⊥ tom celle, kredensial-indireksjon, N>1-indeks, http-hermetikk).
Q3 bekreftet i begge trær: stampen bærer FILNAVNET, ikke bare bytene.
V1 (§7, ny): aktørkonvensjonen for intervju-født innhold er rutet hit på en
navnekollisjon — de tre aktørformene er OKF SPEC.md §7, vår §7 sier «Literally
true» og har 0 treff på aktørformer. Lag-skillet gjør spørsmålet uavhengig av
alle fire opsjoner: operatøren trenger IKKE løse det for å løse V1.
amendment-underlag §7.2: siteringen «:112-114» var HEAD-relativ OG av med én
linje. Ref-bundet til seksjon + ordrett tekst med begge refs oppgitt. Målt:
begge konsumenter står på 7aa53fc (diff-verifisert, identisk), altså ÉN commit
bak — ikke to. MCP-ankeret ligger på :101 i deres kopi, så ugatingen henger
ikke på en pull.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017SZwVVymdJMqntebsHtsZS
This commit is contained in:
parent
84a301057f
commit
ab0ea8f722
2 changed files with 232 additions and 14 deletions
|
|
@ -58,7 +58,7 @@ skrive før pakken lukkes:
|
|||
|
||||
**S2.2–2.4 (D-B)** var det ene punktet commons ikke kunne ankre. **Substansen kom 2026-07-26**
|
||||
og er ført i §7.1–7.2: D-B er en *scope*-beslutning, ikke spec-tekst. **To av de tre gatede
|
||||
storiene viste seg UGATED** — S2.2 fordi `:113-114` normativt plasserer MCP-konnektorer i
|
||||
storiene viste seg UGATED** — S2.2 fordi §4s `http`-punkt normativt plasserer MCP-konnektorer i
|
||||
`http`-familien (MUST på samme kontrakter), S2.4 fordi berikelsen holder seg innenfor §8s tre
|
||||
felt. **Kun S2.3 (`doc`) krever amendment.** Begge frigjøringene kom av ankring i frossen tekst,
|
||||
ingen av dem av en endring.
|
||||
|
|
@ -352,7 +352,7 @@ construction)*; (3) dokument-konnektor-avgrensning *(PDF via `pypdf` nå, DOCX u
|
|||
|
||||
| Story | Krever ingest-spec-amendment? | Hva |
|
||||
|---|---|---|
|
||||
| **S2.2** MCP-konnektor | **NEI — UGATED** (se §7.2) | `:113-114` sier normativt at en MCP-konnektor **er en utvidelse av `http`-familien** med MUST på samme kontrakter. Ingen ny familie, ingen amendment. Bygges mot `http` + §8-grant |
|
||||
| **S2.2** MCP-konnektor | **NEI — UGATED** (se §7.2) | §4s `http`-punkt (HEAD `:113-114` = pin `:101-102`) sier normativt at en MCP-konnektor **er en utvidelse av `http`-familien** med MUST på samme kontrakter. Ingen ny familie, ingen amendment. Bygges mot `http` + §8-grant |
|
||||
| **S2.3** Dokument-konnektor | **JA** — ny kildefamilie | `{type: "doc"}`. PDF→OKF-konseptfil med provenance, deterministisk mot committede fixtures |
|
||||
| **S2.4** Konnektor-herding | **NEI — UGATED** (bekreftet av po) | Timeout-parameter, feilkategorisering, beriket §8-logg (kilde/tidspunkt/radantall — aldri innhold). Retry KUN hvis D-B sier ja (default nei, av hensyn til determinisme). Inkrementell re-ingest: **ikke**, med mindre D-B amender §8 |
|
||||
|
||||
|
|
@ -383,16 +383,34 @@ i commons FØRST» — til noe som må avgjøres, ikke antas:
|
|||
Avsnittet over stilte (a)/(b) som et åpent valg. **Det var feil, og `portfolio-optimiser` fant
|
||||
hvorfor: det finnes et ANDRE anker vi ikke siterte, og det er normativt.**
|
||||
|
||||
> **`ingest-spec.md:112-114`** (§4, kildetypelisten)
|
||||
> **`ingest-spec.md` §4, kildetypelisten, `type: "http"`-punktet** — sitert ORDRETT fordi
|
||||
> linjenumrene ikke overlever pull-grensen (se rammen under):
|
||||
> `type: "http"` — a remote endpoint (OPTIONAL extension point, §1). Field `base_url`: the
|
||||
> endpoint base; it MUST NOT embed credentials. Optional field `credential_ref`: the NAME of
|
||||
> a runtime-resolved secret reference. **An MCP-based connector is an extension of this family
|
||||
> and MUST honour the same extraction, materialization, and gate contracts.**
|
||||
|
||||
`:29-31` sier at MCP-veien ikke krever spec-endring. `:112-114` sier **normativt hvor den hører
|
||||
hjemme** — som en utvidelse av `http`-familien, med **MUST** på de samme kontraktene. Frossen
|
||||
tekst har altså allerede valgt (b). En fjerde `{type: "mcp"}`-familie ville **motsagt** `:113-114`,
|
||||
ikke utfylt den.
|
||||
> **⚠️ Ref-binding for sitatet over (korr. 2026-07-27, meldt av `repos`).** Avsnittet siterte
|
||||
> tidligere «`:112-114`» uten ref. To feil i én: (1) numrene er HEAD-relative, og konsumentene
|
||||
> står på `7aa53fc`; (2) selv mot HEAD var de av med én linje. Målt:
|
||||
>
|
||||
> | Ref | MCP-setningen | Hele `http`-punktet |
|
||||
> |---|---|---|
|
||||
> | commons HEAD | `:113-114` | `:111-114` |
|
||||
> | `7aa53fc` (konsumentenes pin, verifisert identisk i BEGGE arbeidstrær) | `:101-102` | `:99-102` |
|
||||
>
|
||||
> **Failure-moden er grunnen til at dette er verdt en korreksjon:** en konsument som slår opp
|
||||
> `:112-114` i SIN fil finner ikke ingenting — den finner felt-tabellen for `extractions`
|
||||
> (`id`/`title`/`query`), troverdig og relatert spec-tekst uten et ord om MCP. Den mest
|
||||
> sannsynlige konklusjonen er da at ankeret ikke finnes og at kjennelsen hviler på løs grunn.
|
||||
> Et åpenbart tomt treff hadde vært tryggere. **Regel, samme klasse som `git log -S`-regelen
|
||||
> under: sitér SEKSJON + ORDRETT TEKST når mottakeren står på en annen ref — eller skriv
|
||||
> hvilken ref numrene gjelder.**
|
||||
|
||||
`:29-31` sier at MCP-veien ikke krever spec-endring. `http`-punktet sier **normativt hvor den
|
||||
hører hjemme** — som en utvidelse av `http`-familien, med **MUST** på de samme kontraktene.
|
||||
Frossen tekst har altså allerede valgt (b). En fjerde `{type: "mcp"}`-familie ville **motsagt**
|
||||
MCP-setningen, ikke utfylt den.
|
||||
|
||||
**Konsekvens: S2.2 er UGATED.** Premisset «krever ingest-spec-amendment i commons FØRST» er
|
||||
avkreftet av vår egen frosne tekst. S2.2 kan bygges mot `http`-familien + §8s opt-in-grant uten
|
||||
|
|
@ -406,9 +424,9 @@ PDF-parser. Det er deres anbefaling til ratifisering, ikke en beslutning.
|
|||
|
||||
**(a)-argumentet lever videre, men som implementasjonssak, ikke spec-tekst.** At
|
||||
`base_url`/`credential_ref` passer dårlig på en kommando, og at env-var-med-kommando er en
|
||||
subprosess-grant, er ekte friksjon — men `:113-114` sier MUST på *kontraktene*, ikke på
|
||||
subprosess-grant, er ekte friksjon — men MCP-setningen sier MUST på *kontraktene*, ikke på
|
||||
*feltnavnene*, og §8 dekker «any other non-local transport». Friksjonen lever i hvordan en
|
||||
kommando uttrykkes innenfor `http`-familien. Støter implementasjonen faktisk på noe `:113-114`
|
||||
kommando uttrykkes innenfor `http`-familien. Støter implementasjonen faktisk på noe MCP-setningen
|
||||
forbyr, er det et målt funn og kommer tilbake hit.
|
||||
|
||||
**Vår egen feil, ført åpent fordi den er tredje instans samme dag:** vi skrev at `:29-31` var
|
||||
|
|
@ -471,7 +489,7 @@ method-spec navngir aldri en repo-sti (`grep -c 'examples/' method-spec.md` →
|
|||
| 4 | S4.0 / D-A#2 kostbaseline | method §7 `:332-333`, §7.1 `:345-346` | ekte hull | **endrer fasit hvis ubetinget** |
|
||||
| 5 | S3.5 / D-F tittel-whitespace | ingest §4 `:125`, §5 `:158-161`, §6 `:194-197`, §11 `:278` | ekte, smal søm | ingen |
|
||||
| 6 | D-A#5 hovedbok-projeksjoner | ingen tekst; naboer method §7.2 `:367-372`, §12 `:436-464` | **ny seksjon** | ingen direkte; §12 må utvides |
|
||||
| 7 | S2.2–2.4 / D-B | **ANKRET** (§7.1–7.2): kun **S2.3** (`doc`) krever amendment. **S2.2 + S2.4 er UGATED** — S2.2 av `:113-114`, S2.4 innenfor §8s tre felt | **scope-beslutning, ikke spec-tekst** | ingen |
|
||||
| 7 | S2.2–2.4 / D-B | **ANKRET** (§7.1–7.2): kun **S2.3** (`doc`) krever amendment. **S2.2 + S2.4 er UGATED** — S2.2 av §4s `http`-punkt, S2.4 innenfor §8s tre felt | **scope-beslutning, ikke spec-tekst** | ingen |
|
||||
| 8 | B1 / D4 nav-golden | levert `b641741`; 0 spec-referanser | commons-eget, utenfor pakken | — |
|
||||
|
||||
Commons' rolle er uendret: vi forbereder underlaget, operatøren ratifiserer, og frossen tekst
|
||||
|
|
@ -504,7 +522,7 @@ endres ikke uten den ratifiseringen.
|
|||
| D-B-substansen levert 07-26 | coord fra `portfolio-optimiser` | rapportert fra deres `sesjonsplan-fase2-6.md:56-62`, ikke målt av oss |
|
||||
| §1 gjør `http` OPTIONAL, `file`+`sql` påkrevd | `ingest-spec.md:27-31` | ordrett sitert i §7.1 |
|
||||
| …og nevner MCP som `http`-transport | `ingest-spec.md:29-31` | «or via an MCP-based connector … does not require any change to this spec» |
|
||||
| **ANDRE anker: MCP hører NORMATIVT til `http`** | `ingest-spec.md:112-114` | «An MCP-based connector **is an extension of this family** and **MUST** honour the same … contracts» |
|
||||
| **ANDRE anker: MCP hører NORMATIVT til `http`** | `ingest-spec.md` §4, `http`-punktet (HEAD `:113-114` = pin `:101-102`) | «An MCP-based connector **is an extension of this family** and **MUST** honour the same … contracts» |
|
||||
| Begge MCP-ankere landet i `7aa53fc`, ikke `bfa5a9b` | `git log -S` på hver frase | `7aa53fc` for begge — altså i konsumentenes egen kopi |
|
||||
| `bfa5a9b` rørte kun stempelmodellen | `git show --stat bfa5a9b` | 39 innsettinger, D1-stempel |
|
||||
| §8 logger tre felter | `ingest-spec.md:230` | «which source, when, row count» |
|
||||
|
|
|
|||
|
|
@ -79,6 +79,60 @@ innhold legitimt kunne bære en `generated`-mapping med en helt annen `by`.
|
|||
> `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
|
||||
|
|
@ -243,7 +297,134 @@ Dette er et **selvstendig punkt**, ikke en del av V1, og det er ikke i køen. De
|
|||
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å».
|
||||
|
||||
## 7. Det som ikke er commons' å avgjøre
|
||||
#### 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
|
||||
|
|
@ -252,7 +433,7 @@ en delt fasit vi har», men «dette sementerer at en delt fasit aldri kan oppst
|
|||
Bare DEFAULT staterer vårt lag.
|
||||
- **Om produsent-identitet skal logges et annet sted** (O2s pris). Implementasjonens valg.
|
||||
|
||||
## 8. Det som ikke endres uansett utfall
|
||||
## 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
|
||||
|
|
@ -284,7 +465,7 @@ line-oriented-krav, og `ingest_manifest` som stempelets andre halvdel. Ingen ops
|
|||
| …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` | `frontmatter.get("generated") != "true"` + stem-match |
|
||||
| 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 |
|
||||
|
|
@ -294,3 +475,22 @@ line-oriented-krav, og `ingest_manifest` som stempelets andre halvdel. Ingen ops
|
|||
| 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`) |
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue