Konsekvensanalys

Nordic står inför en till synes enkel fråga: kan xECM uppgraderas från 26.1.2 till 26.2.0?

Ett traditionellt gränssnitt kan svara med en graf där xECM har tolv grannar. Ett annat kan visa att tre tenants binder den äldre versionen. Ett tredje kan markera två kontrakt som skew. Alla tre kan vara korrekta och ändå besvara olika frågor.

Matrix måste därför kunna säga mer än vad grafen når. Det måste kunna förklara:

• vilken förändring som analyserades,
• vilken modell och revision som användes,
• vilka objekt som kan exponeras för förändringen,
• vilka som sannolikt eller bekräftat påverkas,
• vilken evidens och täckning som stöder bedömningen,
• vilka luckor som förhindrar ett säkert svar,
• vilken handling som rekommenderas och vem som äger beslutet.

Konsekvensanalys är inte en färgad graf. Det är en granskningsbar argumentkedja.

1. En väg är inte en konsekvens

I en riktad graf betyder en väg att en sekvens av valda kanter förbinder två noder. Resultatet beror på kantens riktning, vilka kanttyper som tillåts, startnoder, maxdjup och hur vägar dedupliceras. Matrix graph-core använder BFS och en global mängd redan sedda noder. Det ger i praktiken den första hittade vägen per nod, inte alla möjliga argument för påverkan (MATRIX-GRAPH-CORE).

Det är användbart för kandidatsökning men otillräckligt för kausalitet. En DEPENDS_ON-kant kan betyda byggberoende, runtimeanrop, organisatoriskt ansvar eller en historiskt deklarerad koppling. Att B är nåbar från A bevisar inte att en förändring i A orsakar ett visst utfall i B. Kausal analys kräver ytterligare antaganden om mekanism och alternativt förlopp (pearl2009causality, CLAIM-IMPACT-001).

Det första språkliga skyddet är därför en progression:

1. Reachable — nåbar: noden hittades med deklarerad frågesemantik.
2. Exposed — exponerad: relationens betydelse gör att noden kan möta förändringen.
3. Plausibly affected — troligen påverkad: scenario, version och mekanism ger ett trovärdigt påverkanargument.
4. Confirmed affected — bekräftat påverkad: aktuell observation eller verifiering visar utfallet i relevant scope.
5. Required action — krävd handling: policy, riskaptit och ägare gör en åtgärd nödvändig.

Varje förflyttning kräver mer än den föregående. En UI-badge får aldrig hoppa från reachable direkt till must fix utan att visa argumentet.

2. Tre olika impactbegrepp i Matrix

Den nuvarande implementationen innehåller minst tre meningsfulla former av impact.

2.1 Topologisk impact

graph-core kan traversera downstream, upstream eller båda riktningar och returnera noder, kanter och vägar. Den rikare impactAnalysis kan också försöka samla evidens. Matrix Command har en separat klientalgoritm där dependents följer kanter baklänges och dependencies framåt (MATRIX-IMPACT-UI).

Denna analys svarar på: vilka grafobjekt ligger inom den valda beroendehorisonten?

2.2 Fleet- och versionsimpact

Fleet-analysen jämför tenantmanifest mot ett uppgraderingsscenario. En tenant som binder paketet blir impacted; numerisk versionsjämförelse anger behind, current, ahead eller unknown. Tenants utan paketbindning listas som opåverkade för just paketfrågan (MATRIX-FLEET-IMPACT).

Denna analys svarar på: vilka tillåtna tenants är exponerade för den angivna paketversionen? behind visar inte att verksamheten går sönder, bara att bindningen ligger bakom målversionen.

2.3 Kontraktsimpact

Kontraktsanalysen går igenom CONSUMES-relationer och skiljer deklarerad från observerad konsumtion. Resultatet är match, skew eller unknown; en okänd runtimeversion blir inte grön (MATRIX-CONTRACT-SKEW).

Denna analys svarar på: stämmer den deklarerade och observerade kontraktsversionen för den konsumtion som faktiskt modellerats?

De tre resultaten bör visas bredvid varandra, inte pressas in i samma odefinierade impactScore. Topologi kan finna en exponerad konsument, fleet kan finna en tenant med äldre paket och kontraktsanalysen kan visa faktisk skew. Tillsammans blir argumentet starkare, men de är fortfarande separata claims.

3. Börja med förändringsscenariot

