Infosystem

KONSEPTER

  • Informasjonsøkosystem(hubside)
    • Faktaflyt (infrastruktur/identitet, signatur, proveniens)
    • Åpen Hendelsesprotokoll (OHP)(hendelsesknutepunkt)
      • Hendelsesprosess-modellen (HPM) (oppdeling i prosesselementer)
    • Sann & Sans (lagdeling) (Observasjon / Vitne / Analyse / Mening)
    • OAR-standarden (kvalitet: Observability–Agreement–Replicability)
    • MP-standarden (menneskepåvirkning: MP0–MP3)
    • Sannhetsbroen (dialog, perspektivkart, brobygging)
    • Eksempler (trafikk, skole, arrangement – “Hva vi vet / ikke vet”)

1) «Informasjonsøkosystem» (hubside)

Formål: Gi leseren 1) helhetsbildet, 2) tydelige roller for hvert delkonsept, 3) raske lenker videre.

Innholdsmal

  • H1: Informasjonsøkosystemet – fra kilde til forståelse
  • Ingress (2–3 setninger): Kort hvorfor dette trengs, og at KI brukes til å samle, strukturere og lage forklarlige oppsummeringer.
  • H2: Slik henger det sammen
    • Faktaflyt: Grunnmur (identitet, signatur, proveniens, versjoner).
    • OHP: Hendelsesknutepunkt som samler alt om samme tid/sted.
    • HPM: Deler hendelsen i prosesselementer (start–slutt, faser).
    • Sann & Sans: Skiller lag i visningen (Observasjon/Vitne/Analyse/Mening).
    • OAR: Kvalitetsmålet (0–9) som alle forstår.
    • MP: Skalerer beviskrav etter konsekvens (MP0–MP3).
    • Sannhetsbroen: Trygg dialog og perspektivkart – uten å dømme.
  • H2: Hva du får som leser
    • «Bare kilden»-visning, tydelige prosesselementer, «Hva vi vet/ikke vet», rett-til-svar når det gjelder.
  • H2: Videre
    • Knapper/lenker til undersidene (Faktaflyt, OHP, HPM, Sann & Sans, OAR, MP, Sannhetsbroen, Eksempler).

Anbefalt slug: informasjonsokosystem (unngå æøå i slug)

2) «Åpen Hendelsesprotokoll (OHP)»

Formål: Hva OHP er og gjør.

Innholdsmal

  • H1: Åpen Hendelsesprotokoll (OHP)
  • Ingress: Førstemelder oppretter en hendelse (HK). Alle bidrag om samme hendelse knyttes hit. KI hjelper å samle, deduplisere og versjonere.
  • H2: Nøkkelideer
    • Hendelsesknutepunkt (HK): global ID, tid, sted, tittel.
    • Bidragstyper: Observasjon (objektiv), Vitneerfaring (subjektiv), Analyse (sammenstilling), Mening (normativt).
    • Incident Snapshot vN: «Hva vi vet / hva vi ikke vet» med lenker til bevis.
  • H2: Når passer OHP? Trafikk, skole, arrangement, offentlig rom, osv.
  • H2: Eksempel (kort) – ett konkret case i 6–8 linjer.
  • Lenker nederst: HPM, Sann & Sans, OAR, MP, Sannhetsbroen.

Slug: apen-hendelsesprotokoll

3) «Hendelsesprosess-modellen (HPM)»

Formål: Hvordan hendelser deles opp i forklarlige biter.

Innholdsmal

  • H1: Hendelsesprosess-modellen (HPM)
  • Ingress: KI foreslår prosesselementer (PE) med start–slutt og fase.
  • H2: Faser (standard)
    • Forkant → Utløsende → Oppstart → Eskalering → Toppunkt → Stabilisering → Oppløsning → Etterkant
  • H2: Når blir det et nytt PE?
    • Ny aktør/objekt, nytt sted/sikt/lys, tydelig handlingsskifte, ny uavhengig vinkel, eller tiltak igangsatt.
  • H2: Kvalitet per PE
    • OAR og MP beregnes per del – ikke bare for totalen.
  • H2: UI-grep
    • Prosess-tidslinje, trådspor per aktør, bevisvarmekart, hull-markører («mangler høyrevinkel 60–90° i 12s»).
  • Lenker nederst: OHP, OAR, MP.

