xinionos/docs/decisions/ADR-0005-geraeteschicht-aller-verkaufsvarianten.md

# ADR-0005 — XinionOS ist die Geräteschicht aller Verkaufsvarianten; GAIA Lite wird Nutzlast

**Stand:** Angenommen, 21.08.2026 · **Entscheidet:** CIO Thomas Reitz
**Berührt:** `Projekt OLYMPUS` — dessen Schichtenmodell führt GAIA Lite als Layer 2 der
Verkaufsvariante. Diese Rolle geht auf XinionOS über.

---

## Worum es geht

Zwei Vorhaben im Haus liefern ein Gerät an einen Kunden aus, und beide haben sich unabhängig
voneinander dieselbe Schicht gebaut.

**OLYMPUS** beschreibt seine Verkaufsvariante als ISO auf Kundenhardware: GAIA Lite als Unterbau,
k3s mit CORE- und WRK-Rollen, Bootstrapping über eine Deployment-Weboberfläche, Single-Tenant.
**XinionOS** beschreibt genau dasselbe: ein Abbild, das installiert wird, sich selbst prüft, sich
aktualisieren lässt und im Fehlerfall zurückspringt — mit Konsolenmenü, Einrichtungsassistent und
Basisoberfläche.

Nebeneinander gelesen ist das **zweimal dasselbe Gerüst**: ISO-Auslieferung, Installation,
Ersteinrichtung über eine Weboberfläche, Aktualisierung, Geräteverwaltung. Der Unterschied liegt
nicht in der Aufgabe, sondern darin, dass zwei Vorhaben sie zu verschiedenen Zeitpunkten für sich
gelöst haben.

## Die Entscheidung

**XinionOS ist die Geräteschicht jedes Xinion-Erzeugnisses, das beim Kunden als Gerät steht.
GAIA Lite hört auf, ein Auslieferungsweg zu sein, und wird zu einer Nutzlast auf XinionOS.**

Damit ersetzt XinionOS **nicht OLYMPUS**, sondern genau den Teil, den OLYMPUS nach unten
weggeschnitten hatte, ohne dass es dafür einen Träger gab.

| Aufgabe | Bisher | Künftig |
|---|---|---|
| ISO bauen und ausliefern | GAIA Lite | **XinionOS** |
| Installation am Blech | GAIA Lite | **XinionOS** (Stufe 0) |
| Ersteinrichtung über Weboberfläche | Deployment-WebUI | **XinionOS** (Stufe 2) |
| Notfallzugang ohne Netz | fehlte | **XinionOS** (Konsolenmenü, Stufe 1) |
| Fassungswechsel und Rücksprung | offen | **XinionOS** (A/B-Wurzel, Selbstprüflauf) |
| Verschlüsselung, sichere Löschung | offen | **XinionOS** (`ADR-0003`) |
| k3s, PostgreSQL, Storage, Secrets, Ingress, IdP — der **Plattform-Vertrag** | GAIA Lite | **GAIA Lite, als Nutzlast** |
| Shell, Auth, Mandantenfähigkeit, Registry, Gateway, Shared Services, Lizenzierung | OLYMPUS | **OLYMPUS, unverändert** |
| Die Anwendungen | INSIGHT, COSMOS, ORION-WebUI | **unverändert** |

**OLYMPUS und die Anwendungen merken davon nichts.** Sie konsumieren Layer 2 weiterhin
ausschließlich über den Plattform-Vertrag; welcher Träger ihn erfüllt, ist genau die
Austauschbarkeit, die OLYMPUS selbst festgeschrieben hat.

## Warum

**Der Cyber Resilience Act rechnet in Erzeugnissen, nicht in Vorhaben.** Zwei Basissysteme sind
zwei Stücklisten, zwei Schwachstellenprozesse und zwei Versorgungszusagen über die
Produktlebensdauer — für dieselbe Sache. Das ist die Begründung aus `ADR-0001`, jetzt angewandt auf
einen konkreten zweiten Fall.

**Der Rücksprung wird nur einmal richtig gebaut.** Er wird ausschließlich in dem Moment geprüft, in
dem ihn jemand braucht. Eine zweite handgebaute Umsetzung wäre eine zweite ungeprüfte — und die
fällt erst beim Kunden auf.

**Das Konsolenmenü fehlte auf der anderen Seite ganz.** Eine Deployment-Weboberfläche setzt ein
funktionierendes Netz und einen funktionierenden Webdienst voraus. Was passiert, wenn das Netz
falsch konfiguriert ist, war nicht beantwortet. Die Notfalloberfläche muss den Ausfall dessen
überleben, was sie verwaltet.