ATAM använder scenarier för att göra arkitekturkvaliteter och tradeoffs konkreta (kazman1998atam). Samma princip behövs här. Frågan "vad påverkas av xECM?" är för obestämd. Ett scenario ska åtminstone ange:

scenarioId
stimulus/changeType
subject: package, API, schema, policy, node eller process
beforeState + afterState
effectiveWindow
tenant/environment scope
assumptions
decisionQuestion
decisionThreshold

För Nordic kan scenariot vara:

subject: package xecm
before: 26.1.2
after: 26.2.0
scope: Nordic production och endast auktoriserade tenants
assumption: breaking-change-listan är komplett för använda operationer
question: vilka verifieringar krävs före rollout?
threshold: ingen blockerande contract skew och bekräftat kvittoflöde i canary

Matrix har redan konfigurerade fleet-scenarier med fromVersion och toVersion (MATRIX-FLEET-SCENARIOS). Det är en bra kärna, men en fullständig bedömning behöver också frågan, scope, tid, antaganden och beslutströskel (CLAIM-IMPACT-002).

4. Bind också själva frågan

Samma scenario ger olika resultat om frågan körs med upstream i stället för downstream eller med djup två i stället för fem. Därför behöver resultatet ett frågekontrakt:

graphRevision + producer revisions
queriedAt
startNodeIds
direction
allowedEdgeKinds
maxDepth
pathPolicy: first | all | bounded-k
includeEvidence
tenant/zone authorization context
coverage policy version
engine + query semantics version

Om maxdjup nås ska resultatet bära en boundary: "ytterligare beroenden kan finnas". Om en kant filtreras bort ska det gå att se vilken regel som gjorde det. Om den globala visited-mängden bara bevarar första vägen får UI:t inte formulera den som den enda orsaken (CLAIM-GRAPH-005).

RESEARCH-020 prövar därför ett additivt ImpactAssessment-envelope. Det ska inte ersätta motorerna. Det ska göra deras svar jämförbara och reproducerbara.

5. Från nåbar till exponerad

En nåbar nod klassificeras som exponerad först när kanttypen har definierad scenariosemantik. En enkel regelmatris kan se ut så här:

Reglerna bör versionsbindas per kanttyp och scenariofamilj. En generisk "följ alla kanter" blandar teknisk propagation med ansvar, evidens och dokumentation.

6. Evidens måste följa sin egen semantik

I Matrix går en härledd PROVES-kant från observationen till definitionen: endpointen bevisar ingressdefinitionen (MATRIX-PROVES-DERIVATION). I processgrafen går även ATTESTS och VERIFIES från evidensbärande objekt mot kontroll eller processobjekt.

Den rika impactmotorns kompletterande evidenssökning börjar däremot vid den påverkade noden, söker utgående PROVES, VERIFIES, SUPPORTS och ATTESTS och lägger bara målnoder av kind evidence i resultatet. Ett hermetiskt test med evidence e --PROVES--> control c och startnod c gav:

{"evidence":[],"incoming":["e"]}

Grafen känner alltså den inkommande källan men evidensberikningen missar den. RESEARCH-019 är en rekommenderad backlogkandidat med acceptanskriterier för riktning och deduplicering. Felet betyder inte att all impactanalys är ogiltig; det betyder att en tom evidence-lista i denna kodväg inte får tolkas som "ingen evidens finns".

7. Okänt är ett eget resultat

Fem tillstånd måste hållas isär:

• unaffected: scenarioregel och tillräcklig täckning stödjer att objektet inte exponeras eller påverkas,
• affected: evidens och regel stödjer påverkan,
• not assessed: objektet låg utanför avsiktligt scope,
• unknown: nödvändig version, relation eller observation saknas,
• refused: analysen fick inte använda data på grund av tenant-, zon- eller policygräns.

Även truncated bör finnas som synlig egenskap när traversal eller population avklippts. Okänd version, djupgräns och otillåten tenant får inte hamna i unaffected (CLAIM-IMPACT-003).

Fleetkoden gör en viktig distinktion: okänd version får unknown, medan en tenant som inte binder paketet kan bli opåverkad för just paketfrågan. Men den senare slutsatsen gäller bara om manifestpopulationen och tenantfiltreringen är tillräckligt täckta.

8. Coverage för impact

En impactbedömning behöver både grafcoverage och observationscoverage.

Grafcoverage frågar om alla relevanta producenter, tenants, relationstyper och revisionsintervall ingick. Observationscoverage frågar om de berörda runtimevägarna faktiskt observerades under relevant tid.