Slug: hendelsesprosess-modellen

4) «Sann & Sans (lagdeling)»

Formål: Lære brukerne lagene og hvorfor de aldri blandes.

Innholdsmal

  • H1: Sann & Sans – lagdeling av informasjon
  • H2: Fire lag
    • Observasjon: objektiviserbar sansing (råfiler/metadata, gjerne signert).
    • Vitneerfaring: subjektiv opplevelse (følelser, usikkerhet).
    • Analyse: metodeforklart sammenstilling (f.eks. konfliktanalyse).
    • Mening: normative forslag/prioriteringer.
  • H2: Hvorfor dette er viktig
    • Forklarlighet, rettferdighet, færre misforståelser.

Slug: sann-og-sans

5) «OAR-standarden»

Formål: Gjør kvalitetsskåren forståelig for alle.

Innholdsmal

  • H1: OAR – kvalitetsmålet (0–9)
  • H2: Slik regnes den ut
    • O (Observability 0–3): 0 rykte · 1 vitne · 2 én sensor/vinkel · 3 flere uavhengige sensorer/vinkler
    • A (Agreement 0–3): 0 ukjent · 1 to kilder · 2 ≥3 kilder eller to uavhengige sensorer · 3 både sensorer og flere vitner
    • R (Replicability 0–3): 0 ikke etterprøvbart · 1 delvis · 2 rådata+metadata · 3 uavhengig verifisert
  • H2: Tolkning
    • 0–3 svak, 4–5 moderat, 6–7 god, 8–9 svært sterk.
  • H2: Eksempel – kort før/etter når ny vinkel løfter A og R.

Slug: oar-standarden

6) «MP-standarden»

Formål: Vise at beviskrav skalerer etter konsekvens.

Innholdsmal

  • H1: MP – menneskepåvirkning (MP0–MP3)
  • H2: Nivåene kort
    • MP0 Akutt, MP1 Høy, MP2 Middels, MP3 Lav.
  • H2: Krav ved MP1/MP2
    • Minstekrav til evidens (f.eks. 2 vinkler eller 1 vinkel + 2 vitner), rett-til-svar, juss/etikk-kontroll, personvernminimering.
  • H2: Enkeltvinkel-regelen
    • Ett kamera ⇒ synlig banner + maks MP2 til mer evidens.

Slug: mp-standarden

7) «Sannhetsbroen»

Formål: Plasser dialogen riktig.

Innholdsmal

  • H1: Sannhetsbroen – trygg dialog på toppen av fakta
  • H2: Hva den er
    • Fasilitert samtale om forståelse, ikke en sannhetsdommer.
  • H2: Verktøy
    • Perspektivkart, åpne motforestillinger, forklarbar KI (struktur, ikke dom).
  • H2: Koblinger
    • Lenker alltid til Incident Snapshot og relevante PE.

Slug: sannhetsbroen (du har siden allerede – bare oppdater teksten slik at mandatet er krystallklart)

8) «Eksempler»

Formål: Gi leserne raske «sånn ser det ut i praksis».

Innholdsmal

  • H1: Eksempler
  • H2: Trafikk – 6–8 linjer + “Hva vi vet/ikke vet”
  • H2: Skole – én vinkel først, hvordan OAR/MP oppdateres når ny vinkel kommer
  • H2: Arrangement – crowd, flere vitner, god A og R

Slug: eksempler-informasjonsokosystem

