Agentiska system och Coordinatorn

Nordics operatör öppnar Matrix och ser RUNNING. Ett systemd-unit för en worker håller samtidigt på att starta. Tokenräknaren stiger. Är arbetet friskt?

Det går inte att avgöra från någon av uppgifterna ensam. RUNNING kan betyda att en lease finns. Ett färskt heartbeat kan betyda att en process fortfarande har kontakt. Ett aktivt unit kan betyda att operativsystemet håller processen vid liv. Tokens kan betyda att en modell producerar text. Inget av detta bevisar att rätt uppgift gör framsteg eller att resultatet blir användbart.

Kapitlets kärnfråga är:

Hur kan Matrix förklara vad dess eget kontrollplan gör, varför det gör det, vad som faktiskt lever och om arbetet ger verifierbar nytta?

1. Kontrollplan, inte agentlista

Coordinatorn omvandlar efterfrågan till kontrollerad exekvering. Den behöver veta vilket arbete som är körbart, vem som får claima det, hur länge ägarskapet är trovärdigt, när ett försök ska återvinnas och vilken kapacitet som får startas. Agenten utför; kontrollplanet tilldelar, begränsar och förklarar.

Matrix implementation har redan huvuddelarna:

• en PostgreSQL-kö med beslut, beroenden, surface-lock och atomisk claim,
• lease och heartbeat med reap och redispatch,
• separata köepisoder i work_queue_runs,
• ett agent-run-register även för arbete utanför kön,
• stage- och journeyvyer för överlämningar,
• en stage-kedja som föds vid dispatch och skiljer bygg, oberoende granskning och bevakad landing,
• en fleet-supervisor som reapar, mäter READY-djup och startar workers,
• append-only arbetshändelser och explicita progressmarkörer,
• ett runtime-passport som jämför körande kod, checkout, main och schema,
• agentanvändning och modellförbrukning,
• en bred health-yta för units, prober, timers och larm.

Styrkan är att delarna inte låtsas vara samma sak. Produktluckan är att de ännu inte samlas till en operativ förklaring (CLAIM-AGENT-009).

2. Identiteter som aldrig får kollapsas

Figur FIG-11-01 visar kontrollplanet som flera korrelerade tidslinjer.

FIG-11-01 — Från arbete via eventdriven review till förklarad landning

Visa diagramdefinition

flowchart TB
    subgraph FLOW["Operativ huvudväg"]
        direction LR
        T[Agenttyp + policy<br/>modell + verktyg]
        W[Work item + lease<br/>heartbeat + episode]
        R[Build run + stages<br/>handovers + receipts]
        N[Stage completion<br/>bokför + NOTIFY]
        Q[Wake-up listener]
        H[Scheduling assessment<br/>demand + supply + cap<br/>health + ekonomi + eval]
        B[Review claim + bokförd dom<br/>head + actor + verdict]
        G{Landing gate<br/>non-FAIL + head + oberoende?}
        M[Merge / landning]
        D[Vägran / skuld]

        W -->|claim / reap / redispatch| R
        T -->|binder agent, modell och verktyg| R
        R --> N
        N -. NOTIFY, ej sanningskälla .-> Q
        Q --> H
        H -->|coverage + freshness| B
        B --> G
        G -->|ja| M
        G -->|nej| D
    end

    subgraph EXPLANATION["Separat läsmodell — inte en ny exekveringsväg"]
        direction LR
        S[Bokförda tillstånd som läses:<br/>work item · run · stage · receipt<br/>verdict · gate · health]
        X[Coordinator explanation<br/>validAt + coverage + unknowns]
        S -->|projektion| X
    end

    G -. bokförda tillstånd .-> S

Ett manifest är en definition, inte en process. En process kan finnas utan en köpost. En köpost kan redispatchas över flera processer. En process kan göra flera modellanrop och lämna flera stages. Därför behöver Matrix stabila korrelationsfält i stället för att använda assignee som universell identitet (CLAIM-AGENT-001). W3C Trace Context ger ett standardiserat sätt att föra traceidentitet över tjänstegränser, men ersätter inte Matrix domän-ID:n (w3c-trace-context).

