Plan, simulering, mänsklig grind och verifiering

Nordic har tre förslag framför sig. Åttiosex meddelanden ska arkiveras, 42 filer ska flyttas och två deploymentoperationer ska appliceras. Alla tre har en knapp märkt Godkänn. Betyder knappen samma sak?

Nej. Ett meddelande kan ha flyttats när Graph-anropets svar försvinner. En filflytt kan reverseras bara så länge målvägen och filens identitet är oförändrade. En databasmigration kan lyckas delvis och sakna verklig invers. En människa kan fatta ett legitimt beslut över fel plan eller fel target.

Kapitlets kärnfråga är:

Hur kan Matrix bevisa att rätt avsikt godkändes, verkställdes högst så många gånger som kontraktet tillåter och gav den avsedda effekten?

1. Handlingskedjan

En trovärdig handling behöver minst följande tillstånd:

proposed → planned → previewed → approved → executing
          → applied | failed-before-effect | outcome-unknown
          → verifying → verified | deviation
          → rolled-back | compensated | manual-required

Det är inte en kosmetisk statustavla. Varje övergång kräver ny evidens:

approved, executed och verified är alltså olika claims (CLAIM-ACTION-003). Ett godkännande gör inte handlingen utförd. Ett tekniskt anrop med exitkod noll bevisar inte att verksamhetseffekten är komplett.

Figur FIG-10-01 visar varför outcome-unknown är en central förgrening.

FIG-10-01 — Från handlingsförslag till verifierat eller reconcilerat utfall

Visa diagramdefinition

flowchart LR
    subgraph MAIN["Huvudväg — avsikt till verifierat utfall"]
        direction TB
        [*] --> P[Proposed]
        P -->|bind intent + target + evidence| PL[Planned]
        PL -->|simulate / dry-run| PV[Previewed]
        PV -->|authorized decision| A[Approved]
        A -->|execution receipt started| E[Executing]
        E -->|provider receipt + known effect| AP[Applied]
        AP -->|test postcondition + coverage| V[Verifying]
        V -->|complete + fresh| OK[Verified]
    end

    subgraph EXCEPTIONS["Avvikelse- och återhämtningsvägar"]
        direction TB

        subgraph DECISION["Beslutet stoppar handlingen"]
            direction LR
            D[Denied]
        end

        subgraph EXECUTION["Exekveringsutfallet är inte en känd effekt"]
            direction TB
            F[FailedBeforeEffect] -->|policy permits retry| TOA[Nästa tillstånd: Approved]
            U[OutcomeUnknown] -->|receipt lookup / read-back| R[Reconciling]
            R -->|effect identified| TOAP[Nästa tillstånd: Applied]
            R -->|absence proven| TOF[Nästa tillstånd: FailedBeforeEffect]
            R -->|uncertainty remains| M[ManualDecision]
        end

        subgraph VERIFICATION["Verifieringen hittar en avvikelse"]
            direction LR
            DV[Deviation] -->|approved rollback / compensation| C[Compensating]
            C -->|verify compensating effect| TOV[Nästa tillstånd: Verifying]
        end
    end

    PV -->|reject or expire| D
    E -->|proven no effect| F
    E -->|crash / timeout after possible effect| U
    V -->|failed / partial / unknown| DV

2. Planen är kontraktet för beslutet

En användare ska inte godkänna en prosatext som senare tolkas fritt av en agent. Matrix behöver ett immutabelt ActionIntent:

actionId + actionType + intentDigest
initiator + rationale + evidenceRefs + impactAssessmentRef
target identity + tenant + environment + resource scope
normalized parameters + expected population
preconditions + postconditions + timeout
risk class + blast-radius cap + reversibility class
idempotency profile + receipt/read-back profile
approval policy + permitted roles + separation policy + expiresAt
executor/adapter identity and version
rollback or compensation intent template

Digesten ska täcka alla beslutsrelevanta fält. Om mottagare, filpopulation, miljö, executorversion eller plan ändras efter preview bryts godkännandet. Ett nytt intent kräver ny konsekvensbedömning och, där policyn kräver det, nytt beslut (CLAIM-ACTION-002).

