Kunskapsgrafen som operativ modell

En karta över Nordics dokumentflöde kan visa sex rutor och fem pilar. Det gör den inte till en kunskapsgraf, och det gör den framför allt inte sann.

För dokument 142 behöver Matrix kunna besvara betydligt strängare frågor:

• Vilket system definierades som producent och vilket som mottagare?
• Vilken körning producerade dokumentet?
• Vilken observation visar att importen avvisades?
• Vilken regel kopplar observationen till ett påverkat processteg?
• Vilka källor, revisioner och tider stödjer varje led?
• Vad saknas, och beror luckan på världen, insamlingen eller modellen?

Grafens värde ligger alltså inte i noderna och linjerna. Det ligger i att relationerna är explicita, källbundna, validerade och möjliga att fråga på ett reproducerbart sätt (CLAIM-GRAPH-001).

1. Grafbild, grafmodell och kunskapstillstånd

En grafmodell består förenklat av objekt, relationer och regler för vad de betyder. En grafbild är en layout av ett urval ur modellen. Ett kunskapstillstånd lägger dessutom till källor, tid, scope, ofullständighet och eventuella konflikter.

Skillnaden är praktisk. Två identiska bilder kan bygga på helt olika underlag: den ena på versionsbundna källor och gröna integritetsgrindar, den andra på en manuellt ritad PowerPoint. Om gränssnittet bara visar slutbilden ser de lika trovärdiga ut.

Litteraturen använder knowledge graph på flera närliggande sätt och fältet rymmer olika grafmodeller, scheman, frågespråk och kvalitetsmetoder (hogan2021knowledgegraphs). I denna bok används en avgränsad operativ definition:

En Matrix-kunskapsgraf är en tidsatt och källbunden projektion av identifierade entiteter, deras typade relationer och de observationer, evidens och bedömningar som får användas för att förklara ett beslut.

Ordet projektion är avgörande. Grafen är Matrix bild av det som dess producenter lyckats observera och godta, inte världen själv (CLAIM-GRAPH-006).

2. Matrix bundlemodell

Matrix grafkontrakt grupperar innehåll i producerbundles. Ett bundle innehåller minst ett schemaversionerat producent-ID samt listor av noder och kanter. Modellen skiljer fyra lager:

Varje nod och kant ska ha minst en sourceRef. Det gör varje relation pekbar, men kapitel 4 visade varför en locator inte ensam beskriver auktoritet, integritet eller full proveniens.

Producenterna är federerade: flera repos och delsystem kan skapa var sitt lokalt bundle. Aggregatet sammanför godkända bundles och lägger även till härledda relationer. Den modellen minskar behovet av en central handskriven karta, men flyttar svårigheten till kontrakt, identitet och integritet.

3. Identitet är federationens hårdaste kontrakt

Anta att två producenter båda emitterar system:xecm, men den ena menar en logisk produkt och den andra en specifik production-instans. Båda objekten kan vara schema-giltiga. Ändå har aggregatet fått ett semantiskt fel.

Den nuvarande grafmotorns inkrementella addBundle behåller alla noder i bundlelistan och kindfrågor, men dess ID-index låter den senast inlästa noden vinna vid lookup. Detta är en uttryckligen dokumenterad kompatibilitetsregel i implementationen (MATRIX-GRAPH-CORE). Konsekvensen är att samma graf kan visa båda objekten i en typfråga men resolvea ID:t till bara det sista.

Det betyder inte att last-write-wins alltid är fel. Det betyder att en merge måste vara avsiktlig och förklarbar. En federerad modell behöver minst:

1. namnrymd eller annan global ID-regel,
2. deklaration av vem som äger identiteten,
3. skillnad mellan samma objekt och liknande objekt,
4. kollisionsgrind eller explicit mergepolicy,
5. audit av vilket bundle som vann och varför.

RESEARCH-012 testar den konkreta kollisionsrisken innan en produktändring föreslås (CLAIM-GRAPH-003).

4. Schema är grammatik, integritet är betydelse

JSON Schema kan kontrollera att en kant har from, to, kind och sourceRefs. Det kan inte ensamt garantera att ändnoderna finns i det sammanslagna aggregatet, att en ingress har en faktisk provider eller att varje registrerad producent redovisats.

Matrix kompletterar därför schemat med semantiska grindar (MATRIX-GRAPH-INTEGRITY):

• en dangling edge vägras alltid,
• en nod utan kanter vägras om den inte är uttryckligen undantagen med orsak,
• en ingress behöver en inkommande EXPOSES-relation eller ett motiverat providerUnresolved,
• gamla undantag som inte längre behövs synliggörs för borttagning,
• aggregatbygget redovisar registrerade producenter som godkända eller vägrade; tyst bortfall stoppar bygget.