3. Arbetsstatus är inte processstatus

Det lagrade köfältet innehåller fortfarande QUEUED, READY, RUNNING, BLOCKED, ERROR, DONE och PARKED, men den nya read-path-modellen slutar behandla dem som en enda livscykel. Itemlagrets projektion är exakt OPEN, DONE eller PARKED. [!] blir flaggan blocked_in_item på en öppen post. Readiness får startable och den maskinkodade förklaringen startable_unmet; runtime, stage, beslut och lease behåller sina egna axlar. Det lagrade sjugradsfältet krymper först i en senare migration när alla writers har flyttats. Detta är en läsmodell, inte bevis för genomförd schemamigration.

Agentinstansen behöver i sin tur tillstånd som starting, running, draining, paused, contact-lost, finished och terminated. Ett supervisor-unit har systemdstatus och en kontrolltick ett eget utfall.

PARKED är medvetet nedprioriterat av användaren och räknas därför som ett uppfyllt beroende: det ska inte hålla efterföljande arbete gisslan. Producenten måste samtidigt ange CODE_DEPENDENCY_PARKED; den får inte översätta detta till det falska påståendet att alla beroenden är klara. BLOCKED väntar på ett namngivet villkor eller en aktör. ERROR betyder att ett försök misslyckats. contact-lost betyder att en lease inte längre kan litas på. Den tidigare beslutsdomen defer är nu pensionerad för nya skrivningar; parkering sker på itemaxeln medan gamla defer-domar förblir läsbar historik. Dessa begrepp får inte slås ihop till rött eftersom nästa handling är olika (CLAIM-AGENT-010).

En särskild stage-risk är självgranskning. Om ändringen träffar stage- mekanikens testlåsta yta kan den automatiska profilen inte trovärdigt godkänna sin egen grind. Jake-implementationen detekterar därför filytan före claim, stämplar stage BLOCKED och låter tillståndet stoppa kedjans avancemang. Vid landing godtas denna yta endast när den bokförda domen kommer från den särskilda cc:independent-review-*-klassen. Den automatiska reviewvägen får inte själv mynta ett namn i den klassen. En exception handler bör fortfarande häva blockeringen och claima arbetet i samma transaktion; writerparet verkställer inte denna samtidighet, och namnrymden är klassificering snarare än kryptografiskt identitetsbevis (CLAIM-AGENT-015).

En annan oberoendevakt ligger direkt i Jakes stage-claim. _refuse_run_author läser tidigare stage-raders run_id och vägrar den länkade körningsepisodens assignee från att claima ett senare steg i samma kedjeinstans. Det stoppar A→B→A när run-länken finns, men är inte ett generellt personhistoriskt förbud: en ny attempt saknar tidigare run-historik, borttagna runs lämnar nullable länkar, jämförelsen gäller assignee snarare än claimed_by, och reviewvägen kan claima utan run_id. Regeln är därför en värdefull episodvakt med uttryckliga identitets- och coveragegränser (CLAIM-AGENT-016).

Användarens tillfälliga “väg till DONE” behövs inte som produktens informationsarkitektur. Coordinatorns permanenta frågor är efterfrågan, ägarskap, kontakt, kapacitet, progress, blockerare, effekt och ansvar.

4. Lease, heartbeat och död

En worker claimar atomiskt med FOR UPDATE SKIP LOCKED. Coordinatorn sätter lease och heartbeat; exekveraren äger inte sanningen om sitt eget liv. Vid claim kör dispatchern reap_stale(). En faktisk lease vars heartbeat passerat budget redispatchas, upp till ett tak på tre, och försökshistoriken bevaras (MATRIX-QUEUE-DISPATCH).

