bmc_hub/fremtidige planer/eskaleringsplan-drift.md

# PLAN – Eskaleringsplan / Drift i BMC Hub

> **Status: Fremtidig plan – ikke implementeret.**
>
> Denne plan er en udvidelse af den eksisterende Drift-funktion. Den må ikke
> fjerne, omdøbe eller ændre eksisterende Drift-adfærd uden udtrykkelig,
> bagudkompatibel migrering.

## 1. Formål

Der skal bygges et nyt modul i **The Hub**, som styrer:

- overvågning af kunders og BMC's driftsressourcer
- eskaleringsplaner
- fejlsituationer og driftsalarmer
- automatisk analyse af hvilke dele af infrastrukturen der sandsynligvis er berørt
- oprettelse af driftssager
- maintenance mode
- forslag til kundekommunikation
- intern eskalering
- SLA-regler
- historik og dokumentation

Systemet skal ikke kun vise, **at noget er nede**.

Det skal også kunne forklare:

> Hvad er nede?  
> Hvem er berørt?  
> Hvor tror vi fejlen ligger?  
> Hvorfor tror systemet det?  
> Hvad skal vi gøre nu?  
> Hvem skal kontaktes?  
> Må vi selv fejlrette?  
> Kræver noget godkendelse?  
> Skal kunden informeres?

---

# 2. Placering i Hub

Under kundens stamdata oprettes et nyt, selvstændigt faneblad:

**Eskaleringsplan**

Fanen supplerer den eksisterende **Drift**-fane. Drift-fanen bevarer dens
nuværende alarmoversigt og historik. Den nye fane viser og administrerer kun
eskaleringsplanens ressourcer, flows, SLA, kontaktregler, godkendelser og
historik for eskaleringer.

Herfra skal man kunne se kundens:

- driftsressourcer
- overvågede devices
- services
- eskaleringsflows
- kontaktpersoner
- kommunikationsregler
- SLA-regler
- godkendelsesregler
- aktuelle og tidligere driftsproblemer

Men selve en driftsressource må **ikke nødvendigvis eje én kunde**.

En internetforbindelse, switch, firewall eller anden ressource kan være delt mellem flere kunder.

---

# 3. Driftsressourcer

Der skal oprettes et generelt objekt:

`Driftsressource`

Eksempler:

- Internetforbindelse
- Gateway
- Firewall
- Switch
- Access Point
- Server
- VM
- Hosting cluster
- UPS
- WAN
- LAN
- Kundens router
- SaaS-service
- VPN
- DNS
- Microsoft 365
- Datacenter
- Bygning
- Etage
- Netværkssegment

En ressource skal kunne tilknyttes:

- én eller flere kunder
- andre driftsressourcer
- en eller flere overvågningskilder
- kontaktpersoner
- services
- eskaleringsplaner

---

# 4. Ressourcehierarki

Driftsressourcer skal kunne forbindes hierarkisk.

Eksempel:

```text
Internetforbindelse
        │
        ▼
     Gateway
     /     \
    ▼       ▼
Switch 1   Switch 2
    │         │
    ▼         ▼
Bygning 1  Bygning 2
    │
 ┌──┴─────┐
 ▼        ▼
Kunde A   Kunde B
```

Dette hierarki bruges til at analysere, **hvor fejlen sandsynligvis ligger**.

---

# 5. Visuel eskalerings-/flow-builder

Eskaleringsplanen skal bygges grafisk.

Det skal ligne eksempelvis:

- Power Automate
- Node-RED
- n8n
- workflow builder

Brugeren skal kunne trække blokke ind på et canvas og forbinde dem.

Eksempel:

```text
[Internet nede]
       |
       v
[Gateway oppe?]
   /          \
 JA            NEJ
 |              |
 v              v
[Check        [Mistanke:
Switches]      udbyder]
 |
 v
[Switch 1 oppe?]
 /          \
NEJ          JA
|             |
v             v
Bygning 1     Check næste gren
berørt
```

---

# 6. Typer af blokke i flow-builderen

Systemet skal bl.a. have følgende node-typer:

### Trigger

Eksempel:

```text
Device bliver DOWN
```

eller:

```text
Internetforbindelse bliver DOWN
```

### Statuscheck

Eksempel:

```text
Er Gateway-01 UP?
```

### Kombination

Eksempel:

```text
Gateway = UP
OG
Switch-01 = DOWN
OG
Switch-02 = UP
```