**Und es ist keine neue Konstruktion, sondern das Einlösen einer vorhandenen.** Der
Nutzlast-Vertrag ist genau dafür geschnitten; die XinionOS-Seite führt die OLYMPUS-Appliance seit
dem 20.08.2026 als eine von vier Nutzlasten. Diese Entscheidung macht aus einer Absicht eine
Festlegung.

## Was daraus folgt

* **GAIA Lite erfüllt den Nutzlast-Vertrag** — `selbstpruefung`, `nutzlast.target`, `kennung`,
  optional `einrichten`. Der Selbstprüflauf von GAIA Lite entscheidet über den Rücksprung mit:
  Ein k3s, das nicht hochkommt, ist ein misslungener Start und kein grünes Gerät.
* **Ein ISO-Bauweg**, ein Abnahmetest, ein Ersatzteil im Regal.
* **Die Deployment-WebUI von GAIA Lite entfällt** als eigener Baustein. Was von ihr fachlich
  gebraucht wird, gehört in den Einrichtungsassistenten von XinionOS.
* **Zwei Registries und zwei Lizenzmechaniken bleiben bestehen** — die von XinionONE für seine
  Module, die von OLYMPUS für seine Anwendungen. Sie sehen sich ähnlich und liegen trotzdem in
  verschiedenen Nutzlasten. **Sie werden nicht zusammengelegt**, solange nicht jemand nachweist,
  dass sie dasselbe tun.

## Die Auflage, die daraus folgt: Container-Abbilder gehören in die Wurzel

*Nachgetragen am 21.08.2026, nachdem die Frage gestellt wurde, ob GAIA Lite und das Grundmodul der
Appliance dieselbe Schicht sind. Sie sind es nicht — aber die Frage hat eine Lücke in dieser
Entscheidung aufgedeckt.*

`appliance/ADR-0005` hat für die Verpackung der Dienste festgehalten, was hier genauso gilt und
oben fehlte: **Was nicht in der Wurzel liegt, nimmt der Rücksprung nicht mit.** Lägen die Dienste
im Bestandsbereich, träfe nach einem Rücksprung eine alte Wurzel auf eine neue Anwendung.

Für GAIA Lite als Nutzlast heißt das konkret:

| Was | Wohin | Warum |
|---|---|---|
| k3s selbst, alle **Container-Abbilder**, Helm-Bündel, Manifeste | **Wurzel** | Software. Wird mitgetauscht und kommt beim Rücksprung von selbst zurück |
| etcd beziehungsweise die Cluster-Datenbank, persistente Datenträger, Zustand der Anwendungen | **Bestand** | Zustand des Kunden. Überlebt den Fassungswechsel absichtlich |

**Damit gilt für GAIA Lite dieselbe Schemaregel wie für jede andere Nutzlast** (`ADR-0004` der
Appliance): Eine Fassung darf den Zustand nur so ändern, dass die Vorgängerfassung noch damit
arbeiten kann. Ein Rücksprung, der auf einen fortgeschriebenen Cluster-Zustand trifft, ist kein
Rückweg, sondern ein zweiter Ausfall.

**Und es ist eine Abbildgrößen-Frage.** Nach `ADR-0004` bleibt das Abbild klein, weil alles zweimal
auf der Platte liegt — einmal je Wurzel. Ein vollständiger Satz Container-Abbilder für Plattform
und Anwendungen ist kein kleiner Posten. **Was GAIA Lite in die Wurzel legt, ist vor dem ersten
Abbildbau zu beziffern**, nicht danach.

## Was ausdrücklich nicht entschieden ist

* **Ob GAIA Full ebenfalls auf XinionOS läuft.** Diese Entscheidung betrifft nur, was beim Kunden
  als Gerät steht. Im eigenen Rechenzentrum bleibt alles, wie es ist.
* **Wann der Umbau geschieht.** OLYMPUS ist Konzept, XinionOS ist Konzept — hier kollidieren zwei
  Pläne, kein Bestand. Das ist der günstigste Zeitpunkt, den es dafür je geben wird.
* **Der Name.** *CORE* bezeichnet bei OLYMPUS eine k3s-Rolle, bei XinionONE die Bezugsquelle, im
  Namensschema zusätzlich das Grundmodul. Drei Dinge, ein Wort — zu entscheiden, aber nicht hier.

---

*Grundlage: Projekt OLYMPUS, Startseite vom 23.06.2026 (Schichtenmodell, Plattform-Vertrag, die
zwei Ausprägungen) · XinionOS `ADR-0001` bis `ADR-0004` · `nutzlast/VERTRAG.md` ·
Nichts davon ist gebaut — diese Entscheidung ordnet Pläne, sie beschreibt keinen Zustand.*