Claimen öppnar dessutom ett köförsök och claimar kedjans aktuella stage i samma transaktion. Leasefält och surface är en odelbar grupp. Efter en godkänd build-handover stängs build-stage och köepisoden, hela gruppen rensas och posten stannar RUNNING men dormant i väntan på granskning. Den saknar då avsiktligt lease, ska inte reapas och låser inte sin surface (MATRIX-QUEUE-READINESS, MATRIX-QUEUE-CHAIN-LIFECYCLE). Därför betyder RUNNING utan lease inte alltid korruption; vyn måste först skilja dormant handover från en oförklarad mismatch.

Detta ger precisa men begränsade claims:

fresh heartbeat  ⇒ kontakt observerad inom budget
expired heartbeat ⇒ lease ej längre betrodd
active process   ⇒ operativsystemet ser en process
none of these    ⇒ rätt resultat eller meningsfull progress

“Död agent” bör därför bara användas när en namngiven detector och tidsbudget stöder det. Annars heter läget contact-lost, process-exited eller measurement-unknown. Heartbeat bevisar liveness, inte kvalitet (CLAIM-AGENT-002, CLAIM-AGENT-003).

5. Två slags försök och två skilda tak

Reap gör kön till at-least-once. Om worker A gör effekt men tappar heartbeat kan worker B få samma arbete. Kapitel 10 visade varför externa side effects då behöver idempotency key, receipt eller read-back. Coordinatorn måste dessutom visa varje försök separat:

work item
  attempt 1: agent A, started, last heartbeat, lease expired, outcome unknown
  attempt 2: agent B, started, stages..., verified outcome

En slutlig grön arbetsrad får inte skriva över det osäkra första försöket. work_queue_runs har rätt grund: en rad per READY→RUNNING-episod, öppnad och stängd i samma transaktion som köövergången. Den bör korreleras med agent-run, trace, action receipt och evaluation (CLAIM-AGENT-004).

Köepisoden får inte blandas ihop med stage-kedjans round. Reap-/leasetaket (standard tre) begränsar återtaganden efter tappad kontakt. Kedjetaket COORDINATOR_CHAIN_ATTEMPT_CAP (standard två) begränsar rundor som en FAIL-verdict har pensionerat. Ett granskningsfel dödar alltså rundan, inte arbetsobjektet: posten öppnas igen som READY eller QUEUED beroende på sina beroenden. Efter loop-guard-blockering finns en uttrycklig requeue_after_review för namngiven granskare och motivering. Den vägen gäller inte blockering från backloggens [!] eller ett förbrukat verdicttak. De två försöksdimensionerna får därför aldrig summeras i ett enda attempt utan typ och orsak (CLAIM-AGENT-011).

6. Fleet-supervisorn som autonom controller

Den nuvarande kontrollslingan gör i ordning:

1. reapa döda leases,
2. pausa ny spawn vid kredit-/sessionsentinel,
3. läs READY-djup och levande workers,
4. beräkna desired = min(cap, ready),
5. starta fria slots.

Det versionerade byggtaket är nu åtta och reviewtaket fyra. Supervisorn dödar inte workers; nedskalning sker passivt när one-shot-workers avslutas. Read-only-kontroll den 11 augusti 2026 visade att matrix-fleet-supervisor.timer var enabled och aktiv, tickade ungefär var annan minut och senast avslutades grönt. Det motbevisar arkitekturdokumentets äldre uppgift att supervisorn ännu inte var byggd.

Varje kontrolltick bör sparas som ett förklarbart beslut:

observedAt + input revisions
ready depth + live/starting/draining workers
stale leases + reap result
cap + pause sentinel + policy version
desired + chosen action + refusal/reason
spawn result + next evaluation + controller health

Om reap misslyckas men spawn fortsätter ska UI visa båda sanningarna. “Tick grön” får inte dölja att en delobservation föll. En autonom controller måste kunna svara “varför tre workers?” och “varför ingen ny?” (CLAIM-AGENT-005).