Praktiske tips

  • Krysslenk smart: Nederst på hver underside, legg «Relaterte konsepter» (3–5 lenker).
  • Konseptoversikt: Oppdater oversikten med «pills/merkelapper» for rolle: Infrastruktur, Applikasjon, Standard, Dialog.
  • Språk/slug: Bruk norske titler, men enkle slugs uten æ/ø/å (a/ae/o).
  • Ikonsett (valgfritt): Gi hvert konsept et ikon (grunnmur, hendelse, tidslinje, lag, måler, varseltrekant, bro).

Åpen Hendelsesprotokoll (OHP) – Hendelsesknutepunkt

Kort forklart: OHP er «samlepunktet» for alt som tilhører samme hendelse (tid/sted/tema). Første melder oppretter en sak (HK = Hendelsesknutepunkt). Alle senere bidrag – video, lyd, sensordata, vitneerfaringer, analyser og meninger – kobles til samme HK. KI (kunstig intelligens) hjelper med å oppdage duplikater, samle like saker, foreslå struktur og lage løpende, versjonerte oppsummeringer (Incident Snapshot).

Formål

  • Samle all relevant informasjon om én hendelse i en ryddig, etterprøvbar struktur.
  • Sikre tydelig skille mellom kilde/fakta, opplevelser, analyse og mening (Sann & Sans).
  • Gjøre det lett for mennesker å forstå «Hva vi vet / Hva vi ikke vet» til enhver tid.

Kjerneprinsipper

  • Én hendelse – ett knutepunkt.
  • Signert og sporbar publisering (identitet, tid, sted, versjoner).
  • Streng lagdeling i visning (Observasjon, Vitne, Analyse, Mening).
  • Append-only: ingenting slettes; feilkorrigering skjer som ny versjon.

Nøkkelobjekt: Hendelsesknutepunkt (HK)

Minimumsfelter i HK:

  • EID (global hendelses-ID)
  • Tittel (nøktern, uten skyldspåstand)
  • Hvor (lat/lon + presisjon / geohash)
  • Når (start–slutt, kan være foreløpig)
  • Tema/tags
  • Status (åpen/under vurdering/publisert/oppdatert/arkivert)
  • MP-nivå (menneskepåvirkning) og OAR-sum (se egne standarder)
  • Versjon (v1.0, v1.1 …)

Bidragstyper (knyttes til HK)

  • Observasjon: objektiviserbar sansing (råfiler + metadata).
  • Vitneerfaring: subjektiv opplevelse (følelser/inntrykk).
  • Analyse: metodeforklart sammenstilling/konfliktanalyse.
  • Mening: normative forslag/prioriteringer.
    (Lagene blandes aldri i samme kort.)

Prosessflyt

  1. Førstemelder oppretter HK (tid, sted, tittel).
  2. KI foreslår sammenslåing hvis lik sak finnes (geotid/semantikk).
  3. Bidrag strømmer inn (Observasjon/Vitne/Analyse/Mening).
  4. KI oppretter/foreslår prosesselementer (HPM) og tråder per aktør/objekt.
  5. OAR (kvalitet) og MP (konsekvens) beregnes – per bidrag og per prosesselement.
  6. Systemet publiserer Incident Snapshot vN («Hva vi vet / ikke vet»).
  7. Nye bevis → ny versjon. Historikk bevares.

UI-mønstre (anbefalt)

  • Lagvelger: Observasjon | Vitne | Analyse | Mening.
  • Hendelsesoverskrift + EID + versjon + MP-badge + OAR-sum.
  • «Hva vi vet / Hva vi ikke vet» alltid synlig med lenker til bevis.

Eksempel (kort)

«Kollisjon ved Torget 08:12» → to mobilvideoer + buss-dashcam + tre vitner. OHP samler alt, HPM deler hendelsen i del-episoder, OAR øker når buss-dashcam kommer inn, Snapshot oppdateres til v1.3.

Koblinger

  • Faktaflyt: publiserings- og proveniensgrunnmur.
  • HPM: prosess/oppdeling av hendelsen.
  • Sann & Sans: lagdeling i visning.
  • OAR/MP: kvalitet og varsomhet.
  • Sannhetsbroen: trygg dialog og perspektivkart på toppen av fakta

