Claims, källor, konflikter och osäkerhet

För dokument 142 visar Nordic-systemen följande:

• dokumentgeneratorn producerade dokumentet 09.05,
• xECM:s API var healthy 09.09,
• xECM avvisade dokumentet 09.33 på grund av metadata.

Tre utsagor, tre källor och två olika färger i ett vanligt gränssnitt. Är källorna i konflikt?

Nej. De talar om olika predikat. Dokumentet kan vara producerat, xECM kan vara levande och den specifika importen kan samtidigt vara avvisad. Konflikten uppstår först när två normaliserade claims tillskriver samma subjekt och predikat oförenliga värden i överlappande scope och tid.

1. Claimen är den minsta granskningsbara utsagan

Ordet claim används här för ett atomärt påstående som kan stödjas, motsägas, revideras eller förbli okänt. En användbar claimprofil behöver minst:

Stabil identitet betyder inte att claimens värde aldrig ändras. Det betyder att versioner, korrigeringar och relationer kan följas utan att gamla beslut tappar sitt sammanhang (CLAIM-CLAIM-001).

Matrix graf har noder, kanter, lager och obligatoriska sourceRefs, men ingen generell förstaklassnod av typen claim (MATRIX-GRAPH-CONTRACT). Claims finns som idé i flera lokala kontrakt. Det talar för en pilotprofil, inte för att varje grafnod automatiskt ska bli en claim.

2. Källa, evidens och auktoritet är olika

En sourceRef svarar på var underlag kan hittas. Den säger inte ensam:

• om källan är auktoritativ för predikatet,
• om versionen är immutabel,
• om källan observerat direkt eller kopierat någon annan,
• om underlaget är färskt och komplett,
• om det gäller rätt tenant och miljö,
• om härledningsregeln är giltig.

Matrix monitoringkontrakt använder redan evidensgrader för definitioner och signaler (MATRIX-MONITORING-CONTRACT). Det är användbart, men en generell modell behöver hålla flera dimensioner separata (CLAIM-EVIDENCE-001):

Två källor är inte två oberoende belägg om båda citerar samma ursprung (CLAIM-SOURCE-001). En graf som räknar inkommande SUPPORTS-kanter riskerar därför att skapa falsk säkerhet.

3. Proveniens förklarar beroendet

Buneman, Khanna och Tan skiljer frågor om var data kommer från och varför ett resultat finns (buneman2001why). W3C PROV modellerar entities, activities och agents samt användning, generering och derivation (w3c-prov-overview).

För claimen om dokument 142 kan kedjan vara:

rejection-record (Entity)
        ↓ used
import-observation (Activity) ← associatedWith xECM-adapter (Agent)
        ↓ generated
observation: accepted=false (Entity)
        ↓ used tillsammans med batchregeln
assessment: batch has one rejected document (Entity)

Om två bedömningar använder samma rejection-record är de två härledningar, men inte två oberoende observationer. Proveniens gör beroendet synligt.

4. När föreligger en konflikt?

Jämför först följande nyckel:

(subject, predicate, tenant, environment, valid interval)

Två olika värden är en direkt konflikt först när nyckeln matchar eller intervallen överlappar (CLAIM-CONFLICT-002). Vanliga skenkonflikter är:

• scopekonflikt: test säger version 2, production version 1,
• tidskonflikt: ägare A gällde i juni, ägare B från juli,
• identitetskonflikt: två ID:n antas felaktigt beskriva samma dokument,
• definitionskonflikt: "levererad" betyder kökvitterad i en källa och verksamhetsaccepterad i en annan,
• granularitetskonflikt: komponenten är healthy men ett objekt avvisat,
• kunskapstidskonflikt: äldre bedömning jämförs med senare korrigerad bild.

Matrix PROVES-härledningen ger ett konkret gott exempel. En observerad endpoint får bara bevisa en deklarerad ingress när (environment, hostname) matchar entydigt. Fel miljö, flera kandidater eller saknad deklaration skapar finding och ingen proof edge (MATRIX-PROVES-DERIVATION). Scope och entydighet är alltså en skrivgrind för bevisrelationen.

5. Bevara konflikten före resolution