Detta ger en viktig UI-regel: visa först vad som kommer att hända, var, med vilken population, varför och hur utfallet kan verifieras. Prompt, CLI-rad och rå JSON är drill-down.

3. Simulering är inte ett enda läge

Ordet simulering används ofta för oförenliga saker:

Matrix generatorflöde säger uttryckligen att dess simulation är på definitionsnivå: det läser spec och plan men startar inget (MATRIX-SIMULATION-FLOWS). Deployment apply har ett starkare statiskt dry-run som validerar executorscript, olösta placeholders och obligatoriska miljövariabler, men inte kontaktar remote system (MATRIX-DEPLOYMENT-APPLY).

Inget av lägena får etiketten “detta kommer fungera i produktion”. UI:t ska visa metod, target, tid, coverage och vad som inte prövades (CLAIM-ACTION-001).

4. Den mänskliga grinden

Matrix JAKE har en samlad approval-yta. Pending actions visas även om TTL gått ut; en utgången post kan avvisas men inte godkännas. Rollkontroll sker före typdispatch. En typ utan automatisk handler bokförs som approved men påstår inte att den körts (MATRIX-APPROVAL-GATE). Det är bra, fail-closed och ärligt.

En generell grind behöver dock besvara fler frågor än “ja eller nej”:

1. Är beslutsfattaren autentiserad och behörig för denna riskklass och tenant?
2. Är initiator, approver och executor tillåtna att vara samma principal?
3. Är evidens, impact och preview fortfarande färska?
4. Matchar visad digest den som exekveraren tänker köra?
5. Är target och credential identity fortfarande desamma?
6. Har någon precondition förändrats eller maintenance window stängt?
7. Är handlingen fortfarande pending, eller har en annan beslutsfattare vunnit?

NIST SP 800-53 AC-5 gör separation of duties till ett explicit behörighetsproblem, inte en visuell varning (nist80053r5). Matrix atomiska villkorsuppdatering gör att två samtidiga beslut inte båda kan vinna. Men separation och scope måste också bäras av det framtida intentkontraktet (CLAIM-ACTION-007).

5. Kraschfönstret som inte får döljas

ActionGateway köar alla okända actiontyper som gated och gör e-post och kalenderbokning obligatoriskt gated. Den skiljer mänskligt denied från execute_failed, och vägrar terminala dubbelbeslut (MATRIX-ACTION-GATEWAY).

Det finns ändå ett fundamentalt distribuerat systemsproblem. Flödet är:

DB: approved
external side effect
DB: executed

Om processen dör efter side effect men före sista DB-skrivningen kan den lokala databasen inte veta om handlingen skedde. Gatewayens egen återställningsguide varnar då för att godkänna igen, men samma approve() tillåter retry från både approved och execute_failed.

Ett hermetiskt test den 11 augusti 2026 använde en fejkad handler som först registrerade en effekt och därefter kastade fel. Samma action godkändes igen:

{"status":"execute_failed","side_effect_count":2}

Detta är reproducerad evidens för RESEARCH-026, inte bevis för att verklig e-post har dubbelsänts. Men det visar att execute_failed är för grovt: det kan betyda säkert fel före effekt, känt fel efter partiell effekt eller okänt utfall (CLAIM-ACTION-004).

6. Säker retry kräver ett kontrakt

AWS beskriver caller-provided request token, bevarad parameteridentitet och semantiskt ekvivalenta svar som mönster för retrybara API:er (aws-idempotent-apis). Matrix bör klassificera varje actionadapter:

En lokal idempotencytabell räcker inte om extern effekt och lokal token inte kan göras atomiska. En e-postleverantör måste deduplicera token eller ge ett receipt som kan frågas. För filflytt kan stabil filidentitet, käll-/målväg och metadata-read-back skapa en domänspecifik predicate. För desired-state- deployments kan “ensure target version” vara naturligt idempotent, men varje underliggande migration måste granskas separat.

7. Durable execution är inte exactly-once-magi

En workflowmotor kan ge beständig historik, timers, resume och operatörsvy. Temporal beskriver exempelvis event-sourcad workflowhistorik och kräver att aktiviteter med side effects är idempotenta eller icke-retrybara (temporal-architecture). Motorn tar alltså inte bort gränsproblemet; den gör orkestreringen robustare och felet synligare.