Hendelsesprosess-modellen (HPM) – Oppdeling i prosesselementer

Kort forklart: HPM gjør hendelser forklarlige ved å bryte dem opp i tidsavgrensede prosesselementer (PE) med start–slutt, fase og egen bevisdekning. KI foreslår naturlige brudd (ny aktør, nytt sted/lys/sikt, handlingsskifte, nytt kamera).

Hvorfor prosess?

  • Hendelser er forløp, ikke enkeltbilder.
  • Bedre presisjon: kvalitet (OAR) og konsekvens (MP) vurderes der de hører hjemme i tidslinjen.

Standard faser (kan tilpasses)

  • Forkant: forutsetninger/opptakt.
  • Utløsende: hendelsen som starter forløpet.
  • Oppstart: første reaksjoner/bevegelse.
  • Eskalering: intensivering/konflikt opptrappes.
  • Toppunkt: mest kritiske øyeblikk.
  • Stabilisering: roer seg/tiltak virker.
  • Oppløsning: hendelsen avsluttes.
  • Etterkant: oppfølging/konsekvenser.

Når opprette nytt PE?

  • Ny aktør kommer inn/ut.
  • Vesentlig endring i sted/lys/sikt/lyd.
  • Klart handlingsskifte (verbal → fysisk, løp → stans).
  • Ny uavhengig kameravinkel/sensor blir tilgjengelig.
  • Tiltak iverksettes (varsling, førstehjelp, politi ankommer).

Felter per PE (minimum)

  • peid, t_start–t_end, fase, thread (aktør/objekt),
  • lenker til Observasjoner og Vitneerfaringer,
  • oar{o,a,r,sum}, mp_level,
  • unknowns[] (hull/blindsoner), needs[] (hva som mangler),
  • kort summary (nøkternt) + signatur/versjon.

Regler

  • Ingen kausalitet inne i PE-kortet. Årsak/skyld er Analyse.
  • Én-vinkel-regel per PE: bare ett kamera ⇒ «enkeltvinkel-banner» og maks MP = MP2 til mer evidens.
  • Bitemporalitet: skill hendelsestid (t_start/ t_end) fra registreringstid (når data kom inn).

UI-mønstre

  • Prosess-tidslinje (PE-blokker) med OAR/MP-badge.
  • Trådspor pr. aktør/objekt.
  • Bevis-varmekart (hvor er dekningen sterk/svak).
  • Hull-markører («mangler høyrevinkel 60–90° i 12 s»).

Eksempel (kort)

PE-001 Forkant → PE-002 Utløsende (gjenstand kastes) → PE-003 Eskalering (fysisk kontakt) → PE-004 Oppløsning (tredjepart skiller). OAR/MP settes per PE; Snapshot samler «Hva vi vet/ikke vet».

Koblinger

  • OHP: HK som ramme for PE-ene.
  • Sann & Sans: visning per lag.
  • OAR/MP: kvalitet/varsomhet pr. PE.
  • Sannhetsbroen: drøfting av tolkning/konsekvenser uten å forurense PE-ene.

Sann & Sans – Lagdeling (Observasjon / Vitne / Analyse / Mening)

Kort forklart: Sann & Sans er presentasjonsreglene som aldri blander lag. Folk skal se hva som er målt/filmet, hva noen opplevde, hva som er sammenstilt/tolket, og hva som er mening – hver for seg.

Lagene

1) Observasjon

  • Hva: sansedata andre kan verifisere likt (video/lyd/sensor) med råfiler/metadata.
  • Krav: innholds-/opprinnelsesbevis når mulig (signatur, sporbarhet).
  • Ikke tillatt: motiv/skyld/årsak, montasjer uten tydelig merking.