7. Stage-kedjan är både kontroll och progressbevis

Elapsed time, CPU, tokens och loggrader är aktivitetssignaler. Progress kräver en förväntad kedja och observerade predicates:

implemented chain: build → code_review → landing
completed: build
current: code_review
post state: RUNNING, dormant, no lease
blocked predicate: attended landing by an independent actor
evidence: build verdict + review verdict + main-branch checkmark

Kedjan skapas vid dispatch, inte först när arbetet påstås vara färdigt. queue_journey kan sammanfoga köepisoder, stages och agentregister och låter otypade episoder vara ärligt otypade när registret saknas. Landing kräver en human:-namngiven aktör, huvudgrenens [x] och en annan aktör än föregående reviewer. human: är dock bara en strukturell namnregel; trovärdig personidentitet måste senare bindas från autentiserad ingress och policyreader (MATRIX-QUEUE-LANDING, RESEARCH-032). För andra arbetsklasser återstår att deklarera start-/slutpredicate, expected population och verifieringsbevis. Procent får endast visas när nämnaren är definierad (CLAIM-AGENT-007).

Coordinatorn har nu dessutom work_queue_events: ett append-only-spår för subaktivitet, kompletterat med last_progress som cache på arbetsposten. Progressmarkörer färdas med heartbeat men skrivs i samma transaktion som händelsen. Det är en viktig separation: heartbeat säger kontakt, medan en markör som build_started, suite_green, suite_red, review_round eller evidence_written säger att en namngiven milstolpe rapporterats. Vokabulären är liten och kodregistrerad, aktörsnamnen är självdeklarerade och någon retention är ännu inte definierad. Append-only-egenskapen verkställs i den aktuella modulen och dess tester, inte av en databastrigger, och de granskade produktionsskrivarna skickar ännu inga progressmarkörer. UI ska därför visa “progress ej observerad” i stället för en fabricerad tidslinje eller procent: spåret är varken komplett processmodell eller kvalitetsbevis (CLAIM-AGENT-017).

8. Prestanda, kostnad och effekt

jake_inference_economics bokför ett anrop per completion med flow, run-ID, agent, modell, input-, output- och cachetokens. Svar utan usage räknas som usage_unknown; modell utan prisrad visas utan fabricerad kostnad. Det är en stark täckningsprincip.

Nuvarande schema saknar dock anropslatens, error type och domänutfall. Tokens per agent kan därför besvara förbrukning men inte:

• genomströmning och kötid per arbetsklass,
• p50/p95/p99-latens per stage och modell,
• fel- och timeoutandel,
• verifierad success rate och regressionsfrekvens,
• kostnad per korrekt resultat eller uppnått verksamhetsmål.

NIST AI 800-4 skiljer funktionalitets-, operations-, human factors-, security-, compliance- och storskalig impact-monitorering och framhåller att pre-deployment-evals inte fångar verklig dynamik (nistai8004). Därför behöver Matrix två axlar: effektivitet (tid, kö, tokens, kostnad, resurser) och effekt (verifierat resultat, eval, mänsklig override, incident och nytta). Billigare fel är inte bättre (CLAIM-AGENT-008).

9. Mättäckning och osynliga agenter

Agent-run-registret inkluderar arbete utanför kön och har running och finished. Registreringen är ändå frivillig. En startad process som inte registrerar sig är osynlig för den populationen.

ask_agent har nu en per-session fanoutbudget som är avstängd som standard och faller stängt vid felaktig konfiguration. En valfri handover-stamping kan skriva payloadhash — inte innehållet eller en fabricerad completed-post — men endast för verifierad människa och bara när storekopplingen är konfigurerad. Detta minskar kedjeexplosion och förbättrar spårbarhet, men är inte ett universellt bevis för all delegering (MATRIX-ASK-AGENT-FANOUT, MATRIX-HANDOVER-STAMPING).