RESEARCH-028 ska därför jämföra Matrix nuvarande databasdrivna kedja med en minimal durable workflow-pilot. Utvärderingen ska mäta crash recovery, versionering, approval waits, operatörsinsyn, tenantisolering, driftkostnad och adapteridempotens. Ingen motor bör införas innan ett gemensamt ActionIntent/ActionReceipt finns; annars gör man ett otydligt kontrakt beständigt.

8. Matrix deploymentcheckpoint

Deployment apply har flera starka invariants:

• DRY_OK skiljs från live OK, så preview kan inte rollbackas som live,
• checkpointen binds till planfilens SHA-256,
• resume och rollback vägrar en redigerad plan,
• hela operationsmängden klassificeras före första execution,
• okänd eller executorlös operation fäller coverage-grinden,
• rollback körs i omvänd ordning och stannar vid första fel,
• misslyckad rollback heter ROLLBACK_FAILED och förblir actionable,
• operation utan rollbackexecutor heter MANUAL_REQUIRED, aldrig rolled back.

Testsviten verifierar dessa fall. Men om en process stannar med status RUNNING varnar den och kör samma executor igen. Säkerheten bygger på kommentarskontraktet att alla executors är idempotenta. Matrix bör göra detta maskinläsbart per operation, med idempotencyProfile, intent key, read-backpredicate och testbevis. Ett RUNNING efter krasch bör annars bli outcome_unknown, inte implicit retry (CLAIM-ACTION-009).

9. Verifiering är en ny observation

Verifiering ska inte fråga “returnerade kommandot noll?” utan:

postcondition(intent, fresh observed state, policy version)
AND coverage(expected population, observed population)
AND target identity matches

xECM-verifieringen visar rätt princip: med en plan jämförs alla bindbara planoperationer mot observerade bindings. En operation utan binding blir unbound och exit 2. Utan plan varnas användaren uttryckligen att populationsgrinden inte körs (MATRIX-XECM-VERIFY-GATE).

Två nyare Matrix-kedjor konkretiserar samma modell:

• User onboarding: en read-only plan härleds från Infrastructure-roller. Executorn är dry-run som standard, tillåter endast typade Graph-steg och vitlistade fält, kräver approval-ID, scopebevis och precondition-read, genererar execution password utan att persistiera det och gör read-back och journal med dedikerad workload identity.
• xECM record publication: en testkedja går i ordningen gate → folder → versioned upload → record declaration → read-back. Stubben får skrivas först efter verifierat receipt, aldrig som ersättning för en saknad effekt.

Båda är implementationsbevis för domänspecifika mönster, inte ett påstående om en färdig generell actionmotor eller en verifierad produktionsdeployment (MATRIX-USER-ONBOARDING-EXECUTOR, MATRIX-XECM-RECORD-PUBLISH, CLAIM-ACTION-010).

Verifiering bör vara så oberoende som praktiskt möjligt från write-adaptern. Om samma kod bara återberättar sitt requestobjekt är det ingen read-back. Receipt och observation får stödja varandra men ska inte blandas ihop. Resultatet behöver verified, deviation, partial, unknown, stale och refused, med saknad population redovisad (CLAIM-ACTION-006).

Den nu landade F39-kedjan gör denna distinktion konkret för konfigurations- scenarier. Profil, deterministisk data, content manifest, entityprojektion, blueprint, apply-plan/dry-run och scenario playbook är separata artefakter. NIS-beviset visar 1 760 av 1 760 förväntade blueprintobjekt och en plan med 1 295 operationer utan saknade eller oväntade objekt. Det är ett starkt genererings- och dry-run-bevis, men inte ett bevis för live deployment. Blueprintens informationsarkitektur är fortfarande manuellt författad; endast entityvärden projiceras automatiskt, och LLM-genererad dokumentkropp är inte byte-deterministisk. Design Studio måste därför visa varje led och dess bevisnivå i stället för att kalla hela generatorn antingen “klar” eller “målbild” (CLAIM-ACTION-011).

10. Rollback, undo och kompensation