2) Vitneerfaring

  • Hva: subjektiv opplevelse (følelser, inntrykk, tolkning).
  • Krav: kontekst (posisjon/avstand/lys), egen sikkerhetsskår.
  • Visning: aldri blandet med Observasjon i samme kort.

3) Analyse

  • Hva: metodeforklart sammenstilling (f.eks. hvorfor to vinkler «motsier hverandre», parallakse).
  • Krav: eksplisitt lenking til Observasjoner/Vitner + beskrevet metode.

4) Mening

  • Hva: normative vurderinger/forslag/prioriteringer.
  • Krav: lenk til fakta/Analyse som meningen bygger på.

UI-regler

  • Lagvelger i toppen av hver sak.
  • «Bare kilden»-modus (kun Observasjon).
  • Konflikter/uenighet vises som Analyse, aldri inne i Observasjon.

Eksempel (kort)

Én video + tre vitner: video → Observasjon, vitnene → Vitneerfaring, «hvorfor ser vinklene ulike ut?» → Analyse, «hva bør kommunen gjøre?» → Mening.

Koblinger

  • OHP/HPM: Sann & Sans styrer visningen av alt innhold.
  • OAR/MP: kvalitet/varsomhet vises på hvert lag.
  • Sannhetsbroen: dialog om forskjeller i forståelse – uten å endre kildelag.

OAR-standarden – Kvalitet (Observability–Agreement–Replicability)

Kort forklart: OAR er et enkelt, forklarbart mål (0–9) for hvor robust et bevisgrunnlag er – per bidrag og per prosesselement.

Slik beregnes OAR (0–3 på hver dimensjon)

O – Observability (observerbarhet)

  • 0: indirekte rykte/ukjent kilde
  • 1: én vitnebeskrivelse uten dokumentasjon
  • 2: én sensor/ett kamera med metadata
  • 3: flere uavhengige sensorer/vinkler (med metadata)

A – Agreement (uavhengig samsvar)

  • 0: ukjent/ikke vurdert
  • 1: to kilder samsvarer
  • 2: ≥3 kilder eller to uavhengige sensorer samsvarer
  • 3: både sensorer og flere vitner samsvarer

R – Replicability (etterprøvbarhet)

  • 0: ikke etterprøvbart
  • 1: delvis (mangler rådata/metadata)
  • 2: rådata + metadata tilgjengelig
  • 3: uavhengig verifisert av validator-noder/forensikk

Sum (0–9): 0–3 svak • 4–5 moderat • 6–7 god • 8–9 svært sterk.

Hvordan øke OAR

  • Få flere uavhengige vinkler/sensorer (øker O og A).
  • Del råfiler/metadata (øker R).
  • Tids-synk og vinkel-separasjon dokumentert (anbefalt ≥ 60°).

Visning/Notasjon

  • Skriv f.eks.: O2/A2/R1 (sum 5/9).
  • Vis OAR-badge på hvert prosesselement og i hendelsens topp.

Eksempel (kort)

Start: ett kamera uten råfil → O1/A0/R0 (1/9).
Ny vinkel + råfiler → O3/A2/R2 (7/9).
Uavhengig verifisering → O3/A3/R3 (9/9).

Koblinger

  • HPM: OAR beregnes per PE.
  • MP: krav til minstenivå stiger med MP-nivå.
  • Sann & Sans: OAR-merking vises i alle lag som berører fakta.

MP-standarden – Menneskepåvirkning (MP0–MP3)

Kort forklart: MP beskriver hvor mye informasjonen kan påvirke enkeltpersoner/grupper. Jo høyere MP, jo strengere beviskrav, varsomhet og kontroll før publisering.

Nivåer

  • MP0 – Akutt fare: liv/vesentlig skade nå. Kan varsles umiddelbart; full MP-prosess i etterkant.
  • MP1 – Høy: alvorlige anklager/store konsekvenser. Krever høy evidens, rett-til-svar, juridisk/etisk kontroll.
  • MP2 – Middels: moderat innvirkning/omdømme. Krever moderat evidens og tydelig usikkerhet.
  • MP3 – Lav: små konsekvenser. Fleksibelt; korrekt merking.

