okr/docs/innboks-ingestion-veivalg-2026-06.md

# Innboks-ingestion — veivalg og posisjon (2026-06-26)

> **Operatør-låst retning for okr-pluginens innboks-ingestion.** Avstemmer okr-STATE mot den
> cross-cutting convergence-briefen (`linkedin-studio/docs/okf-convergence-brief.md`). Self-bearing —
> leses ved oppstart av ingestion-løpet. **Teknisk grunnlag (web-verifisert):**
> `docs/innboks-ingestion-funn-2026-06.md`. Status-of-play: `STATE.md`.

> **RATIFISERT 2026-06-29 (handoff `catalog/docs/okf-second-brain/handoff-2026-06-29.md` §3).** Den
> delte konvensjonen er nå kanonisert i `catalog/docs/okf-second-brain/spec.md` v0.1 (single source of
> truth, katalog-eid). Dette dokumentet **refererer** spec-en — det redefinerer den ikke. Innboks-løpet
> bygger mot spec §3 (minimal kontrakt = gulv, ikke tak) + §5 (extension keys). okr-bekreftelser (§4):
> `okf-check.mjs`-semantikken står som referansekontrakt (spec §7); okr bruker `resource` (ikke
> `source`); ingen feltgap (profil/config-nøkler = extension keys). Premiss-korreksjonene i §2 under er
> nå kanonisert i spec §9.

## 1. Låste beslutninger (operatør, 2026-06-26)

1. **Innboks-ingestion SKAL bygges for okr.** Ikke valgfritt, ikke «defer». Krever **grundig
   planlegging** — eget Voyage-løp (`/trekbrief` → `/trekplan` → execute), egen minor-bump
   (1.7.0-kandidat). Start når operatør sier fra (scope-guard).
2. **linkedin-studio er IKKE en mal for okr.** Deres second-brain har en *annen tilnærming*
   (provenans-vektet læring, episodisk/semantisk split, evidens-terskel-promotering) som vi
   **ikke kopierer**. okr bygger sin egen sti.
3. **Delt cross-repo OKF-skill: ikke nå.** Stage 3 (betinget) i convergence-briefen — utsatt.
   okr-ingestion er okr-eid og ikke gated på en delt skill.

## 2. Avstemming mot convergence-briefen (hva gjelder for okr)

Convergence-briefen er linkedin-studio-sentrert og cross-cutting. For **okr** skiller vi
verifiserte tekniske fakta (beholdes) fra strategisk framing (avvises):

**BEHOLD — verifiserte tekniske premisser (gjelder uansett strategi):**
- Google `knowledge-catalog` har **ingen** innboks→OKF-pipeline (funn §2, brief §2). Vi får spec +
  byggeklosser, ikke en ferdig løype.
- `mdcode` er **ikke** et OKF-verktøy — det er Dataplex git-sync med et *annet* frontmatter-schema
  (`id`/`resource.name`/`createTime`/`links`). **Ikke** planlegg `kcmd` til å emittere/synke OKF.
- Googles `reference_agent` ER en OKF-produsent, men leser **BigQuery + seed-URLer**, ikke en
  dokumentmappe, og er Gemini/GCP-bundet. Gjenbrukbare (GCP-frie) deler: SPEC, emit/serialize/
  validate-kjernen, `index.md`-syntese.
- **Dokument-klassifisering/-konvertering av vilkårlige filer: Google gir INGENTING** — 100 % bygg
  selv.
- OKF-relasjoner = **vanlige markdown-lenker i body** (ikke frontmatter-felt); konsumenter MÅ
  tolerere brutte lenker (funn §4, brief §5).
- **OKF v0.1-spec finnes** på `okf/SPEC.md` (distinkt fra `mdcode`s «Metadata as Code» for Dataplex).
  Kun `type` påkrevd; `index.md` reservert (ingen frontmatter); `okf_version` i rot-`index.md`.
  *(NB: okr 1.6.0 pinnet bevisst til «Documents/kb Layout» og kalte det IKKE en formell standard —
  ingestion-løpet bør re-verifisere `okf/SPEC.md` ved brief-tid og avgjøre hvor tett vi konformer.)*

**AVVIS for okr — strategisk framing som IKKE styrer okr-ingestion:**
- «Defer auto-classify/convert; build only on demonstrated need» → **avvist** (beslutning 1: skal bygges).
- «linkedin-studio is the reference design; siblings rise to it» → **avvist for okr** (beslutning 2).
- «Inbox forblir en manuell drop-zone uten auto-klassifiserer» → det var linkedin-studios stance;
  okr-målet er det motsatte: **auto-oppdage + konvertere + tilordne OKF**.

