# XinionOS ist ein eigener Strang — was das heißt

**Beschlossen am 19.09.2026 vom CIO.** XinionOS hat seit diesem Tag eine eigene Organisation im Git
und einen eigenen Bereich in Confluence. Es ist nicht mehr Teil des Vorhabens XinionONE, sondern
dessen **Lieferant**.

## Warum

**XinionOS ist die Grundlage künftiger Appliance-Ideen, nicht der Unterbau eines einzelnen
Produkts.** Eine Geräteschicht, die entlang der Bedürfnisse *einer* Nutzlast entsteht, passt der
zweiten nicht — und genau dieser Fehler hat den ersten Anlauf von XinionONE gekostet, dort eine
Ebene höher.

**Zwei Abnehmer stehen bereits fest:** XinionONE und GAIA. Das ist keine Plattform mit einem Kunden,
die so tut, als hätte sie mehrere.

**Und die Regulierung trennt sie ohnehin.** XinionOS fällt als Betriebssystem unter Anhang III
Klasse I der Verordnung (EU) 2024/2847, XinionONE voraussichtlich als Netzmanagementsystem — zwei
Konformitätswege, zwei Stücklisten, zwei Unterstützungszeiträume. Gekoppelt wäre das eine
Vermischung, die spätestens beim ersten Audit auffällt.

## Die Grenze, an der es hängt

> **Eine Anforderung ist ein Bedarf, keine Lösung.**

| ❌ So nicht | ✅ So |
|---|---|
| *„Verwendet systemd-boot mit diesen Registern"* | *„Das Gerät kehrt nach einem fehlgeschlagenen Update ohne anwesenden Menschen auf den vorigen Stand zurück"* |

Das Erste ist eine Entscheidung vom Stuhl des Abnehmers aus. Das Zweite ist ein Bedarf, den XinionOS
erfüllen kann, wie es für richtig hält.

**Das Anforderungsregister gehört diesem Strang, nicht den Abnehmern** — mit einer Spalte, wer
fordert. Sonst müsste XinionOS zwei Kundendokumente lesen, um zu wissen, was erwartet wird, und bei
einem dritten drei.

## Was von der alten Arbeit gilt

Diese Ablage ist am 19.09.2026 aus dem Archiv zurückgeholt worden: 13 Commits, sieben
Architekturentscheidungen, der Abbildbau.

**Und hier gilt mehr weiter als anderswo.** Am 13.09.2026 wurde bei XinionONE die grüne Wiese
ausgerufen, weil das Produktbild falsch war. **Die Entscheidungen von XinionOS stammen nicht aus
diesem Bild, sondern aus Physik und Feld:**

> *Ein Gerät, das beim Kunden im Rack steht und nach einem Update nicht mehr hochkommt, ist ein
> Vor-Ort-Einsatz — bei zweihundert Geräten zweihundert davon.*

A/B-Wurzel, Rücksprung, Verschlüsselung, kein Auslagerungsspeicher, der Installationsdialog, der
Konsolenbereich: Das gilt unverändert, gleich welche Nutzlast darauf läuft. **Eine der sieben
beschreibt sogar genau diese Entkopplung** — eine Laufzeitschicht für alle Nutzlasten, GAIA als
Profil darauf.

**Zu prüfen ist nur, wo eine Entscheidung XinionONE beim Namen nennt.** Solche Stellen werden zu
Anforderungen eines Abnehmers umformuliert, nicht gestrichen.

## Was offen ist

* **Das Konzept** entsteht im eigenen Confluence-Bereich, nicht als Abschnitt eines fremden.
* **Wer entscheidet, wenn zwei Abnehmer sich widersprechen.** Heute der CIO — es gehört
  hingeschrieben, denn das bricht als Erstes, sobald ein Termin auftaucht.
* **Wer daran arbeitet.** Der Arbeitsplatz steht seit dem 02.09.2026 bereit und wurde nie benutzt.
  **Entkopplung schafft keine Kapazität.**

---

*Angelegt am 19.09.2026 beim Umzug in die eigene Organisation. Wiederhergestellt aus
`XinionONE/archive`, Bündel `xinionos.bundle`.*