Rollback är inte tidsresa. Efter en handling kan andra aktörer ha ändrat tillståndet, data kan ha konsumerats och externa meddelanden kan inte osändas. Sagas beskriver långlivade transaktioner som steg med kompenserande transaktioner, inte en global ACID-rollback (garciamolina1987sagas).

Matrix har konkreta mönster:

• filpiloten flyttar i stället för att radera, journalför gamla och nya sökvägar och verifierar metadata före undo (MATRIX-REVERSIBLE-FILE-ACTION),
• mailboxbatchen räknar om den färska mängden före körning, journalför flyttade item-ID:n och kan undo (MATRIX-PHASE0-EXECUTION),
• deploymentrollback stannar när en beroende operation inte kunde återställas.

En återställning ska därför vara ett nytt intent med egen risk, preconditions, approval, execution och verifiering. Om invers saknas ska UI säga compensation eller manual-required, aldrig lova rollback (CLAIM-ACTION-005).

11. Blast radius och gradvis autonomi

Agentens självskattade confidence avgör inte om den får agera. Policyn bör väga:

• handlingens verksamhets- och säkerhetskonsekvens,
• antal tenants, objekt och mottagare,
• irreversibilitet och kompensationskvalitet,
• evidensens freshness och coverage,
• target- och credentialstyrka,
• verifierbar postcondition,
• idempotensprofil och failure containment,
• tidigare verifierad historik för exakt capabilityversion.

Det ger en progression:

observe → recommend → plan → approve-one → capped batch
        → canary → bounded autonomy → broader autonomy

Varje steg kräver mätbar success rate och nya avbrytningsvillkor. En batchcap är en teknisk policy, inte en promptinstruktion. Fortsättning över cap skapar ett nytt plan-/beslutsobjekt. Hög påverkan eller okänd reversibilitet stannar vid mänsklig grind (CLAIM-ACTION-008).

12. Funktioner och use cases

UC10.1 — Skapa ett handlingsförslag

En användare eller agent väljer mål och avsikt. Matrix samlar evidens, förväntad population, risk, preconditions, postconditions och skapar ett versionsbundet intent. Ofullständigt target eller okänd actionprofil ger not-ready, inte en aktiv knapp.

UC10.2 — Jämför förhandslägen

Användaren väljer definition simulation, dry-run, provider preview, sandbox eller canary. Matrix visar kostnad, side effects, täckning och uttryckliga begränsningar. Resultaten kan inte uppgraderas till livebevis.

UC10.3 — Granska plan och konsekvens

Beslutsfattaren ser semantisk diff, berörda objekt och tenants, beroenden, unknowns, blast-radius cap, rollback/kompensation och hur utfallet ska verifieras. Rå plan finns som drill-down.

UC10.4 — Godkänn, avvisa eller låt förfalla

Matrix kontrollerar roll, separation, TTL, target, digest och färskhet vid beslutet. Avslag kräver skäl. Ändrat intent eller utgången TTL kräver nytt förslag; ett gammalt approval återaktiveras inte.

UC10.5 — Följ exekvering

Operatören ser attempt-ID, executor, target, current step, heartbeat, receipt, partial effects och auditpersistens. approved, executing, applied och verified har olika visuella och semantiska statusar.

UC10.6 — Hantera okänt utfall

Efter timeout eller krasch blockeras blind retry. Matrix söker provider receipt, korrelations-ID och live postcondition. Resultatet blir applied, failed-before-effect eller fortsatt outcome-unknown med namngiven ägare.

UC10.7 — Verifiera postconditions

Matrix läser tillbaka rätt target, jämför hela expected population och redovisar freshness, deviations och saknad coverage. Verifieringspolicyn och dess version ingår i kvittot.

UC10.8 — Rollback eller kompensera

Användaren ser vad som faktiskt kan återställas, vad som redan konsumerats och vilka nya risker som uppstår. Ett separat intent skapas och verifieras efter utförd rollback/kompensation.

UC10.9 — Kör begränsad batch och fortsätt

En första batch håller sig inom objekt-, tenant-, tids- och felcap. Matrix stoppar vid avvikelse. Fortsättning använder observerat batchutfall och kräver nytt beslut om policyn eller populationen säger det.

UC10.10 — Granska ansvar och audit