### Timer

Eksempel:

```text
Har forbindelsen været nede i 15 minutter?
```

### Impact

Eksempel:

```text
Markér Bygning 1 som berørt
```

### Intern handling

Eksempel:

```text
Opret driftssag
```

### Intern notification

Eksempel:

```text
Send SMS til driftsteam
```

### Godkendelse

Eksempel:

```text
Kræver kundens godkendelse før hardwareudskiftning
```

### Kommunikation

Eksempel:

```text
Foreslå driftsbesked
```

**Må aldrig automatisk sende besked til kunden.**

---

# 7. Overvågningsintegrationer

Eksisterende integrationer, der allerede leverer Drift-events, skal fortsætte
uændret. Første nye integrationer eller udvidelser:

### Uptime Kuma

Bruges eksempelvis til:

- ping
- HTTP
- TCP
- serverstatus
- internetforbindelser
- gateway-status

### UniFi

Bruges eksempelvis til:

- gateways
- switches
- access points
- sites
- internetstatus
- device-status

Den eksisterende UISP-integration bevares som en separat eksisterende kilde;
UniFi tilføjes uden at ændre UISP- eller Uptime Kuma-events, deres synkronisering
eller deres nuværende visning.

Arkitekturen skal være generisk, så senere integrationer kan tilføjes, eksempelvis:

- Prometheus
- UISP
- PRTG
- Zabbix
- SNMP
- Azure Monitor
- Microsoft Graph
- VMware
- Proxmox
- custom API

Overvågningssystemerne skal primært levere **events og status**.

Hubben skal selv afgøre, hvad eventet betyder.

---

# 8. Eksempel – internetforbindelse

Antag:

```text
Internet
   │
Gateway
   │
 ┌─┴─────────┐
 │           │
Switch 1   Switch 2
 │           │
Bygning 1  Bygning 2
```

Hvis:

```text
Internet monitor = DOWN
Gateway = UP
Switch 1 = DOWN
Switch 2 = UP
```

kan Hub konkludere:

```text
Internetforbindelsen er sandsynligvis OK.

Problemet ser ud til at være omkring:
Bygning 1 / Switch 1.
```

Det betyder ikke nødvendigvis:

> Switch 1 er defekt.

Systemet skal i stedet kunne skrive:

> Fejlen er lokaliseret til området omkring Switch 1 / Bygning 1.

Mulige årsager kunne være:

- switch
- strøm
- fiber/kabel
- uplink
- lokalt netværk

---

# 9. Eksempel – kun én kunde berørt

Hvis:

```text
Gateway = UP
Switch = UP
Kunde A router = DOWN
Kunde B router = UP
Kunde C router = UP
```

skal Hub kunne konkludere:

```text
Fejlen ser ud til kun at påvirke Kunde A.
```

Systemet må ikke automatisk konkludere, at BMC's udstyr er defekt.

---

# 10. Hvorfor-visning

Dette er en vigtig funktion.

Når Hub har vurderet et problem, skal teknikeren kunne trykke:

**Hvorfor?**

Så vises hele beslutningsstien.

Eksempel:

```text
07:42 Internet monitor: DOWN

07:42 Gateway-01: UP

07:42 Switch-B1: DOWN

07:42 Switch-B2: UP

07:43 Router Kunde A: DOWN

07:43 Router Kunde B: DOWN

--------------------------------

Regel:
Gateway UP
+
Switch B1 DOWN
+
Switch B2 UP

Resultat:
Sandsynligt problem i Bygning 1.
```

Den aktive vej gennem diagrammet skal visuelt markeres.

Eksempel:

```text
Internet DOWN
      ↓
Gateway UP ✓
      ↓
Switch B1 DOWN ✕
      ↓
Bygning 1 berørt
```

---

# 11. Systemets sikkerhed omkring konklusioner

Hub må gerne lave en teknisk vurdering.

Men der skal skelnes mellem:

**Observeret**

og

**Vurderet**

Eksempel:

```text
Observeret:
Switch B1 svarer ikke.

Vurdering:
Fejlen ser ud til at være lokaliseret til Bygning 1.
```

Ikke:

```text
Switch B1 er defekt.
```

medmindre det faktisk kan konstateres.

---

# 12. Driftssag / Eskaleringssag

Når et relevant flow trigges, skal Hub kunne:

```text
Opret driftssag
```

Driftssagen kan være:

