Definition, observation, evidens och bedömning

Klockan 09.10 visar Nordic Industrial Services driftpanel grönt. ERP svarar, dokumentgeneratorn svarar, integrationsplattformen svarar och xECM svarar. Ändå saknar fem av 142 dokument ett verifierat slutkvitto.

Är systemet friskt?

Frågan ser enkel ut därför att ordet friskt pressar samman flera olika frågor. Är komponenterna nåbara? Har dokumenten genererats? Har de överförts? Har mottagaren accepterat dem? Är underlaget färskt och fullständigt? Den gröna panelen svarar bara på den första frågan men ser ut som ett svar på alla.

Det här kapitlet introducerar en modell för att undvika sådan falsk trygghet. Den består av fyra kunskapsroller:

1. Definition: vad som ska vara sant.
2. Observation: vad en namngiven källa faktiskt har sett.
3. Evidens: vad som gör ett påstående granskningsbart.
4. Bedömning: vilken slutsats som dragits och enligt vilka regler.

Fyrdelningen är en Matrix-designsyntes, inte en universell naturlag (CLAIM-CORE-006). Dess värde ligger i vilka frågor den gör möjliga att ställa och vilka felslut den hindrar.

1. Fyra meningar som inte betyder samma sak

Betrakta följande utsagor:

Alla dokument i batch NIS-2026-08-10-01 ska finnas i xECM senast tio minuter efter att de lämnat dokumentgeneratorn.

Detta är en definition. Den beskriver ett beslutat eller önskat tillstånd. Den säger ingenting om vad som faktiskt har hänt.

xECM-importens räknare rapporterade 137 mottagna dokument klockan 09.08.

Detta är en observation. Den har en källa, en tid och ett scope. Den säger inte ensam att räknaren är korrekt eller att dokumenten är arkiverade.

Importloggen innehåller 137 poster med dokumentidentitet, mottagningstid och verifierbar loggreferens.

Detta beskriver evidens. Underlaget gör observationen möjlig att granska, men är ännu inte slutsatsen om batchen.

Batchen är ofullständigt verifierad: 137 av 142 dokument har verifierat slutkvitto och fem är okända efter tidsgränsen.

Detta är en bedömning. Den kombinerar definition och observation enligt en regel. En reproducerbar bedömning anger vilka versioner, tider och källor som använts samt vad som saknas.

När rollerna lagras och visas som om de vore samma sak uppstår typiska fel:

• en konfiguration behandlas som bevis för att den är aktiv,
• en heartbeat behandlas som bevis för att ett resultat är korrekt,
• en loggrad behandlas som en färdig verksamhetsslutsats,
• en analys presenteras utan de antaganden som skapade den,
• frånvaro av en observation behandlas som frånvaro av ett problem.

Matrix kan redan representera noder i lagren definition, observation, evidence och analysis (MATRIX-GRAPH-CONTRACT). Principen att skilja definition från observation och kräva evidens är också kanonisk i Matrix (MATRIX-PRINCIPLE-DEFINITION-OBSERVATION, MATRIX-PRINCIPLE-EVIDENCE-FIRST). Kapitlets uppgift är att förklara varför denna separation behövs, vilka gränser den har och hur den används utan att skapa en ny sorts skenprecision.

2. Varför gröna komponenter inte räcker

Ett distribuerat system har inget självklart gemensamt "nu". Observationer görs av olika komponenter, med olika fördröjning, i olika ordning och ibland med förlorade meddelanden. Chandy och Lamports klassiska arbete om distribuerade snapshots visar varför ett meningsfullt globalt tillstånd i ett asynkront system måste konstrueras med hänsyn till både processernas lokala tillstånd och meddelanden som befinner sig mellan dem (chandy1985distributed).

Det betyder inte att varje driftpanel behöver implementera deras algoritm. Det betyder att slutsatsen "alla lokala indikatorer är gröna, alltså är det globala flödet friskt" saknar ett nödvändigt resonemangssteg (CLAIM-DIST-001).

I Nordic-fallet kan samtliga health probes vara sanningsenliga:

• ERP-processen kan svara på sin probe.
• Generatorn kan ha producerat 142 dokument.
• kön kan ta emot och leverera nya meddelanden.
• xECM kan svara på sin API-kontroll.

Samtidigt kan två meddelanden ligga fast i en retry-loop, ett dokument ha avvisats på grund av metadata och två kvitton ha försenats. Komponenthälsa och flödesutfall är relaterade men inte identiska påståenden.