agent_usage gör rätt när det bara säger zero_usage om delegationer, agent-runs och inferencekällan alla kan läsas. En onåbar källa ger unknown. Rapportens nämnare är de 49 registrerade agenttyperna i den låsta revisionen: 7 kategori B, 3 kategori C och 39 kategori D. Alla har actionpolicy; ingen deklarerar modell eller tools i manifestet. Det äldre arkitekturdokumentets 45 och tio saknade policies är historiska observationer, inte nuläge.

Gränssnittet behöver alltid visa:

observed / expected / unknown / stale / unregistered
source status + validAt + sourceRevision

Annars blir ett tomt diagram falskt lugnande (CLAIM-AGENT-006).

10. Ett korrelerat nuläge, inte global magi

Kö, agent-run-register, systemd, SQLite-ekonomi, health-prober och evalstore uppdateras inte atomiskt. Coordinator-översikten ska därför inte märka sin sammanställning “sanningen kl. 12:42:12”. Den ska visa per källa:

• observerad tid och revision,
• freshnessbudget,
• korrelationsgrad,
• konflikter och luckor,
• om data är direkt observation, härledning eller konfiguration.

OpenTelemetry semantic conventions kan ge gemensamma namn för spans, metrics, fel och messagingkorrelation. Både messaging- och GenAI-delarna är under utveckling eller migration, så Matrix bör versionspinna en exportprofil och behålla sina domänkontrakt (otel-semconv143, otel-messaging-spans).

11. Den konkreta 8181- och runtime-luckan

En live snapshot från den tillfälliga localhostytan den 11 augusti 2026 visade 564 DONE, 27 BLOCKED, 34 PARKED, 20 QUEUED och en RUNNING-post claimad av cc:build-pass. Snapshoten är inte en produktbaslinje; värdena är flyktiga.

Den viktiga observationen är formen. RUNNING-raden exponerade assignee och updated men inte heartbeattid/-ålder, stalegräns, run-ID, försöksnummer, workerstatus eller fleetbeslut. Coordinatorns vanliga build_view har redan run_seconds, heartbeat_age_s, stale, stale_after_s och redispatch_count; den tillfälliga ytan förenklar bort dem. Två interna ytor kan därmed berätta olika mycket om samma arbete. RESEARCH-029 gör detta till en rekommenderad backlogkandidat.

Sedan snapshoten togs har en operativ köcockpit landat i Jake med KPI-rad, arbetstabell och ett chain-deriverat pipelineflöde. Den bevarar unknown när stagekedjan inte kan läsas. Den 13 augusti var även 8181-sidan installerad som versionerad user service med loopbroms, men den svarade fortfarande med rubriken “Kön — tillfällig sanningssida”. Den är alltså en ärligare och mer driftbar brygga, inte den permanenta produktvyn.

Samma kontroll gav ett ännu tydligare självförklaringsbevis. Vid den första läsningen rapporterade /health körande Jake, checkout och main på a8e1d4a. Några minuter senare hade main flyttat två commits till c82ee2e, medan den körande processen och serve-checkouten stod kvar på a8e1d4a. Koden förväntade migration 0022_elicitation_split_out, live-databasen stod på 0021_finding_improvement_class och serve-stämpeln saknades. Passportets Coordinatorfält visade källrepots nya HEAD d0f02e4, men implementationen läser repo-HEAD vid frågetillfället och bevisar därför inte att den redan startade processen laddat den revisionen. Processen var levande samtidigt som source freshness, schema och utrullningskvitto avvek. Passportet gör en verklig lucka synlig och avslöjar samtidigt behovet av striktare fältsemantik (CLAIM-OPS-011).

En ny read-only-observation den 13 augusti cirka 22:12 CEST visade samma mönster med större avstånd: processen körde a8e1d4a, checkout och main var c8f69b6, serve-stämpeln saknades och 0022 var fortfarande landad men inte applicerad över live-schemats 0021. Samtidigt svarade paneltjänstens egen /health endast {"status":"ok"}. Service-passportet är alltså ett lokalt bevis för bridgeprocessen, inte ännu ett servicefamiljekontrakt.