En minimal rapport kan innehålla:

expected producers/tenants/subjects
covered
missing
skipped with reason
refused
stale
unexpected
traversal boundaries

Matrix coverage-kontrakt ger redan dessa grundkategorier, men anroparen måste definiera nämnaren (MATRIX-COVERAGE-CONTRACT). Utan nämnare kan "0 fel" betyda att inget är fel eller att ingen tittade.

9. Deklarerad och observerad topologi

En deklarerad CONSUMES-kant kan vara gammal. En observerad span kan vara samplad eller sakna sin andra halva. De ska därför inte skriva över varandra.

OpenTelemetry Collector service graph connector kan härleda servicekanter ur parade client/server- eller producer/consumer-spans. Dokumentationen redovisar också unpaired och dropped spans och komponenten är i alpha (otel-servicegraph-connector). OpenLineage kan på motsvarande sätt uttrycka observerade jobb, runs och datasetflöden (openlineage-spec).

Detta ger en användbar jämförelse:

RESEARCH-021 föreslår en syntetisk pilot. Observerade kanter bör bli tidsbundna claims med källor och coverage, inte automatiskt auktoritativ arkitektur (CLAIM-IMPACT-005).

10. Tenant, fleet och informationsläckage

En fleetfråga är samtidigt en behörighetsfråga. Om en användare bara får se Nordic får varken impacted, unaffectedTenantIds, totalsiffror eller traversalvägar avslöja andra tenants. Filtrering efter att en global summary räknats kan läcka själva existensen av skyddade objekt.

Den serverexponerade fleetfunktionen filtrerar impactresultat mot tillåtna tenant-ID:n. Det är rätt principiell placering av gränsen (MATRIX-FLEET-IMPACT, CLAIM-IMPACT-007). Ett generellt ImpactAssessment måste bära vilket authorization scope som faktiskt användes, utan att serialisera hemligheter.

För Nordic ska gränssnittet alltså inte säga "4 av 7 tenants påverkas" om operatören endast får se fyra. Det ska säga "4 av 4 auktoriserade tenants är exponerade; övrig population är inte synlig i detta beslutsscope".

11. Konsekvens i flera dimensioner

NIST SP 800-30 behandlar riskbedömning som stöd för val av handlingsalternativ, med explicit osäkerhet och antaganden (nist80030r1). Matrix behöver ett bredare verksamhetsperspektiv än enbart informationssäkerhet, men samma disciplin: bryt ned innan du sammanväger.

En siffra som risk = sannolikhet × påverkan kan vara användbar för grov rangordning när skalorna är definierade. Den får inte skapa låtsad precision. Visa ursprungliga dimensioner, intervall, antaganden och vad som skulle ändra bedömningen (CLAIM-IMPACT-004).

12. Simulation är ett villkorat påstående

Fleet-scenariot säger i praktiken: om paketet går till målversionen och dessa manifest är aktuella, vilka tenantbindningar ligger då bakom? Det är en kontrafaktisk fråga under modellantaganden. Det är inte en prognos om att en incident säkert inträffar (CLAIM-IMPACT-006).

Ett simuleringsresultat bör därför uttryckas:

Under scenario S, modellrevision G och antaganden A
är objekt X exponerat via väg P.
Påverkan Y är trolig/bekräftad med evidens E.
Coverage är C; luckor är L.
Rekommenderad handling är H enligt policy R.

Efter canary eller rollout matas observerat utfall tillbaka som nya claims. Först då kan Matrix jämföra förväntad och faktisk påverkan och förbättra reglerna.

13. Ett gränssnitt som stödjer beslut

En användare ska kunna gå från fråga till förklaring utan att börja i en gigantisk graf.

Vy 1: scenario

Välj ändringstyp, före/efter, tid, tenant/miljö och beslut. Visa antaganden och vilken data som inte är åtkomlig.

Vy 2: sammanfattning

Visa separata mängder för nåbara, exponerade, troliga, bekräftade, unknown, refused och opåverkade. Bryt ned konsekvensdimensioner; använd inte ett ensamt rött antal.

Vy 3: varför

För varje objekt: relationstolkning, en eller flera kända vägar, källrevision, evidens, freshness, coverage och alternativa förklaringar. Markera uttryckligt när endast första BFS-vägen visas.

Vy 4: luckor och motbevis

Lista saknad version, avklippt traversal, stale observation, konflikt, otillåten tenant och test som skulle kunna ändra verdict.

Vy 5: handlingsalternativ

