Matrix Publishing System

PUB-USECASE-001use-case-briefsStatus: internal-reviewReview: currentTak: supported-with-gapRevisionslås: matrix-lock.json

Prioriterade användningsfall för Matrix

Ett use case är supported först när en målroll kan genomföra hela vägen med verifierad yta och evidens. Nedan skiljs produktmål, landad mekanik och verifierat utfall.

UC-A — Förstå konsekvensen av en uppgradering

Aktör: lösningsarkitekt eller kundansvarig.
Trigger: en produkt- eller API-version ska ändras.
Problem: beroenden finns utspridda i dokument, overlays, avtal och personkunskap.

Huvudflöde: välj targetrevision och scope; fråga grafen; granska valda och alternativa vägar; kontrollera stale/missing producers; skapa förändringsplan; simulera; lämna till mänsklig grind.

Resultat: ett revisionsbundet beslutunderlag med berörda objekt, kunder, kontrakt, unknowns och verifieringsplan. En graf utan source/coverage räcker inte.

Mognad: graf-, package- och impactmekanik finns i delar; den sammanhållna användarvägen är koncept.

UC-B — Upptäck kundpåverkan före kunden

Aktör: operatör eller serviceägare.
Trigger: avvikelse i ett tvärsystemflöde.
Problem: komponenter är gröna men verksamhetsobjekt saknar verifierat slutläge.

Huvudflöde: välj process och tidsfönster; jämför expected population med observationer; visa var kedjan bryts; klassificera unknown kontra fel; öppna evidens; föreslå verifierbar åtgärd.

Resultat: kundpåverkan uttrycks i verksamhetsobjekt och färskhet, inte bara CPU eller endpointstatus.

Mognad: UI är koncept och datakällor är inte anslutna. Use caset behöver en verklig pilot med outcome-källa.

UC-C — Skapa och granska en xECM-konfiguration

Aktör: leveransarkitekt eller konsult.
Trigger: ett kundscenario ska skapas eller uppgraderas.
Problem: konfiguration, struktur, dokumentinnehåll, ACL och recordsregler har olika källor och ändringstakt.

Huvudflöde: välj profil och fixtures; generera manifest och projektion; granska manuellt blueprint; kör apply-plan/dry-run; öppna struktur och JSON; lös coveragegap; lämna versionerad artefakt till delivery.

Resultat: reproducerbar plan med expected population och exakta artefakter. Genererad JSON förblir output och handredigering flyttas till auktoritativ källa.

Mognad: F39-kedjan och NIS dry-run är landade. Generell ConfigurationRelease, cross-scenario-portfölj, live apply och selektiv rollback är målbild (CLAIM-ACTION-011).

UC-D — Följ Coordinator och agentflottan

Aktör: agentansvarig eller plattformsoperatör.
Trigger: arbete fastnar, kapacitet saknas eller kontrollväg avviker.

Huvudflöde: öppna demand/supply; skilj work item, attempt, run och stage; jämför heartbeat med progress; granska lease och redispatch; öppna reviewer, findings och enforcement; kontrollera service-passport.

Resultat: operatören ser nästa säkra handling utan att tolka RUNNING som framgång. Om produktionswriters saknar progressmarkörer visas “progress ej observerad” (CLAIM-AGENT-017).

Mognad: flera kontrollmekanismer är landade men enforcement och passports har tydliga repo-/service-/DONE-vägsgränser.

UC-E — Elicitera verksamhetskunskap utan att skriva om utsagan

Aktör: processledare, arkitekt och informant.
Trigger: en process eller regel behöver dokumenteras.

Huvudflöde: starta session; håll transcript separat från atomära claims; föreslå frågor; flagga utmaningar utan att ändra originalet; bedöm mättnad; spela tillbaka och fatta beslut; avsluta med retention-/exportkontrakt.

Resultat: informantens utsaga, agentens analys och beslutet är separata artefakter.

Mognad: motor, fasgrindar och datamodell finns, men någon verifierad slutanvändarväg har inte demonstrerats. Capability är inte samma sak som supported use case (CLAIM-VALUE-010).

UC-F — Förbered gransknings- och revisionsunderlag

Aktör: revisor, säkerhetsansvarig eller systemägare.
Trigger: ett beslut, en release eller kontrollperiod ska granskas.

Huvudflöde: välj scope och period; följ regel→mandat→plan→dom→handling→ receipt→read-back; visa supersessions, waiver, missing evidence och enforcementcoverage; exportera revisionsbundet paket.

Resultat: granskningskedjan anger både bevis och luckor. Avsaknad av fyndrad är inte bevis för frånvaro av problem.

Mognad: audit- och claimsdelar finns; sammanhållen produktvy och exportpaket är koncept.

Gemensamt acceptanskriterium

Varje use case behöver innan “supported”:

namngiven målroll och autentiserad ingress,
komplett start-till-slut-väg,
versionsbundet input- och outputkontrakt,
tydliga human gates,
expected population och coverage,
verifierad postcondition eller explicit unknown,
dokumenterad failure/recovery-väg,
minst en verklig observation utan demodata,
ägare, supportintervall och mätkontrakt.

Spårbarhet

CLAIM-PLATFORM-001, CLAIM-ACTION-006, CLAIM-AGENT-017, CLAIM-VALUE-010, CLAIM-ACTION-011.

Visuella referenser

Från ändringsscenario till beslutbar konsekvensbedömning

Från arbete via eventdriven review till förklarad landning

Driftbild med belagd kundpåverkan och explicit okänt

Landskapsfråga med graf, träffar och konsekvenskedja

Design Studio med landad F39-kedja och markerad produktmålbild

Arbetsöversikt med separata lifecycle-, readiness-, runtime- och stageaxlar