## 3. Hva som faktisk skal bygges (gap, fra funn-grunnlaget §5)

1. **Dokument-konvertering** — PDF/Word/e-post/tekst → markdown. Finnes ikke i Google-repoet
   (`fileskb`/`md-fileset` antar markdown og er read-only).
2. **Konsept-ekstraksjon + frontmatter-tilordning** — splitte vilkårlige dokumenter til «konsepter»,
   sette `type`/`resource`/`title`/`description`/`tags`/`timestamp`.
3. **Generalisert relasjons-oppdagelse** — Googles relasjons-prompt er BQ-joins/web-spesifikk; må
   generaliseres til vilkårlig dokumentkorpus (relasjoner som markdown-lenker i body).
4. **Innboks-orkestrering** — oppdage nye filer, **beholde original + plassere markdown-peker**,
   idempotent re-kjøring, plassering i riktig nivå av treet, regenerere berørt `index.md`.

## 4. Gjenbrukbart fra OKF-fasen (1.6.0 — bygger ikke fra null)

- `scripts/okf-index.mjs` — kildeagnostisk, idempotent `index.md`-regen (speiler Googles
  `regenerate_indexes`). Innboks-pipelinen kaller den etter skriv (som tre-skriverne i `oppsett.md`).
- `lib/frontmatter.mjs` (parse/skrive) + `scripts/okf-check.mjs` (validering) dekker skrive- og
  verifiserings-siden.
- Googles `Source`-ABC viser et rent adapter-mønster — en «innboks-kilde» som lister konsepter fra en
  mappe kan mate eksisterende skrive-/index-/kryss-lenke-maskineri.

## 5. Åpne spørsmål til `/trekbrief` (avgjøres da, ikke nå)

- **Konverterings-motor:** okr er i dag **zero-dependency Node ESM** (kun `node:`-builtins). PDF/Word→md
  krever realistisk enten et eksternt verktøy (pandoc/libreoffice/markitdown) eller en avhengighet —
  **bryter zero-dep-invarianten**. Dette er et reelt arkitekturvalg (dokumentert prerequisite à la
  `export-pdf.py`/weasyprint? egen avhengighet? hvilke formater i v1?).
- **Konsept-ekstraksjon:** LLM-drevet (Claude i kommando) vs. heuristisk splitting — og hvor deterministisk.
- **Relasjons-oppdagelse:** hvor generalisert; hvordan holde testbart.
- **Innboks-plassering:** prosjekt-`.claude/okr/innboks/`? home? begge røtter? Original-bevaring + peker-layout.
- **Mål-format:** full OKF v0.1 (`okf/SPEC.md`) vs. dagens lettere «OKF-kompatible form» okr emitterer.
- **Idempotens + sikkerhet:** re-kjøring uten dubletter; ikke ødelegge brukerens originaler.

## 6. Forhold til søsken-pluginer

- **Delings-scope (operatør-låst 2026-06-29):** en eventuell delt Stage-3-skill deles mellom
  **okr + ms-ai-architect** — **IKKE linkedin-studio**. linkedin-studio har sin egen mekanisme
  (rikere ikke-OKF-brain, reference-design — «not levelled down to bare OKF», brief §1) og leveres
  ikke ned til en delt skill. Låsen endrer kun *hvem* som deler, ikke *når*: Stage 3 er fortsatt
  betinget på Stage-2-måling og utsatt.
- `ms-ai-architect` har samme oppgave (designet, ikke bygget). **Vurder felles abstraksjon før
  dobbel-implementasjon** — men felles ≠ kopiere linkedin-studio. Eventuell deling skjer på okr-egne
  premisser.
- En delt OKF-**spec** (convergence-briefens Stage 1, katalog-nivå) er grei interop og ikke i konflikt
  med dette løpet; okr-ingestion er ikke blokkert på den.

## 7. Kilder

- **Delt konvensjon (single source of truth):** `catalog/docs/okf-second-brain/spec.md` v0.1 + koordinerings-`log.md` + `handoff-2026-06-29.md` (samme mappe, katalog-repo).
- `docs/innboks-ingestion-funn-2026-06.md` — web-verifisert Google-repo-analyse (kilder i §9 der).
- `linkedin-studio/docs/okf-convergence-brief.md` — cross-cutting convergence (avstemt over; nå foldet inn i spec-en).
- OKF v0.1: `github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md`.
- Leveranse vi bygger på: okr 1.6.0 (`scripts/okf-*`, `lib/frontmatter.mjs`, skill `okr-second-brain-search`).