Detta är exempel på skillnaden mellan objektsyntax och grafens tvärsnittsinvariants (CLAIM-GRAPH-002). W3C:s SHACL visar samma allmänna idé i RDF-världen: shapes beskriver villkor över en datagraf och valideringen producerar en rapport (w3c-shacl). Matrix ska inte byta modell bara för att standarden finns. Jämförelsen är värdefull eftersom den frågar om de egna grindarna har tydliga mål, severity och maskinläsbara resultat.

5. Härledning skapar ny kunskap—och nytt ansvar

En kant kan vara direkt deklarerad eller härledd. Matrix härleder exempelvis PROVES mellan en observerad endpoint och en definierad ingress när miljö och hostname matchar entydigt (MATRIX-PROVES-DERIVATION). Ingen kant skapas vid fel miljö, saknad kandidat eller tvetydighet.

En härledd kant måste därför kunna besvara:

• vilken regel och regelversion användes,
• vilka inputnoder och källrevisioner deltog,
• när härledningen kördes,
• om resultatet är materialiserat eller räknas vid frågetillfället,
• vilka findings uppstod när en relation inte kunde härledas.

Det sista är lätt att missa. "Ingen PROVES-kant" kan betyda att inget bevis finns, att observationen är för gammal, att identiteten är tvetydig eller att producenten inte kördes. Alla fyra ger samma tomma bild men kräver olika handling.

6. Frånvaro är inte negation

När en nod eller kant saknas i Matrix vet systemet i första hand att den inte finns i den aktuella projektionen. Det vet inte automatiskt att motsvarande objekt eller relation saknas i verkligheten.

För Nordic betyder frånvaron av ett slutkvitto inte "dokumentet levererades inte". Den betyder att slutstatus inte kan styrkas inom aktuellt scope. Ett senare kvitto kan ändra kunskapsläget utan att historien skrivs om.

Matrix integritetsregel för avsiktligt olänkade noder är en bra förebild: luckan tillåts bara när den är synlig och har en användbar orsak. En sådan booking är inte ett frikort. När noden senare kopplas ska undantaget bli stale och tas bort. Detta gör ofullständighet till förvaltat tillstånd (CLAIM-GRAPH-004).

Ett gränssnitt bör därför skilja minst:

• known present: representerat och styrkt inom angivet scope,
• known absent: en auktoritativ observation stödjer frånvaro,
• unobserved: relevant källa har inte observerats,
• unresolved: observation finns men identitet eller relation kan inte avgöras,
• refused: data fanns men underkändes av en grind,
• out of scope: frågan ingår inte i den aktuella projektionen.

7. Frågan är en del av svaret

Grafdatabasforskning skiljer modeller och operationer för navigation, mönstermatchning och strukturella frågor (angles2008graphmodels). I Matrix är följande parametrar en del av ett impactsvars betydelse:

• startnod eller startmängd,
• outgoing, incoming eller båda riktningar,
• tillåtna kanttyper,
• maximalt djup,
• stopp vid vissa nodtyper,
• hur cykler och redan sedda noder hanteras,
• om evidens hämtas och i vilken kantriktning,
• vilken grafrevision frågan kördes mot.

Grafmotorns traverse använder breadth-first search och en global mängd av redan sedda nod-ID:n. En nod returneras därför via den första väg som når den; alla alternativa vägar räknas inte upp. Den separata impactBfs behåller av kompatibilitetsskäl dessutom kantordning och kan i läget both innehålla dubbletter. Detta är inte nödvändigtvis en bugg. Det är däremot fel att kalla resultatet "alla förklaringsvägar" (CLAIM-GRAPH-005).

Ett reproducerbart impactsvar bör bära ett query envelope:

graphRevision
queryContractVersion
startIds[]
direction
edgeKinds[]
maxDepth
stopAtKinds[]
includeEvidence
executedAt
resultDigest
limitations[]

Därmed kan audit visa både resultatet och frågan som skapade det.

8. Federerad byggkedja

Figur FIG-05-01 visar den operativa kedjan:

FIG-05-01 — Federerad väg från källor till beslutbar grafprojektion

Visa diagramdefinition

flowchart LR
    S[Versionsbundna källor] --> P1[Producer A]
    S --> P2[Producer B]
    P1 --> V{Schema + lokal integritet}
    P2 --> V
    V -- vägra --> R[Synlig refusal med orsak]
    V -- godkänd --> A[Aggregat]
    A --> C{Täckning, identitet,<br/>derivability, staleness}
    C -- vägra --> R2[Synlig refusal<br/>coverage eller identitet]
    C -- godkänd --> D[Härledda kanter]
    D --> Q[Versionsbunden frågesemantik]
    Q --> U[Påverkan, förklaring,<br/>gränssnitt och beslut]
    U --> E[Evidens och audit]
    E -. ny observation .-> NEXT[Nästa cykel:<br/>versionsbundna källor]