Minimumskrav per nivå (Observasjon)

  • MP1:
    • Minst to uavhengige vinkler/sensorer, eller én vinkel + to uavhengige vitner.
    • Råfiler/metadata tilgjengelige (R≥2).
    • Rett-til-svar før frontvisning; juss/etikk-kontroll.
  • MP2:
    • Minst én sensor/ett kamera eller to uavhengige vitner.
    • Tydelig usikkerhet og hva som mangler.
  • MP3:
    • Fleksibelt, men anbefal OAR-merking.

Særregel: Én-vinkel-regel

  • Bare ett kamera? Vis enkeltvinkel-banner og sett maks MP = MP2 til mer evidens kommer.

Personvern og rett-til-svar

  • Minimering (sladding av ansikt/skilt) når mulig uten å svekke beviskjernen – dokumentér hva/hvorfor.
  • MP1/MP2: synlig rett-til-svar-panel tilknyttet HK, med kort frist og versjonert logg.

Eskaleringsflyt

  1. Foreløpig MP-nivå i HK.
  2. KI/forensikk vurderer evidens opp mot krav.
  3. Godkjenning (ansvarlig red./ombud) for MP1/MP2 før frontvisning.
  4. Nye bevis → revisjon av MP-nivå og Snapshot-versjon.

Visning

  • MP-badge (MP0–MP3) på HK og på prosesselementer med betydelig risiko.

Eksempel (kort)

Skolevideo med én vinkel → MP2 (enkeltvinkel-banner).
Ny vinkel og uavhengig vitne → krav for MP1 kan oppfylles; publisering etter rett-til-svar og etikk/juss-kontroll.

Koblinger

  • OHP/HPM: MP settes i HK og per PE.
  • OAR: høyere MP krever høyere OAR.
  • Sann & Sans: MP påvirker varsom visning per lag.
  • Sannhetsbroen: dialog kanaliseres trygt ved høy påvirkning.

Delkonsept: Innholdsproveniens (“Byline 2.0”) for AI-assistert publisering

Plassering i modellen

Dette er et delkonsept under Faktaflyt og Sannhetsbroen. Faktaflyt beskriver hvordan informasjon beveger seg og kvalitetssikres, mens Sannhetsbroen beskriver hvordan vi bygger etterprøvbar tillit mellom kilder, tekst og leser. Innholdsproveniens er limet mellom disse to: et konkret system for å vise hvordan en tekst ble til, hvem som bar ansvar i hvert steg, og hvilke kilder og verktøy som ble brukt – spesielt når AI er involvert.

Formål (hva dette løser)

  • Åpenhet: Leseren ser hvordan artikkelen ble produsert – ikke bare hvem som publiserte.
  • Ansvar: Roller og godkjenninger synliggjøres (bestiller, redaktør, faktasjekk).
  • Etterprøvbarhet: Kilder, versjoner og endringer kan spores og verifiseres.
  • Samsvar: Klargjør merking av AI-assistert innhold og gjør dere klar for gjeldende/fremtidige krav.

Kjerneidé

Vi utvider den tradisjonelle bylinen (“skrevet av…”) til en proveniens-etikett: en kort, menneskevennlig oppsummering + maskinlesbar metadata som dokumenterer hele flyten fra kilder → AI-generering → menneskelig redigering → godkjenning → publisering.

Styrende prinsipper

  • Tydelig, kort, nær teksten: En “Hvordan denne teksten ble til”-boks alltid tilgjengelig ved artikkelen.
  • Maskinlesbart fra dag 1: Metadata legges i HTML (JSON-LD) for søk, deling og gjenbruk.
  • Versjoner, ikke skjul: Endringer skaper nye versjoner med synlig diff og begrunnelse.
  • Mennesket ansvarlig: AI er et verktøy; menneskelig redaktør og faktasjekk bærer sluttansvar.
  • Modulært: Start enkelt (MVP), utvid med signering, innholdskredentialer og verifiserbare attester.