- automatisk oprettet
- manuelt oprettet

Den skal indeholde:

- starttidspunkt
- berørte ressourcer
- berørte kunder
- berørte services
- nuværende status
- severity
- eskaleringsplan
- ansvarlig
- events
- timeline
- vurderet årsag
- hvorfor-visning
- SLA
- notifications
- kundekommunikation
- maintenance status

---

# 13. Severity

Forslag:

```text
INFO
WARNING
MAJOR
CRITICAL
```

Eksempel:

BMC Hostingcenter nede:

```text
CRITICAL
```

En enkelt AP hos en kunde:

```text
WARNING
```

Severity skal kunne defineres i flow-builderen.

---

# 14. BMC's egen hosting

BMC's egen infrastruktur skal kunne have meget aggressive eskaleringsplaner.

Eksempel:

```text
Hosting cluster DOWN
        ↓
CRITICAL
        ↓
Opret driftssag
        ↓
SMS til alle relevante medarbejdere
        ↓
Push notification
        ↓
Start eskaleringsplan straks
```

Det må godt ske automatisk internt.

Begrænsningen omkring manuel godkendelse gælder **kundekommunikation**.

---

# 15. SLA

Eskaleringsplaner skal understøtte SLA.

Eksempel:

```text
0 min:
Registrér event

5 min:
Verificér fejlen

15 min:
Opret driftssag

30 min:
Kontakt ansvarlig

60 min:
Eskalér til senior tekniker

4 timer:
SLA-grænse
```

Der skal kunne være:

- responstid
- løsningstid
- tidsfrister
- advarsler
- escalation deadlines

---

# 16. Godkendelsesregler

Under kunden skal det være muligt at definere:

```text
Må BMC fejlrette uden godkendelse?
JA / NEJ
```

Eksempel:

```text
Fejlsøgning:
Tilladt

Genstart:
Tilladt

Firmware-opdatering:
Kræver godkendelse

Hardwareudskiftning:
Kræver godkendelse

Omkostninger over 2.500 kr:
Kræver godkendelse
```

Der skal kunne angives hvem der må godkende.

---

# 17. Kontaktpersoner og driftstilmelding

Kontaktpersoner skal kunne abonnere på drift.

Ikke kun:

```text
Kunde A
```

men også eksempelvis:

```text
Internetforbindelse 047
```

eller:

```text
Bygning 1
```

eller:

```text
Office 365
```

eller:

```text
Hovedkontorets netværk
```

En kontakt kan dermed være tilmeldt flere driftsressourcer.

---

# 18. Delte forbindelser

En internetforbindelse kan være delt mellem flere kunder.

Eksempel:

```text
Internetforbindelse #1028
```

benyttes af:

```text
Kunde A
Kunde B
Kunde C
Kunde D
```

Hub skal derfor kunne beregne:

```text
Berørte kunder: 4

Potentielle modtagere: 12
```

---

# 19. Impact engine

Systemet skal kunne beregne påvirkningen ud fra diagrammet.

Eksempel:

```text
Internetforbindelsen
        ↓
Gateway
        ↓
Switch Bygning 1
        ↓
Kunde A
Kunde B
Kunde C
```

Hvis Switch Bygning 1 går ned:

```text
Berørt:
Kunde A
Kunde B
Kunde C

Ikke berørt:
Kunde D
Kunde E
```

---

# 20. Driftsbeskeder

Fra en driftssag skal der være:

**Generér driftsbesked**

Hub kan automatisk foreslå:

- modtagere
- emne
- tekst
- hvilke kunder der er berørt
- hvilken bygning/service der er berørt
- kendt status

Men:

# Kundekommunikation må ALDRIG sendes automatisk.

Der skal altid være et menneskeligt klik:

```text
GODKEND OG SEND
```

---

# 21. AI / automatisk tekstforslag

Hub kan eksempelvis foreslå:

```text
Driftsforstyrrelse – Bygning 1

Vi oplever i øjeblikket problemer med netværksforbindelsen
i Bygning 1.

Vores overvågning viser, at øvrige dele af forbindelsen
fungerer normalt, og problemet ser derfor ud til at være
lokaliseret til netværket i Bygning 1.

Vi undersøger fejlen og sender en ny status, når der er
yderligere information.
```

Brugeren kan redigere teksten før udsendelse.

---

# 22. Beskedtyper

Systemet bør have mindst:

```text
Driftsforstyrrelse

Opdatering

Planlagt vedligehold

Forlænget nedetid

Drift normaliseret
```

---

# 23. Foreslå kommunikation

Flow-builderen skal kunne have en node:

```text
Foreslå kundekommunikation
```

Eksempel:

```text
Hvis nedetid > 15 minutter
        ↓
Foreslå driftbesked
```

Dette åbner eksempelvis:

```text
Der er 17 relevante modtagere.

Vil du oprette en driftsbesked?
```

Ikke automatisk sende den.

---

# 24. Maintenance mode

Der skal være en sagstype:

```text
Drift / Vedligehold
```

I sagen kan man vælge:

```text
Sæt devices i maintenance
```

Eksempel:

```text
Gateway-01
Switch-01
Switch-02
AP-01
```

Mens sagen er aktiv:

```text
Maintenance = aktiv
```

Når sagen lukkes:

```text
Maintenance = automatisk fjernet
```

---

# 25. Maintenance slutdato

Ved maintenance kan man sætte:

```text
Start:
24-09-2026 22:00

Forventet slut:
25-09-2026 01:00
```

Hvis maintenance stadig er aktiv efter sluttidspunktet:

```text
ADVARSEL

Maintenance skulle være afsluttet for 38 minutter siden.
```

---

# 26. Events under maintenance

Events skal ikke slettes.

Hvis et device går ned under maintenance:

```text
Event registreret
```

men eksempelvis:

```text
Alarm undertrykt:
Device er i maintenance via sag #1842
```

Så historikken stadig er komplet.

---

# 27. Kritiske undtagelser

Nogle alarmer må aldrig ignoreres under maintenance.

Eksempel:

```text
UPS batterifejl

Brandalarm

Temperatur kritisk

Hosting cluster helt nede
```

De kan markeres:

```text
Ignore maintenance = YES
```

---

# 28. Timeline

Driftssagen skal have én samlet timeline.

Eksempel:

```text
07:41 Uptime Kuma meldte Internet DOWN

07:42 Hub kontrollerede Gateway-01

07:42 Gateway-01 svarede

07:42 Switch-B1 svarede ikke

07:42 Switch-B2 svarede

07:43 Hub vurderede:
Problem sandsynligvis Bygning 1

07:44 Driftssag #1932 oprettet

07:46 Christian åbnede sagen

07:48 Driftsbesked genereret

07:49 Driftsbesked godkendt af Christian

07:50 14 modtagere informeret
```

---

# 29. Audit log

Alle automatiske beslutninger skal kunne spores.

Gem eksempelvis:

```text
regel-id
regel-version
input-data
status på devices
resultat
beslutningssti
timestamp
handlinger
brugerhandlinger
```

Det skal være muligt bagefter at forstå præcis:

> Hvorfor gjorde Hub dette?

---

# 30. Overstyring

Teknikeren skal kunne overstyre systemets vurdering.

Eksempel:

Hub siger:

```text
Mistanke: Netværk Bygning 1
```

Tekniker kan ændre til:

```text
Bekræftet årsag:
Fiberbrud mellem hovedbygning og Bygning 1
```

Den oprindelige automatiske vurdering skal dog stadig gemmes i historikken.

---

# 31. Skabeloner

Der skal kunne bygges templates.

Eksempel:

```text
Standard internetkunde

Standard UniFi-site

Delt erhvervsforbindelse

Hostingkunde

Microsoft 365 kunde
```

Ved oprettelse af ny kunde kan man eksempelvis vælge:

```text
Anvend:
Standard internetkunde
```

og derefter blot tilknytte de rigtige devices.

---

# 32. Regelversionering

Hvis en eskaleringsplan ændres, må historiske driftssager ikke ændre sig.

Eksempel:

```text
Eskaleringsplan v3
```

blev brugt på hændelsen.

Selv hvis planen senere bliver v4, skal sagen stadig kunne vise den regelversion, der faktisk blev brugt.

---

# 33. Systemarkitektur

Overvågningskilder bør sende normaliserede events til Hub.

Eksempel:

```json
{
  "source": "uptime_kuma",
  "resource_id": 812,
  "event": "down",
  "timestamp": "...",
  "metadata": {}
}
```

Hub behandler eventet gennem:

```text
Monitoring Event
      ↓
Resource Mapping
      ↓
Escalation Engine
      ↓
Impact Engine
      ↓
Rule Flow
      ↓
Actions
```