Traditionella register använder ofta "senaste värdet vinner" eller en fast källprioritet. Det kan fungera när domänen verkligen har en auktoritativ master. Det blir farligt när källorna observerar olika delar av verkligheten.

AGM-traditionen formaliserar hur en kunskapsmängd kan kontraheras och revideras när ny information tillkommer (agm1985theorychange). Dungs argumentationsramverk visar hur argument och attacker kan analyseras utan att ett motsatt argument raderas (dung1995arguments). Matrix behöver inte implementera dessa teorier fullt ut. Designlärdomen är enklare:

råa claims och deras stöd bevaras; ett beslut använder en namngiven resolutionspolicy och producerar en ny bedömning.

Möjliga policyer är:

• domänauktoritet: xECM avgör acceptedByXecm,
• färskaste giltiga direktobservation,
• högsta evidensklass inom samma scope,
• mänskligt avgörande vid säkerhets- eller compliancekonflikt,
• ingen resolution: returnera conflicted och stoppa handling.

Det sista alternativet är viktigt. Ett kontrollager måste kunna vägra välja.

6. Revision, retraction och motbevis

Fyra tillstånd får inte blandas:

• superseded: en nyare version används för current-frågor,
• retracted: claimen får inte längre användas som stöd,
• contradicted: en annan claim påstår ett oförenligt värde,
• resolved: en policy eller människa har avgjort hur konflikten ska behandlas för ett bestämt beslut.

En retraction är inte ett bevis för motsatsen. Om ett slutkvitto visar sig vara korrumperat vet Matrix inte automatiskt att dokumentet avvisades. Det tidigare positiva stödet har försvunnit; resultatet kan återgå till okänt.

7. Osäkerhet som profil

Ett truth score blandar lätt ihop olika frågor. För varje bedömning bör Matrix i stället kunna redovisa:

• täckningsosäkerhet: saknas objekt eller systemgränser?
• färskhetsosäkerhet: är observationerna för gamla?
• källosäkerhet: är auktoritet eller integritet oklar?
• identitetsosäkerhet: vet vi att två referenser gäller samma objekt?
• modell-/regelrisk: kan en annan rimlig regel ge annat svar?
• konflikt: finns aktiva oförenliga claims?
• konsekvens: vad händer om bedömningen är fel?

Forskningen om aleatorisk och epistemisk osäkerhet i AI-råd visar att människors reliance påverkas på mer komplexa sätt än av en enda konfidensnivå (holstein2025balancing). Matrix-hypotesen är därför att dimensioner och orsak ska visas före eventuell sammanvägning (CLAIM-UNCERTAINTY-002). Den måste användartestas.

8. En minimal resolutionspost

När Matrix eller en människa avgör en konflikt bör resultatet vara en ny artefakt, exempelvis:

resolutionId
conflictSet[]
decisionScope
policyId + version
selectedClaims[]
rejectedForThisDecision[]
decidedBy / decidedAs
decidedAt
rationale
expiresOrReviewAt

rejectedForThisDecision betyder inte raderad eller globalt falsk. En claim kan vara irrelevant i ett scope och användbar i ett annat.

9. Gränssnitt för konflikt

Under en incident behöver användaren inte först se en ontologi. En progressiv vy kan ha tre nivåer:

1. Konsekvens: "Dokument 142 är avvisat; batchen är inte fullständigt verifierad."
2. Varför: xECM rejection-record, rätt miljö, färsk 09.33, direkt källa.
3. Full kedja: entities, activities, agents, versioner, competing claims och resolutionsregel.

Om konflikt finns ska första nivån säga conflicted eller kan inte avgöras, inte välja färg genom medelvärde.

10. Matrix nuläge och nästa steg

Matrix har starka byggstenar:

• obligatoriska sourceRefs,
• särskilda evidence-noder och relationer som PROVES, VERIFIES, SUPPORTS och ATTESTS,
• lager för definition, observation, evidence och analysis,
• konkret scopegrind i endpoint→ingress-härledningen,
• evidensgrader i monitoringdefinitioner.

Det som saknas som generell kärnförmåga är ett claimobjekt med normaliserad identitet, conflict set, källberoende, revision/retraction och deklarerad resolution. Nästa rimliga steg är en undervisnings- och exportprofil över Nordic-fallet, inte att direkt utöka grafens enum.