De fire byggeklossene

  1. Synlig merking (UI/UX)
    En kort boks ved artikkelen:
    – Initierende person/rolle (bestiller)
    – AI-bruk (modell/versjon, nøkkelinnstillinger/verktøy)
    – Kildegrunnlag (lenker, innhentet tidspunkt)
    – Menneskelig redigering/faktasjekk (roller, endringer)
    – Status (versjon, sist oppdatert, eventuelle interessekonflikter)
  2. Maskinlesbar metadata (semantikk)
    – JSON-LD i <head> med Article/CreativeWork (forfatter, editor, isBasedOn/citation, dateCreated, dateModified, version).
    – Proveniensmodell (W3C PROV): Entities (kilder/prompt), Activities (generering/redigering), Agents (mennesker/systemer).
  3. Kryptografisk attestering (media)
    – For foto/video/lyd: Content Credentials (C2PA) for å binde media til produksjonslogg.
    – For tekst: “soft binding” (fingeravtrykk/manifest) kan brukes der det er hensiktsmessig.
  4. Verifiserbar identitet og godkjenning
    – Signerbare kvitteringer for “faktasjekk utført” / “redaktør godkjent” (f.eks. Verifiable Credentials).
    – Kobles til roller i redaksjonen for tydelig ansvarslinje.

Minimumsdatamodell (v1)

Front-end på norsk, systemnøkler på engelsk.

  • Artikkel-ID (article_id) – global unik ID/URL.
  • Tittel (headline) – visningsnavn.
  • Versjon (version) – f.eks. 1.0, 1.1.
  • Status (creativeWorkStatus) – Draft/Published/Corrected/Retired.
  • Initierende (initiator) – navn/rolle som bestilte/definerte oppdraget.
  • Ansvarlig redaktør (editor.name, editor.role).
  • Faktasjekk (fact_check.reviewed_by, fact_check.date, fact_check.notes).
  • AI-detaljer (ai.model, ai.model_version, ai.temperature, ai.system_prompt_ref, ai.tools_used[]).
  • Kilder (sources[]) – url, title, publisher, accessedAt, evidenceType (primær/sekundær), claimRefs[].
  • Endringslogg (changelog[]) – when, who, what, diff_ref.
  • Interessekonflikt (conflicts[]) – optional.
  • Signaturer (attestations[]) – f.eks. fact_check_vc, editorial_approval_vc.
  • Media-bevis (content_credentials.manifest_url) – C2PA/manifest.

Redaksjonell arbeidsflyt

  1. Initiativ: Bestiller definerer mål, spørsmål, målgruppe og premisser.
  2. Innhenting: AI/verktøy søker kilder (tidsstemples), bygg kildekurv.
  3. Generering: AI skriver førsteutkast; prompt, modell og parametre logges automatisk.
  4. Menneskelig redigering: Fagredaktør kvalitetssikrer, oppgir endringsnotat og konfidens per hovedpåstand.
  5. Faktasjekk: Egen rolle verifiserer utvalgte påstander og signerer “gjennomført”.
  6. Publisering: Artikkel → vis proveniens-boks + JSON-LD; tilknytt C2PA for media.
  7. Korrigeringer: Nye funn → ny versjon med diff og begrunnelse.

UI-mønstre (redaksjon og leser)

  • Proveniens-pill ved tittel: “AI-assistert · menneskeredigert · kilder oppgitt”.
  • Sidepanel “Arbeidsflyt”: Tidslinje med Kilder → Generering → Redigering → Godkjenning.
  • Påstandsvisning (valgfritt v2): Tabell over hovedpåstander med kilder og sist verifisert-tidspunkt.
  • Media-inspektør: “Se Content Credentials” for bilder/video.