En revisor följer initiator, planförfattare, approver, executor och verifierare, inklusive rollbevis och alla nekade försök. Saknat auditkvitto visas separat från handlingsutfallet.

UC10.11 — Planera en fleet-handling

En fleetoperatör simulerar per behörig tenant, grupperar risk och börjar med canary. Counts beräknas efter tenantfilter. En tenants okända utfall stoppas från att döljas i flottans totalsiffra.

UC10.12 — Matrix ändrar Matrix

Coordinator-, agent-, policy- eller modelländring går genom samma intent, approval, capped rollout, health/read-back och rollbackregler. Matrix får inte ge sitt eget kontrollplan ett osynligt undantag.

UC10.13 — Planera och genomför user onboarding

Behörig handläggare väljer en deklarerad roll. Matrix visar exakt användare, grupper, licenser, Graph-operationer, scopes och preconditions. Dry-run gör ingen effekt. Efter ett giltigt approval verkställer den dedikerade executorn stegvis, håller lösenord utanför beständig plan/journal och verifierar varje postcondition. Delutfall blir synligt och får inte sammanfattas som “onboarded”.

UC10.14 — Publicera och deklarera en xECM-record

Operatören granskar target, folder, version och recordklass. Kedjan skapar eller identifierar foldern, laddar upp en version, deklarerar record och läser tillbaka resultatet. En stub eller leveransmarkering skapas först efter kvitto; saknat kvitto ger unknown/manual reconciliation, inte en grön leverans.

13. Gränssnittshierarki

Handlingsytan bör organiseras efter beslut och utfall:

1. Action center: pending, executing, outcome-unknown, deviations och verifierade handlingar med risk och ägare.
2. Intent: avsikt, target, population, plan, impact, digest och TTL.
3. Preview: typ av simulation, resultat, coverage och obevisade antaganden.
4. Decision: behörighet, separation, beslut, skäl och policyversion.
5. Execution: attempts, steg, receipts, heartbeats och partial effects.
6. Verification: postconditions, read-back, coverage, freshness och verdict.
7. Recovery: receipt reconciliation, retry eligibility, rollback, compensation och manual-required.
8. Audit: immutable timeline, identiteter, sourceRefs och evidensluckor.

Den viktigaste kön är inte bara “väntar på godkännande”. Den måste också visa handlingar vars utfall är okänt. De är ofta farligare än både röda fel och väntande beslut.

14. Nordic som verifierad handling

1. Frys tre separata intent för mailbox, filer och deployment.
2. Räkna full population och sätt cap per domän.
3. Kör rätt previewtyp och redovisa vad den inte bevisar.
4. Bind impact, target, executorversion och postconditions i digest.
5. Kontrollera roll, separation och TTL; godkänn exakt digest.
6. Skapa attempt innan första externa effekt.
7. Spara provider receipt och korrelation när adaptern stödjer det.
8. Vid krasch: klassificera utfallet som okänt och läs tillbaka innan retry.
9. Verifiera hela populationen mot rätt miljö och tenant.
10. Stoppa nästa batch om deviations eller coveragebrist uppstår.
11. Skapa separat rollback/compensation intent där det behövs.
12. Verifiera också återställningen och redovisa auditpersistensluckor.

Det slutliga svaret kan då vara:

Mailboxintent A arkiverade 86 av 86 identifierade meddelanden och verifierades via item-ID-read-back. Filintent B flyttade 41 av 42 filer; en fil hade ändrats efter planen och stoppades. Deploymentintent C tappade svar efter steg två. Providerkvittot saknas och live predicate är inte entydig; utfallet är därför outcome-unknown och automatisk retry är blockerad.

Sammanfattning

• Approval är ett versionsbundet beslut, inte bevis på handling.
• Simulation, dry-run, preview, sandbox och canary ger olika evidens.
• Ett möjligt externt utfall kräver outcome-unknown, receipt lookup och read-back före retry.
• Idempotens är ett adapterkontrakt som måste testas och bindas till intent.
• Verifiering mäter postcondition, population, target och freshness.
• Rollback är en ny felbar handling; ibland finns bara kompensation.
• Autonomi följer risk, blast radius, reversibilitet och verifierbarhet.
• Matrix ska använda samma handlingskontrakt när det ändrar sitt eget system.