Eventdriven granskning är en styrslinga, inte en notifieringsfunktion

Stage completion emitterar nu en PostgreSQL-notis som väcker en resident listener. Notisen är uttryckligen en otrustad hint: listenern claimar inget och använder inte payloaden som sanning. Kapacitetsticket återläser bokförda READY- steg, jämför demand med levande review-workers och tillämpar ett tak per profil [CLAIM-AGENT-012].

stage completion → NOTIFY → listener → capacity tick
→ återläs READY + levande reviewers → eventuellt spawn
→ claim ur Coordinator → review → bokförd dom

Slingan är avsiktligt parkerad när JAKE_REVIEW_FLEET_MAX saknas: cap blir noll. I den versionerade servicekonfigurationen vid bokens aktuella lås är profilcap däremot fyra och listenern var aktiv i read-only-kontrollen den 13 augusti. Kontrollplanet måste ändå visa listener connected, senaste notice, senaste tick, demand, supply, cap, parkeringsorsak och återanslutningar separat. Ett positivt tak bevisar inte att någon reviewer kör [CLAIM-AGENT-013].

12. Funktioner och use cases

UC11.1 — Förstå kontrollplanets nuläge

Operatören öppnar översikten och ser arbetsdemand, färska/starting/draining/ contact-lost agentinstanser, fleet-cap, pausorsak, senaste controllertick, fel, blockers och mättäckning. Varje siffra visar validAt och kan öppnas till populationen bakom.

UC11.2 — Inspektera ett aktivt arbete

Operatören öppnar arbetsobjektet och ser beslut, beroenden, current lease, heartbeatålder, stalebudget, köepisoder, stages, expected population, agent-run, traces, actions och verification. Dormant handover visas uttryckligt som väntan mellan stages, inte som död lease. Leaseförsök och kedjerundor visas var för sig; tidigare försök skrivs inte över.

UC11.3 — Inspektera en agentinstans

Användaren ser agenttyp, process/unit, launcher, purpose, owner, starttid, senaste heartbeat, aktuella leases, stages, modellcalls, resursbruk och terminalt utfall. Saknad registrering eller korrelation visas som lucka.

UC11.4 — Skilja pausad, blockerad, parkerad och tappad kontakt

Matrix klassificerar arbetsstatus, processstatus och beslutsstatus separat. Vyn anger detector, orsak, ägare och nästa handling. Användaren kan inte “återuppta agent” när det egentligen är arbetet som väntar på extern input. Ett parkerat beroende visas som avsiktligt accepterat, inte som DONE.

UC11.5 — Förklara fleetbeslut

Operatören öppnar en tick och ser READY-djup, live supply, cap, sentinel, stale leases, policyversion, desired count och spawn/refusalresultat. En kontrafaktisk simulering visar vad en annan cap skulle ha gjort utan att ändra drift.

UC11.6 — Pausa, dränera och återuppta kapacitet

Behörig operatör skapar ett intent för att pausa nya claims eller dränera en worker. Matrix visar berörda leases och blast radius. Den nuvarande supervisorn har ingen kill-väg; framtida stop/cancel får inte låtsas finnas innan explicit action-, receipt- och recoverykontrakt har byggts.

UC11.7 — Reapa och redispatcha stale lease

Automatik eller operatör ser expired heartbeat, tidigare attempts och idempotensprofil. Matrix reapar bara en verklig lease, bevarar episoden och redispatchar inom tak. Okänt actionutfall blockerar osäker retry.

UC11.7a — Hantera handover och granskningsrunda

Build lämnar över med verdict och släpper hela leasen. Reviewer claimar nästa stage oberoende. FAIL pensionerar rundan och öppnar ny inom kedjetaket; loop-guard-blockering kan återöppnas först efter namngiven review. UI blandar aldrig ihop denna runda med stale-lease-redispatch.