En refusal är en produktutgång, inte skräp i en logg. Om en producent är registrerad men saknar bundle måste en operatör kunna se producent, förväntad källa, senaste lyckade körning, vägransorsak och vilka frågor som därmed blir ofullständiga. Detta förbinder kunskapsgrafen med coordinatordelen: Matrix måste kunna förklara varför dess egen projektion saknar kunskap.

9. Nordic som operativ graf

En minimal modell kan innehålla:

process:document-delivery -[HAS_STEP]-> step:import-xecm
generator:nordic         -[PRODUCES]-> document:142
run:generator-0905       -[GENERATED]-> document:142
run:import-0933          -[USED]-> document:142
run:import-0933          -[GENERATED]-> observation:rejected-142
observation:rejected-142 -[ABOUT]-> step:import-xecm
evidence:xecm-record     -[SUPPORTS]-> observation:rejected-142

Kantnamnen är här pedagogiska, inte ett förslag att direkt utöka Matrix vokabulär. Modellen visar tre skilda saker: den avsedda processen, de faktiska körningarna och evidensen för bedömningen.

Frågan "vad påverkas av xECM-avvisningen?" bör inte börja vid komponentens healthnod. Den börjar vid observationen eller dokumentet och följer en deklarerad uppsättning semantiska relationer. Annars blandas komponentliveness med objektsutfall igen.

10. Behövs grafdatabas, RDF eller GQL?

Tre teknikspår bör hållas isär:

Ett teknikbyte ska utlösas av verifierade frågor, volym eller interoperabilitetsbehov—inte av att ordet graf förekommer. RESEARCH-013 översätter fem verkliga Matrix-frågor till alternativen och jämför resultatet.

11. Konsekvenser för gränssnittet

Ett operativt gränssnitt bör börja med frågor och kunskapstillstånd, inte med en oändlig force-directed graf. En rimlig progression är:

1. Konsekvens: vad vet Matrix, vad påverkas och vilket beslut stöds?
2. Scope: tenant, miljö, tid, grafrevision och querykontrakt.
3. Förklaring: vald väg med kantbetydelser och källor.
4. Alternativ: andra kända vägar, konflikter och stoppade traversalgrenar.
5. Täckning: saknade, vägrade, stale eller oresolveade producenter.
6. Rå graf: expertvy för fri exploration och diagnostik.

Samma modell ska kunna förklara Matrix självt. Producenter, aggregate builds, derivationer, agentruns, refusals och queryresultat bör vara inspekterbara som egna operativa objekt. Annars blir kontrollplanet ett undantag från sin egen evidence-first-princip.

SCREEN-05-01 visar hur frågan, den valda grafprojektionen, relevanta träffar och en konsekvenskedja kan samlas utan att rågrafen blir startsida. Hela vyn visas för att behålla orienteringen; inga utsnitt presenteras utan locator.

SCREEN-05-01 — Landskapsfråga med graf, träffar och konsekvenskedja. Hel konceptvy; graf och träffar är demodata, inte observerat kundläge.

Praktisk granskningslista

1. Namnge beslutet som grafen ska stödja.
2. Avgränsa tenant, miljö, tid och systemgräns.
3. Lista producenter och auktoritativa källor.
4. Definiera global identitet och kollisionspolicy.
5. Separera deklarerade, observerade och härledda relationer.
6. Kräv source refs och regelversion för varje beslutsrelevant led.
7. Validera både bundleform och tvärgående invariants.
8. Representera saknat, okänt, unresolved och refused separat.
9. Versionsbind queryparametrar och grafrevision.
10. Testa alternativa vägar, cykler, djupgränser och kantfilter.
11. Visa täckning och vägran bredvid slutsatsen.
12. Låt samma krav gälla Matrix egen kontrollplansgraf.

Sammanfattning

En kunskapsgraf är inte trovärdig för att den kan ritas. Den blir operativ när identitet, relationer, källor, scope, ofullständighet och frågor utgör ett testbart kontrakt.

Matrix har redan starka byggstenar: federerade bundles, obligatoriska sourceRefs, fail-closed integritetsgrindar, producertäckning och konkret PROVES-härledning. Implementationsgranskningen visar samtidigt två gränser som måste vara synliga: ID-kollisioner resolveas enligt last bundle wins och traversal räknar inte upp alla möjliga vägar.

Det rimliga nästa steget är därför inte automatiskt en ny grafdatabas. Det är att göra identitets- och querykontrakten explicita, mutationstesta dem och låta gränssnittet visa grafrevision, täckning och begränsningar tillsammans med svaret.

Läranderesultat

Efter kapitlet ska studenten kunna:

• skilja grafbild, grafmodell och kunskapstillstånd,
• förklara federationens identitetsproblem,
• skilja schemafel från relationella integritetsfel,
• modellera frånvaro utan att göra den till negation,
• reproducera ett impactsvar från dess query envelope,
• argumentera för eller emot en alternativ grafteknik med mätbara behov.