Suksesskriterier og måling

  • Dekning: ≥ 95 % av publiserte artikler har komplett proveniens-boks og JSON-LD.
  • Kildekvalitet: Andel artikler med minst én primærkilde.
  • Tidsbruk: Median tid redaksjon → publisering endres < 10 % etter innføring.
  • Tillitssignaler: Økt dwell-time på proveniens-panelet; færre rettelser pr. 100 artikler.

Risikoer og avbøting

  • Personvern/taushet: Skjul interne detaljer (f.eks. uoffentlige kildereferanser) med tilgangsstyring; eksponer bare nødvendige felt.
  • Kompleksitet: Start med MVP-felt; gjør resten valgfrie.
  • Over-avhengighet av ett verktøy: Logg på standardformater (JSON-LD/PROV); unngå leverandørlåsing.
  • Friksjon i redaksjon: Automatiser logging (tracing) i skriveverktøy; bruk ett “endringsnotat”-felt som minimum.

Innføringsplan (MVP → v2)

  • MVP (4–6 uker):
    1. Proveniens-boks i artikkelmal.
    2. JSON-LD (Article + isBasedOn + editor + version).
    3. Enkel prompt/parameter-logging i AI-flyten.
  • v1.1:
    – Påstandsvisning, konfidens pr. påstand, kilde-tidsstempel, enkel diff-visning.
  • v2:
    – C2PA for media; signerte “faktasjekk/redaktør”-attester; PROV-graf for hele artikkelen.

Eksempeltekst (microcopy) til boksen

Hvordan denne teksten ble til
– Initierende: NN (rolle)
– AI-assistanse: Modell/versjon. Parametre og verktøy er loggført.
– Kilder: 5 kilder (3 primær, 2 sekundær), sist kontrollert DD.MM.ÅÅÅÅ kl. TT:MM.
– Menneskelig kvalitetssikring: Redigert av NN. Faktasjekk utført av NN.
– Versjon: 1.1 (endringslogg tilgjengelig).
– Eventuelle interessekonflikter: Ingen oppgitt.

Implementasjonsnotat (WordPress/Bricks – kort)

  • Felter: Opprett en ACF-gruppe “Proveniens” med feltene over (visningsetiketter norsk, keys engelsk).
  • Visning: Lag en Bricks-komponent for “Hvordan denne teksten ble til”; koble mot ACF-feltene.
  • Metadata: Generer JSON-LD i <head> via tema/snutt (map ACF → Article-nøkler + isBasedOn).
  • Tracing: Logg AI-parametre via eget adminpanel eller en liten MU-plugin (lagre referanse/ID, ikke nødvendigvis hele prompten).
  • Media: Når klart – koble opplastingsløypa til Content Credentials for bilder/video.

Samspill med Faktaflyt og Sannhetsbroen

  • Faktaflyt: Dette delkonseptet materialiserer selve flyten – fra råkilde til publisert tekst – og gjør den synlig og kontrollerbar.
  • Sannhetsbroen: Påstands-/kildetabellen og signerte godkjenninger bygger bro mellom fakta og tillit; leseren kan verifisere uten å stole blindt.
  • Flytende demokrati (videre): Når saker og versjoner utvikles over tid, kan proveniens hjelpe borgere å se hva som endret seg og hvorfor før de stemmer/vektlegger.

Navn og URL

  • Navn (internt): Innholdsproveniens (Byline 2.0).
  • Slug-forslag: innholdsproveniens eller byline-2-0.
  • Plassering: Under Faktaflyt → Delkonsepter og/eller Sannhetsbroen → Metoder.

Forvaltning og eierskap

  • Roller: Produktansvarlig (proveniens), Redaktørkorps, Faktasjekk-ansvarlig, Teknisk forvalter.
  • Policy: Minimumsfelt som alltid må fylles; når og hvordan signering brukes; hvordan konflikter og rettelser håndteres.
  • Åpenhet: Offentlig spesifikasjon av felter og JSON-LD-mapping, slik at andre kan validere og bygge integrasjoner.