UC11.8 — Följa progress och blockerare

Användaren ser completed/current/expected stages, täckt population, predicatebevis, väntande beslut och extern dependency. Loggrader och elapsed time visas som signaler, aldrig som fabricerad procent.

UC11.9 — Mäta prestanda och kapacitet

Operatören jämför queue wait, run duration, throughput, error rate, latency, reap rate, saturation och resursbruk per arbetsklass, agenttyp och version. Okända mätvärden och hög kardinalitet redovisas.

UC11.10 — Mäta kostnad och effekt

Produktägaren följer tokens, cache, priscoverage och kostnad per run och verifierat utfall, tillsammans med eval, override och incident. Modeller utan pris eller calls utan usage ingår i coverage men får ingen påhittad kostnad.

UC11.11 — Förvalta agentkatalog och policy

Arkitekten ser alla registrerade typer, kategori, ägare, capability, actionpolicy, faktisk användning och versionsdrift. Modell- och toolpolicy visas som “ej deklarerad” där manifestet saknar dem, inte infererat från namn.

UC11.12 — Upptäcka osynlig och oanvänd kapacitet

Matrix jämför registrerad population med delegations-, run-, queue- och inferencekällor. Den skiljer verifierat oanvänd, unregistered activity, claim mismatch och measurement unknown.

UC11.13 — Granska delegering och överlämning

Revisorn följer mål, DoD, grindnivå, actionpolicy, source/target-agent, submitted/completed/failed, stages och evidensbasis. Handoverpayload och promptinnehåll skyddas efter dataklass.

UC11.14 — Jämföra agent- och modellversioner

Evaluatorn grupperar likvärdiga uppgifter efter agent-, prompt-, policy- och modellversion. Matrix visar outcome- och coveragefördelning och vägrar kalla ojämförbara populationer en regression.

UC11.15 — Hantera controllerfel

När reap, registry, database, systemd eller model meter faller visar Matrix vilken del av kontrollslingan som är blind, vilka beslut som ändå togs och om nya claims/spawns bör fail-closed. Controller health har egen ägare och SLA.

UC11.16 — Matrix förklarar Matrix

Användaren ställer “varför kör detta?”, “varför står det still?”, “vad vet du inte?” eller “vad ändrades sedan förra bilden?”. Svaret binds till work-, run-, lease-, stage-, decision-, telemetry- och evalreferenser med per-källa validAt.

UC11.17 — Jämför landad kod med verklig runtime

Operatören öppnar ett service-passport och ser processrevision, checkout, main-tip, utrullningsstämpel, komponenternas processbundna eller uttryckligt icke processbundna revisioner samt landad och applicerad migrationsrevision. Varje mismatch får egen konsekvens och åtgärd. Okänd stämpel eller laddad komponentrevision visas som okänd, inte som lyckad deploy.

UC11.18 — Följa faktisk progress utan att förväxla den med heartbeat

Användaren ser senaste heartbeat och senaste progressmarkör sida vid sida och kan öppna den append-only tidslinjen. En okänd eller otillåten markör vägras, men frånvaro av markör betyder “progress ej observerad” och inte automatiskt att arbetet står still.

13. Gränssnittshierarki

Två helvyer gör skillnaden mellan arbete och plattformsdrift konkret. SCREEN-11-01 visar arbetsöversikten med lifecycle, readiness, runtime och stage som separata axlar.

SCREEN-11-01 — Arbetsöversikt med separata lifecycle-, readiness-, runtime- och stageaxlar. Konceptvy; status, antal och tider är demodata medan tillståndsaxlarna är avsiktliga.

SCREEN-11-02 visar Control Plane med passport per tjänst och enforcement per repo och DONE-dörr. Båda är konceptvyer byggda från daterade observationer, inte live-UI.