En bättre driftbild behöver därför ange vilken nivå som bedöms:

Varje nivå kräver egna definitioner, observationer och evidens. En högre nivå får inte ärva grönt enbart från den lägre.

3. Okänt är information

Antag att Matrix inte hittar något felmeddelande för de fem dokumenten. Det finns minst tre möjliga lägen:

1. dokumenten har inte kommit fram,
2. dokumenten har kommit fram men kvittot saknas eller är försenat,
3. Matrix observationsförmåga är trasig eller saknar åtkomst.

Underlaget räcker inte för att välja mellan dem. Det korrekta tillståndet är därför okänt, med en förklaring av vad som inte observerats. Okänt är inte en mildare variant av grönt. Det är inte heller automatiskt rött: rött bör reserveras för ett negativt påstående som faktiskt har belägg.

Detta ger en användbar trevägsdistinktion:

• belagt positivt: förväntat tillstånd har observerats med tillräckligt underlag,
• belagt negativt: en observation motsäger definitionen,
• okänt: underlaget räcker inte för att avgöra.

Matrix tes är att okänt aldrig får presenteras som friskt (CLAIM-CORE-003). Det är en normativ designregel, härledd ur systemets uppgift att stödja granskningsbara beslut. Den säger inte att all okändhet är akut. Gränssnittet måste också visa konsekvens, tidsgräns och vad som kan göras för att minska osäkerheten.

4. Två tider och en sen observation

Vid 09.10 bedömer Matrix att fem dokument saknar slutkvitto. Klockan 09.24 anländer två försenade event. De anger att dokumenten togs emot redan 09.07. Hur ska historiken beskrivas?

Om systemet ersätter fem med tre och skriver över den gamla posten blir nutidsbilden bättre men beslutshistoriken falsk. En operatör som agerade 09.12 gjorde det med kunskapen att fem kvitton saknades. En senare revision måste kunna se både verklighetstid och kunskapstid.

Temporal databaslitteratur skiljer därför mellan:

• giltighetstid (valid time): när uppgiften gäller i den modellerade verkligheten,
• kännedomstid (transaction time): när databasen registrerade eller kände till uppgiften (jensen1992glossary).

Nordic-händelsen kan uttryckas så här:

Frågan "hur många var mottagna 09.10 enligt vad vi vet nu?" ger 139. Frågan "hur många kände Matrix till 09.10?" ger 137. Båda svaren är riktiga, men de besvarar olika frågor.

Coordinator har redan en lokal approximation: findings lagrar både observed_at och recorded_at (MATRIX-FINDING-STORE). Matrix-event har occurredAt, medan grafbundles kan bära generatedAt — fältet är inte obligatoriskt i schemat (MATRIX-EVENT-CONTRACT, MATRIX-GRAPH-CONTRACT). Det är en bra grund, men inte ett generellt bitemporalt kontrakt för alla föränderliga påståenden.

Bokens forskningshypotes är därför ett additivt assertionlager för utvalda påståenden, inte en omskrivning av varje grafnod. Hypotesen och dess motbevisande test finns i RESEARCH-001.

Scenario: en historik som inte skrivs om

Följande tidslinje används genom resten av kapitlet:

Notera hur "fem saknas" byter epistemisk status. Först är det en bedömning av saknat underlag. Senare visar två sena event att en del av luckan berodde på observationsfördröjning, två på faktisk leveransfördröjning och en på ett belagt avvisande. En mogen modell bevarar alla dessa steg.

5. Evidens är mer än en länk

Matrix grafkontrakt kräver minst en sourceRef för varje nod och kant. Det är en ovanligt stark och värdefull grundregel. En referens innehåller repository, sökväg och valfri revision eller selektor (MATRIX-GRAPH-CONTRACT).

Men en källpekare besvarar främst frågan var?. Proveniensforskning visar att frågan varifrån kommer värdet? och frågan varför finns resultatet? inte är samma fråga (buneman2001why). W3C PROV gör skillnaden operativ genom tre grundbegrepp:

• Entity: ett dokument, en konfigurationsversion, en observation eller ett annat bestämt ting,
• Activity: en körning, mätning, analys eller transformering som använder och producerar entities,
• Agent: personen, tjänsten eller agenten som är associerad med aktiviteten (w3c-prov-overview).

För Nordic-bedömningen behövs därför inte bara länken till importloggen. En full förklaring bör kunna svara på:

1. Vilken version av batchdefinitionen användes?
2. Vilka observationer och loggsegment lästes?
3. Vilken aktivitet skapade bedömningen?
4. Vilken regelversion räknade ett dokument som verifierat?
5. Vilken människa eller agent var ansvarig för aktiviteten?
6. När gjordes bedömningen och vilket kunskapsläge användes?
7. Har någon källa senare korrigerats eller återkallats?

W3C:s constraints-dokument visar dessutom att proveniens inte bara är en samling länkar. Identitet, händelseordning och omöjliga kombinationer behöver kunna valideras (w3c-prov-constraints). Matrix behöver en egen profil för detta; standarden är en begreppsgrund, inte ett färdigt produktkontrakt.

Forskningsspåret RESEARCH-002 föreslår därför en PROV-kompatibel export av fem representativa Matrix-fall. Det är avsiktligt mindre än att byta intern lagring till RDF eller göra hela produkten beroende av en extern ontologi.

6. Bedömning är en härledning, inte en färg

En bedömning bör kunna läsas som en funktion:

bedömning = regelversion(definition, observationer, evidens, scope, tid)

I Nordic-fallet kan en regel vara:

verified(document, deadline) =
  det finns ett accepterat slutkvitto för dokumentets stabila identitet
  vars händelsetid är senast deadline

Regeln måste också säga vad som händer vid dubbletter, fel tidszon, motstridiga kvitton och sena event. Annars är resultatet inte reproducerbart.

En bedömning ska minst redovisa:

• stabil identitet och regelversion,
• de exakta definitioner och observationer som användes,
• scope: tenant, miljö, batch och relevanta systemgränser,
• beräknings- eller beslutstid,
• resultat och klassificering,
• konflikter och saknat underlag,
• osäkerhetens orsak,
• nästa verifierbara handling.

Detta gör inte varje beslut objektivt. Två rimliga regelverk kan väga evidens olika. Skillnaden är att oenigheten blir synlig och möjlig att pröva.

7. Osäkerhet får inte komprimeras bort

Det är lockande att sammanfatta Matrix kunskapsläge som ett truth score: 88 av 100. Ett sammanfattande mått kan hjälpa användaren att hitta ett problem, men det riskerar att blanda flera dimensioner:

• täckning: hur stor del av scopet observeras?
• färskhet: hur gammal är senaste observationen?
• källkvalitet: är källan direkt, härledd eller självrapporterad?
• konflikt: motsäger två källor varandra?
• modellrisk: hur osäker är analysmetoden?
• konsekvens: hur farligt är det att ha fel?

Forskning om mänsklig tillit till AI-råd visar att responsen på aleatorisk osäkerhet — variation i världen — och epistemisk osäkerhet — begränsning i modellens kunskap — är mer komplex än att "mer osäkerhet ger mindre tillit" (holstein2025balancing). Studien gäller AI-råd, inte alla driftpaneler, men den räcker för att ifrågasätta ett ensamt värde som slutpunkt (CLAIM-UNCERTAINTY-001).

I ett Matrix-gränssnitt bör användaren därför kunna öppna ett sammanfattande värde och se:

Konceptbilden SCREEN-02-01 visar denna riktning. Den är en designartefakt, inte bevis för att beteendet finns i produkten.

SCREEN-02-01 — Driftbild med belagd kundpåverkan och explicit okänt. Konceptuell vy, inte verifierad produktimplementation.

8. Från kunskap till handling

Figur FIG-02-01 sammanfattar kapitlets flöde:

FIG-02-01 — Från verklighet till verifierad förändring

Visa diagramdefinition

flowchart LR
  R[Verklighet] -->|observeras| O[Observation]
  D[Definition] --> X[Avvikelse]
  O --> X
  E[Evidens] --> B[Bedömning]
  X --> B
  B --> G[Mänsklig grind]
  G --> H[Handling]
  H --> V[Verifiering]
  V --> O2[Nytt observerat tillstånd]

Det avgörande är återkopplingen. En handling avslutar inte kunskapskedjan. Efter retry, konfigurationsändring eller manuell korrigering behövs en ny observation som prövar om avsett resultat uppnåddes. Verifieringen får inte vara samma kommando som utförde handlingen och får inte reduceras till att kommandot returnerade utan fel.