Jämför genomför, canary, skjut upp, isolera eller samla mer evidens. Visa tradeoffs, ägare, approval och verifieringsplan. Verkställighet hör fortsatt till ActionGateway, inte till impactvyn.

Vy 6: utfall

Efter förändringen jämförs förväntad och observerad konsekvens. Avvikelsen blir underlag för modell-, kontrakts- och processförbättring.

Figur FIG-08-01 sammanfattar denna kedja.

FIG-08-01 — Från ändringsscenario till beslutbar konsekvensbedömning

Visa diagramdefinition

flowchart LR
    S[Ändringsscenario<br/>före → efter, scope, tid] --> R[Nåbarhet<br/>kanter, riktning, djup]
    R --> E[Exponering<br/>vilka kan möta förändringen?]
    E --> P[Trolig påverkan<br/>semantik + antaganden]
    P --> C[Bekräftad påverkan<br/>observation + evidens]
    C --> A[Krävd handling<br/>ägarbeslut + grind]

    Q[Frågekontrakt<br/>grafrevision, filter, tenant] --> R
    V[Evidens och coverage<br/>färskhet, luckor, konflikter] --> P
    V --> C
    U[Okänt eller avklippt] -. får inte bli opåverkat .-> A
    A --> D{Beslut}
    D -->|genomför| M[Mät utfall och uppdatera claims]
    D -->|vägra eller utred| X[Ny evidens eller nytt scenario]
    M --> N[Ny evidens för nästa analyscykel]
    X --> N

14. När Matrix analyserar Matrix

Samma krav gäller systemets eget kontrollplan. En ändring i coordinatorns leasepolicy kan vara nåbar till agentkörningar, men påverkan måste skilja:

• levande agenter som exponerats för policyn,
• pausade agenter vars lease löper ut under fönstret,
• döda eller saknade workers,
• jobb vars resultat är stale eller saknar attestering,
• tenants och köer som inte får visas i aktuellt scope,
• prestandaförändring före och efter deployment.

Matrix kan inte trovärdigt förklara andra system om det inte lika tydligt kan förklara sitt eget tillstånd. En själv-impactvy bör använda samma scenario-, coverage-, evidens- och unknownmodell som kundlandskapet — inte en separat dashboard med andra sanningsregler.

15. Fallstudien som beslutsunderlag

Nordics xECM-uppgradering kan nu bedömas stegvis:

1. Lås scenario 26.1.2 → 26.2.0 och Nordic production.
2. Kör fleetanalys för auktoriserade tenantmanifest.
3. Traversera relevanta CONSUMES, DEPENDS_ON, EMITS och kontrollrelationer med deklarerat djup och kantfilter.
4. Klassificera nåbara objekt som exponerade eller irrelevant nåbara.
5. Jämför deklarerade och observerade kontraktsversioner.
6. Hämta evidens i relationernas kanoniska riktning och redovisa den kända implementationsluckan tills den är åtgärdad.
7. Kontrollera coverage, freshness, conflicts och authorization scope.
8. Bedöm konsekvens per dimension och jämför rolloutalternativ.
9. Kräv canary receipt, rollbackplan och namngiven ägare före handling.
10. Läs tillbaka utfallet och uppdatera bedömningen.

Det trovärdiga svaret är kanske inte "ja" eller "nej". Det kan vara:

Två auktoriserade tenants är exponerade via deklarerad konsumtion. En har bekräftad kontraktsskew, en har okänd runtimeversion. Dokumentflödets observation är färsk men populationstäckningen saknas. Genomför inte full rollout; samla versionsevidens och kör canary med kvitto- och rollbacktest.

Detta är Matrix värde: inte fler noder, utan ett beslut där det går att se vad systemet vet, varför det tror det och vad som fortfarande kan motbevisa det.

Sammanfattning

• Reachability är kandidatsökning, inte kausalitet eller konsekvens.
• Scenario, modellrevision och frågesemantik är del av resultatet.
• Exponering, trolig påverkan, bekräftad påverkan och handling är olika claims.
• Unknown, refused, not assessed och truncated får inte bli unaffected.
• Graf-, fleet- och contract-impact är komplementära bevislinjer.
• Deklarerad och observerad topologi ska jämföras med synlig coverage.
• Konsekvens bryts ned i dimensioner innan risk eller prioritet sammanvägs.
• Simulation är villkorad; verkligt utfall måste läsas tillbaka.
• Matrix egen coordinator ska kunna analyseras med exakt samma ärlighet.