SCREEN-11-02 — Control Plane med service-passports och enforcement per repo och DONE-väg. Konceptvy byggd från daterad read-only-observation; inte en livepanel.

Coordinatorns permanenta produktområde bör ha följande nivåer:

1. Control plane overview: demand, supply, active/contact-lost, blockers, fleet decision, alarms och measurement coverage.
2. Work: queue states, leases, queue episodes, chain rounds, dependencies, dormant handovers, stages och progress.
3. Agents & runs: instanser, purpose, owner, liveness, process och aktuellt arbete; agentkatalogen är en separat typvy.
4. Fleet & capacity: cap, pause/drain, slots, controller ticks, reap och kontrafaktisk capacity simulation.
5. Performance & economics: queue/run latency, throughput, saturation, tokens, cache, cost coverage, evals och kostnad per verifierat utfall.
6. Decisions & recovery: blockers, approvals, stale leases, unknown outcomes, redispatch, cancel/drain och manual-required.
7. Catalog & policy: agenttyper, capabilities, actionpolicy, modeller, tools, ägare, version och faktisk användning.
8. Audit & coverage: journeys, handovers, traces, source freshness, unregistered activity, mismatch och dokumentationsdrift.
9. Runtime & deployment: service-passports, process/checkout/main, utrullningsstämplar, migrationsdrift och komponentvis coverage.

Översikten ska prioritera avvikelser och nästa aktör, inte skapa ett övervakningsrum av dekorativa grafer. Rå logg, JSON, SQL och systemd är drill-down; förklaringen är primär.

14. Datakontrakt för en CoordinatorSnapshot

En framtida additiv snapshot bör minst bära:

snapshotId + assembledAt + assemblerVersion
sourceObservations[] {source, validAt, revision, freshness, status, error}
workSummary + workItems[] + leases[] + queueEpisodes[] + chainRounds[]
agentTypes[] + agentRuns[] + processObservations[]
stages[] + handovers[] + supervisorDecisions[]
inferenceCalls/aggregates + resourceMetrics + evaluations[]
correlationCoverage + measurementCoverage + conflicts[] + unknowns[]

Detta är en sammanställning, inte en ny auktoritativ databas. Varje detalj pekar tillbaka till sin ägande källa. Ett gemensamt trace-ID förbättrar korrelation; det ger inte global transaktion eller full population.

15. Nordic som kontrollplansutredning

1. Frys översiktens per-källa validAt och revision.
2. Öppna RUNNING-postens lease, dormant-förklaring, queue episodes och kedjerundor.
3. Korrelera assignee mot agent-run och faktisk process/unit.
4. Bedöm heartbeatålder mot uttrycklig stalebudget.
5. Läs stages och expected population; markera progress unknown om nämnare saknas.
6. Öppna senaste supervisorbeslut och dess inputs, inklusive reaperesultat.
7. Korrelera inference med run och beräkna usage-/pricecoverage.
8. Läs verifierat utfall/eval; separera effektivitet från effekt.
9. Om kontakten tappats, bedöm actionernas idempotens före redispatch.
10. Spara förklaringen med luckor och nästa ansvariga aktör.

Resultatet är inte “grönt” eller “rött”. Det är ett evidensbundet svar på vad som arbetar, vad som väntar, vad som inte längre kan betros och vad Matrix ännu inte kan veta.

Sammanfattning

Ett agentiskt kontrollplan blir trovärdigt när det kan beskriva sina egna identiteter, försök, tidsbudgetar, beslut, resurser, utfall och luckor. Matrix har redan starka byggstenar: atomisk claim, leases, episoder, agentregister, journey, fleet-controller, health och ekonomimätning. Nästa steg är inte fler statusbrickor. Det är en korrelerad, tidsmedveten och ärlig Coordinator-förklaring där kontakt inte förväxlas med progress, kostnad inte förväxlas med nytta och mätbortfall aldrig blir noll.