I Nordic-fallet kan Matrix föreslå att två dokument körs om. Innan handlingen utförs behöver en grind kontrollera identitet, tenant, risk och mandat. Efter handlingen behöver xECM-observationen visa nya slutkvitton. Först då finns evidens för att flödesutfallet förändrades.

9. Alternativa modeller och kritik

En enda statusmodell

En enklare produkt kan lagra green, yellow och red per objekt. Den är billig och ofta tillräcklig för liveness. Den faller när användaren behöver förklara varför statusen finns, jämföra olika tider eller skilja saknad observation från negativ observation.

Event sourcing som hela svaret

En append-only eventlogg bevarar vad som hänt i lagringsordning. Den hjälper historik och replay, men löser inte automatiskt giltighetstid, semantisk proveniens eller bedömningsregler. Ett event kan anlända sent och en observationstid är inte alltid samma sak som ett giltighetsintervall.

Full semantisk webbmodell

RDF och PROV-O kan ge standardiserad semantik och interoperabilitet. Priset kan vara högre modell- och driftkomplexitet än Matrix behöver. En exportprofil låter projektet pröva värdet innan den interna modellen binds till tekniken.

Full bitemporalitet överallt

Två tidsaxlar på varje objekt ger stor uttryckskraft men ökar lagring, frågekomplexitet och undervisningsbörda. Ett avgränsat assertionlager är en hypotes om bättre balans. Om representativa beslut aldrig ändras av known_at bör hypotesen förkastas eller begränsas ytterligare.

10. Praktisk analysmetod

När ett påstående visas i Matrix, ställ frågorna i denna ordning:

1. Formulera claimen atomärt. Undvik "systemet är friskt"; skriv exakt vad som påstås.
2. Ange rollen. Är detta definition, observation, evidens eller bedömning?
3. Avgränsa scope. Vilken tenant, miljö, batch, komponent och tidsperiod?
4. Ange tiderna. När gällde eller observerades uppgiften, och när blev den känd?
5. Följ proveniensen. Vilken källa, version, aktivitet och agent bär påståendet?
6. Sök konflikter och luckor. Vilka relevanta observationer saknas eller motsäger varandra?
7. Pröva slutsatsen. Vilken regelversion användes, och skulle en annan rimlig regel ge ett annat resultat?
8. Redovisa osäkerheten. Typ, orsak, konsekvens och nästa sätt att minska den.
9. Separera handlingen. Vem har mandat, vilken risk gäller och hur ska resultatet verifieras?

Metoden är medvetet långsammare än att färgsätta ett kort. Den ska användas för beslut där felaktig säkerhet kostar mer än förklaringen. En vardaglig heartbeat behöver inte en uppsats; ett påstående om kundpåverkan eller compliance kan göra det.

Sammanfattning

Ett grönt tekniskt landskap kan innehålla ett trasigt verksamhetsflöde. Problemet uppstår när en begränsad observation presenteras som en bredare slutsats än underlaget tillåter.

Kapitlets fyrdelning separerar vad som ska vara sant, vad som observerats, vad som gör observationen granskningsbar och vilken slutsats som dragits. Giltighetstid och kännedomstid bevarar skillnaden mellan historisk verklighet och historisk kunskap. Proveniens förklarar mer än var en fil ligger. Strukturerad osäkerhet gör luckor handlingsbara utan att låtsas att de är säker kunskap.

Matrix kan inte trovärdigt förklara andra system om det inte lika tydligt kan förklara sitt eget kunskapsläge. Det börjar med en enkel disciplin: säg exakt vad som påstås, visa vilket underlag som bär det och låt okänt förbli okänt.

Läranderesultat

Efter kapitlet ska studenten kunna:

• klassificera en utsaga som definition, observation, evidens eller bedömning,
• förklara varför lokala health states inte automatiskt bildar ett globalt verksamhetstillstånd,
• skilja giltighetstid från kännedomstid,
• identifiera när en källpekare inte räcker som härledningsförklaring,
• beskriva osäkerhet utan att reducera den till ett ensamt värde,
• modellera en korrigering utan att skriva om tidigare kunskapsläge.

Centrala begrepp

Definition, observation, evidens, claim, bedömning, scope, liveness, giltighetstid, kännedomstid, proveniens, härledning, osäkerhet, verifiering.

Referenser

Fullständiga bibliografiska poster finns i sources/academic-sources.bib och kapitlets källroll i SOURCES.md. Matrix-revisioner binds genom sources/matrix-sources.yaml och sources/matrix-lock.json.