---

# 34. Central event-model

Hub skal ikke være afhængig af et bestemt overvågningssystem.

Normaliser eksempelvis status til:

```text
UP
DOWN
DEGRADED
UNKNOWN
MAINTENANCE
```

Så samme flow kan bruge:

```text
Uptime Kuma
UniFi
Prometheus
UISP
andet
```

---

# 35. UI – kundens stamdata

Fanen:

```text
Eskaleringsplan
```

kunne have undermenuerne:

```text
OVERSIGT
RESSOURCER
FLOW
KONTAKTER
SLA
GODKENDELSER
HISTORIK
```

---

# 36. UI – live flow

Når en driftssag er aktiv, skal diagrammet kunne vises live.

Eksempel:

```text
          [Internet DOWN]
                 ↓
            [Gateway]
              UP ✓
                 ↓
        ┌────────┴────────┐
        ↓                 ↓
 [Switch B1]        [Switch B2]
    DOWN ✕               UP ✓
        ↓
 [BYGNING 1]
    BERØRT
```

Aktive nodes skal fremhæves.

Teknikeren skal kunne klikke på en node og se:

```text
Status
Sidste check
Datakilde
Device
Regel
Resultat
```

---

# 37. Drift dashboard

På Hub's eksisterende **Drift**-side bør aktive eskaleringssager vises.

Eksempel:

```text
CRITICAL  1
MAJOR     2
WARNING   4
```

Kort kan eksempelvis vise:

```text
Norva24

Netværk – Bygning 1

Start: 07:42
Varighed: 28 min

3 kunder berørt
14 kontaktpersoner

Mistanke:
Lokalt netværk Bygning 1
```

---

# 38. MVP – første version

Første version bør fokusere på:

```text
Driftsressourcer

Kunde ↔ ressource relationer

Delte ressourcer

Uptime Kuma integration

UniFi integration

Visuel flow-builder

UP/DOWN conditions

AND / OR conditions

Tidsbetingelser

Opret driftssag

Impact analyse

Hvorfor-visning

Timeline

Maintenance mode

Kontaktperson ↔ driftsressource

Generér driftsbesked

MANUEL godkendelse og send

Audit log
```

---

# 39. Version 2

Efter MVP:

```text
Avancerede SLA-regler

SMS

Push

Telefoneskalering

Webhook actions

Flere overvågningssystemer

AI-genereret statusbesked

Automatisk root-cause forslag

Dependencies mellem services

Service maps

Statistik

Rapportering

SLA-performance
```

---

# 40. Absolutte regler

Disse regler skal overholdes:

**1. Kundebeskeder må aldrig sendes automatisk.**

Hub må:

```text
foreslå besked
foreslå modtagere
generere tekst
```

men et menneske skal altid godkende udsendelsen.

**2. Automatiske vurderinger skal kunne forklares.**

Man skal altid kunne se:

```text
Hvorfor nåede systemet frem til dette resultat?
```

**3. Observation og konklusion skal adskilles.**

Eksempel:

```text
Observation:
Switch svarer ikke.

Vurdering:
Problemet ser ud til at være lokaliseret omkring switchen.
```

**4. En driftsressource kan deles af flere kunder.**

**5. Alle beslutninger og ændringer skal logges.**

**6. Arkitekturen må ikke være låst til Uptime Kuma eller UniFi.**

---

# 41. Eksempel på komplet hændelse

```text
07:40
Internet monitor melder DOWN.

07:41
Gateway responderer stadig.

07:41
Hub følger eskaleringsdiagrammet.

07:41
Switch Bygning 1 = DOWN.

07:41
Switch Bygning 2 = UP.

07:42
Hub beregner impact.

Berørt:
Kunde A
Kunde B
Kunde C

Ikke berørt:
Kunde D
Kunde E

07:42
Hub vurderer:

"Problemet ser ud til at være lokaliseret til
netværket i Bygning 1."

07:42
Driftssag oprettes.

07:43
Teknikeren kan åbne "Hvorfor?"

Internet DOWN
→ Gateway UP
→ Switch B1 DOWN
→ Switch B2 UP
→ Bygning 1 berørt

07:45
Hub foreslår:

"Der er 8 kontaktpersoner tilmeldt de berørte
driftsressourcer.

Opret driftsbesked?"

Teknikeren trykker JA.

Hub genererer teksten.

Teknikeren retter evt. teksten.

Teknikeren trykker:

GODKEND OG SEND
```