Forskningsspår RESEARCH-011 jämför också W3C PROV med OpenLineage. Det senare har en konkret modell för Job, Run, Dataset och run events och kan passa producer- och pipelineinstrumentering. Det bör bara införas om verkliga integrationer motiverar ytterligare en profil.

Implementationsnot 2026-08-12: elicitering utan sammanblandade mandat

Matrix har nu ett konkret claimnära flöde som skärper kapitlets modell. Interviewer ställer exakt en fråga per tur och bokför svarskontext, medan Challenger får föreslå och mekaniskt pröva flaggor men aldrig ändra ett claim. En separat rollagent får endast claims och probes; transcriptmaterial vägras vid gränsen. Playback bekräftar eller korrigerar en tolkning utan att skriva om informantens ursprungliga yttrande [CLAIM-CLAIM-012].

yttrande → atomärt claim → challenge-flagga → playbackbeslut

Mättnad mäts i den separata elicitation_saturation-modulen; Challenger äger flaggor men inte mättnadens beräkning eller claimens innehåll. Mättnad och evidensstyrka är härledda mått, inte sanningspoäng. En session där informanten endast väljer bland presenterade alternativ kan därför ge en varning i stället för falskt hög säkerhet. Motorn är landad, men den fulla användarvägen är fortfarande en produktlucka (MATRIX-ELICITATION-SATURATION).

Praktisk konfliktalgoritm

1. Atomisera utsagorna.
2. Normalisera identitet, predikat, scope och tidsintervall.
3. Separera skenkonflikter från direkta konflikter.
4. Följ proveniens till gemensamma ursprung.
5. Bedöm auktoritet, direkthet, aktualitet, integritet och täckning separat.
6. Bevara alla råa claims.
7. Välj en versionsbunden resolutionspolicy för beslutet.
8. Returnera resolved, conflicted eller unknown med motivering.
9. Spara resolutionen som en ny, tidsatt artefakt.
10. Ompröva när en källa korrigeras eller retractas.

Sammanfattning

Flera källor skapar inte automatiskt mer sanning. Innan claims jämförs måste de tala om samma subjekt, predikat, scope och tid. Därefter behöver Matrix förstå om källorna är oberoende, vilket underlag de använder och vilken auktoritet de har för just predikatet.

Konflikt är ett legitimt kunskapstillstånd. Råa claims bevaras; resolution är en separat, spårbar bedömning. Osäkerhet förklaras genom orsak, täckning, färskhet, identitet och konsekvens innan den eventuellt sammanfattas. Ett system som ibland säger "jag kan inte avgöra" är mer trovärdigt än ett system som alltid hittar en vinnande färg.

Läranderesultat

Efter kapitlet ska studenten kunna:

• formulera ett atomärt, tids- och scopebundet claim,
• skilja källa, evidens, auktoritet och oberoende,
• identifiera direkt konflikt respektive skenkonflikt,
• bevara konkurrerande claims och skapa en separat resolution,
• förklara varför retraction inte automatiskt bevisar motsatsen,
• presentera osäkerhet och konflikt progressivt i ett gränssnitt.

Centrala begrepp

Claim, subject, predicate, scope, provenance, auktoritet, oberoende, evidensstyrka, direct conflict, skenkonflikt, supersession, retraction, resolution, argumentation och multidimensionell osäkerhet.

Referenser

Bibliografiska poster finns i sources/academic-sources.bib, källornas roll i SOURCES.md och Matrix-bindningarna i sources/matrix-sources.yaml.

FIG-04-01 — Från källor till spårbar konfliktresolution

Visa diagramdefinition

flowchart LR
  S1[Källa A] --> C1[Claim A]
  S2[Källa B] --> C2[Claim B]
  O[Gemensamt ursprung] --> S1
  O --> S2
  C1 --> N[Normalisera subjekt, predikat, scope och tid]
  C2 --> N
  N --> X{Direkt konflikt?}
  X -->|nej| K[Samtidigt förenliga claims]
  X -->|ja| P[Versionsbunden resolutionspolicy]
  P --> R[Resolved, conflicted eller unknown]
  R --> A[Ny spårbar bedömning]