---

# 42. Målet

Det færdige system skal gøre, at en tekniker ved en alarm ikke kun ser:

> Device DOWN

men i stedet får:

```text
HVAD SKER DER?

Netværksproblem Bygning 1


HVEM ER BERØRT?

3 kunder
8 kontaktpersoner


HVORFOR TROR HUB DET?

Gateway = UP
Switch B1 = DOWN
Switch B2 = UP


HVAD SKAL VI GØRE?

1. Kontrollér Switch B1
2. Kontrollér uplink
3. Kontakt onsite person hvis nødvendigt


KRÆVER DET GODKENDELSE?

Fejlsøgning: NEJ
Hardwareudskiftning: JA


KUNDEN INFORMERET?

NEJ

[ GENERÉR DRIFTSBESKED ]
```

Det er den retning, jeg ville bygge hele **Eskaleringsplan / Drift**-funktionen efter.

---

# 43. Sameksistens og bagudkompatibilitet – bindende krav

## 43.1 Eksisterende Drift-funktioner

Følgende skal bevares under hele implementeringen:

- Drift-siden med aktive alarmer, filtre, tællere og alarmhistorik
- kundens eksisterende fane **Drift**
- Uptime Kuma- og UISP-events og deres synkronisering
- eksisterende monitor-til-kunde-koblinger
- blacklist af driftsenheder
- godkendelse af alarmer
- eksisterende oprettelse og sammenkædning af sager fra driftsevents
- eksisterende API-endpoints og deres svar til nuværende klienter

Den nye fane **Eskaleringsplan** må ikke erstatte eller omdøbe Drift-fanen.

## 43.2 Data og migrering

Nye driftsressourcer, ressourceforbindelser, eskaleringsflows og abonnements-
relationer oprettes som nye tabeller eller additive felter. De eksisterende
`drift_events`, `drift_devices`, `drift_customer_mappings` og links til sager
må ikke slettes, nulstilles eller have betydning ændret.

En eksisterende monitor-kobling til én kunde skal fortsat virke. Delte
ressourcer modelleres i den nye ressource-relation, så én ressource kan have
flere kunder uden at ændre betydningen af den eksisterende monitor-kobling.

Alle migreringer skal være additive og reversible. Før produktionsmigrering
skal der være en læseprøve, som dokumenterer antal eksisterende events,
mappings, blacklists og sagslinks før og efter migreringen.

## 43.3 Status og API-kompatibilitet

Den eksisterende Drift-statusmodel fortsætter uændret for eksisterende
endpoints og skærme. Den nye eskaleringsmotor kan arbejde med normaliserede
observationer som `UP`, `DOWN`, `DEGRADED`, `UNKNOWN` og `MAINTENANCE`, men
skal oversætte dem ved grænsen til den eksisterende Drift-model.

Eksisterende filtrering, tællere og historik må derfor fortsat forstå aktive,
løste og godkendte alarmer. Nye API’er lægges under nye endpoints; eksisterende
Drift-endpoints ændres ikke i første version.

## 43.4 Sager og maintenance

Når et flow opretter en driftssag, skal det genbruge den eksisterende
sag-oprettelse og bevare linket mellem driftsevent og sag. En ny eskaleringssag
må have ekstra metadata om ressourcer, impact, flow-version og beslutningssti,
men må ikke miste sagens kunde, status, historik eller eksisterende sagslinks.

Maintenance på ressourcer er en ny, sagstyret undertrykkelse af eskalerings-
handlinger. Den holdes helt adskilt fra Hubs eksisterende system-maintenance.
Ressource-maintenance må ikke ændre systemets maintenance-status, og system-
maintenance må ikke automatisk ændre en ressources maintenance.

## 43.5 Implementeringsrækkefølge

1. Kortlæg og test eksisterende Drift-data, endpoints og visninger.
2. Tilføj den additive ressource- og relationsmodel uden at ændre eksisterende
   Drift-data.
3. Tilføj fanen **Eskaleringsplan** under kunden.
4. Tilføj læsning, impact, audit og hvorfor-visning.
5. Tilføj flow-handlinger og sag-oprettelse med dubletbeskyttelse.
6. Tilføj resource-maintenance og kundekommunikationsforslag.

Hver fase frigives først, når eksisterende Drift-visning, events,
monitor-koblinger og sagslinks er verificeret uændrede.