CIO-Beschluss vom 19.09.2026. XinionOS ist die Grundlage kuenftiger Appliance-Ideen und nicht
der Unterbau eines einzelnen Produkts. Eine Geraeteschicht, die entlang der Beduerfnisse
EINER Nutzlast entsteht, passt der zweiten nicht — genau dieser Fehler hat den ersten Anlauf
von XinionONE gekostet, dort eine Ebene hoeher.
Zwei Abnehmer stehen fest, XinionONE und GAIA. Und die Regulierung trennt sie ohnehin: Anhang
III Klasse I gegen Netzmanagementsystem, zwei Konformitaetswege.
Die Grenze, an der die Entkopplung haengt: Eine Anforderung ist ein Bedarf, keine Loesung.
Und das Anforderungsregister gehoert diesem Strang, nicht den Abnehmern — sonst muesste
XinionOS zwei Kundendokumente lesen, um zu wissen was erwartet wird.
Hier gilt mehr von der alten Arbeit weiter als bei XinionONE: Die sieben Entscheidungen
stammen aus Physik und Feld, nicht aus dem verworfenen Produktbild. Zu pruefen ist nur, wo
eine Entscheidung XinionONE beim Namen nennt — solche Stellen werden zu Anforderungen eines
Abnehmers umformuliert, nicht gestrichen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bei der Durchsicht der Aufbauten in infra aufgefallen: Der Tresor-Pod laeuft mit
disable_mlock. Im Behaelter ist das unvermeidlich und mit eingebautem Speicher vertretbar —
aber nur unter einer Bedingung, die bisher nirgends stand. Ohne Speicherfestnagel darf der
Arbeitsspeicher des Tresors ausgelagert werden, und das ist genau der Speicher mit den
entschluesselten Zugangsdaten aller Zielsysteme des Kunden. Es entstuende eine zweite,
unbewachte Kopie ausserhalb des Tresors, ausserhalb seiner Richtlinien und ausserhalb der
Pruefspur — die das Herunterfahren ueberlebt und die keine Loeschregel dieser Entscheidung
erfasst.
Die Anforderung gehoert in die Geraeteschicht und nicht in die Nutzlast: Ein Pod bestimmt
nicht, ob sein Wirt auslagert. Eine Anforderung, die nur die Nutzlast kennt aber nur der
Wirt erfuellen kann, ist die Art Luecke, die niemandem auffaellt.
Der Preis ist gering und faellt sogar guenstig aus: Ohne Auslagerung ist ein
Speicherueberlauf ein harter Abbruch statt einer Verlangsamung — ein zaehes Geraet sieht wie
ein Leistungsproblem aus und wird tagelang gesucht, ein abgebrochener Pod startet neu und
steht im Protokoll.
Suspend-to-Disk faellt aus demselben Grund weg. Das Absturzabbild des Kerns bleibt offen und
beruehrt das Diagnosepaket aus ADR-0007.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Entscheidung liess offen, wo eine Nutzlast aus Containern liegt.
appliance/ADR-0005 hat den Fall schon beantwortet: Was im Bestand liegt,
nimmt der Ruecksprung nicht mit. Also Software -- k3s, Abbilder, Buendel
-- in die Wurzel, Zustand in den Bestand, und dieselbe Schemaregel wie
fuer jede andere Nutzlast.
Folge fuer die Abbildgroesse: Ein vollstaendiger Satz Container-Abbilder
liegt zweimal auf der Platte und ist vor dem ersten Abbildbau zu
beziffern.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
GAIA Lite steht jetzt bei der Plattform statt als eigener Unterbau,
GAIA Full bei der Infrastruktur. Die beiden Regeln "kein Produktname
in dieser Ablage" bleiben unberuehrt -- sie betreffen den Kern, nicht
die Einordnung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
OLYMPUS und XinionOS hatten sich unabhaengig voneinander dieselbe Schicht
gebaut: ISO-Auslieferung, Installation, Ersteinrichtung, Aktualisierung.
GAIA Lite gibt diese Rolle ab und wird eine Nutzlast auf XinionOS; der
Plattform-Vertrag darueber bleibt unveraendert, OLYMPUS und die
Anwendungen merken nichts davon.
Begruendung: ein CRA-Dossier statt zwei, ein Ruecksprung statt zweier
handgebauter, und ein Notfallzugang, den die andere Seite gar nicht hatte.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Jedes Gigabyte kostet beim Herunterladen, auf dem Stick, ueber die
Fernwartung und per Post. Und was im Abbild liegt, liegt zweimal auf der
Platte — einmal je Wurzel — und steht in der Stueckliste, die ueber die
Produktlebensdauer zu versorgen ist.
Ins Abbild kommen Betriebssystem und die Software der Nutzlast. Modelle,
Wissensspeicher und Kundenzustand liegen im Bestandsbereich. Richtwert
unter drei Gigabyte; wird es groesser, ist die Frage nicht 'wie
komprimieren wir', sondern 'warum ist das im Abbild'.
Damit war ein Widerspruch aufzuloesen: NEXTgenIT/ADR-0004 haelt fest, die
Modelle seien im Abbild mitgeliefert, sonst waere die Ersteinrichtung ein
Transfer von ueber 100 GB. Das war richtig, solange Betriebssystem und
Appliance ein Erzeugnis waren. Die Sorge bleibt berechtigt und wird anders
geloest: Das Abbild ist klein, das ausgelieferte Geraet ist voll — Modelle
kommen im Werk auf den Bestandsbereich.
Der Fall, der dabei zuerst Sorge macht, loest sich von selbst: Eine
Neuinstallation fasst den Bestandsbereich nicht an. Ein Transfer ueber die
Leitung ist nur bei einem fabrikneuen leeren Geraet noetig.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Sicherung wird ebenfalls verschluesselt — aber die Wahl des
Schluessels ist wichtiger als die Entscheidung selbst. Mit dem
Geraeteschluessel verschluesselt waere sie genau dann unlesbar, wenn man
sie braucht: Geraet zerstoert, Baustein weg, Sicherung wertlos. Sie traegt
deshalb einen eigenen Schluessel, der nicht am Geraet haengt und den der
Kunde verwahrt.
Zum Sicherheitstoken: Er loest an drei Stellen drei verschiedene Probleme,
die leicht verwechselt werden. Als Wiederherstellung tragfaehig, als
zweiter Faktor eigenstaendig sinnvoll — als dauerhaft steckende
Startbedingung aber ohne Gewinn gegenueber dem Sicherheitsbaustein, weil
beide gegen ein entwendetes Laufwerk schuetzen und keiner gegen ein
entwendetes Geraet.
Echt und verkaufbar ist der Fall, in dem der Token bewusst entfernt wird.
Deshalb: Sicherheitsbaustein bleibt der Regelweg, Token ist
Zusatzausstattung fuer Kunden, die 'startet nicht ohne Token' verlangen —
mit der ausgesprochenen Folge, dass das Geraet nach einem Stromausfall
nicht von allein hochkommt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Annahme 'wer bis zum Server kommt, ist freigegeben' traegt genau so
lange, wie das Geraet im Haus des Kunden bleibt. Bei Reparatur, Austausch,
Rueckgabe und Entsorgung entscheidet allein, was auf dem Datentraeger
steht.
Der Bestandsbereich wird deshalb bei der Einrichtung verschluesselt, ohne
Schalter. Die Wurzeln nicht: Dort steht unsere ausgelieferte Software, die
auf jedem Geraet dieselbe und damit kein Geheimnis ist. Dort ist nicht
Vertraulichkeit die Frage, sondern Unversehrtheit — und dagegen hilft eine
Pruefung beim Start, keine Verschluesselung.
Sichere Loeschung heisst Schluesselvernichtung. Auf Flash-Speichern ist
Ueberschreiben durch die Verschleissverteilung nicht verlaesslich; ein
Loeschlauf, der stundenlang Nullen schreibt, erzeugt vor allem ein gutes
Gefuehl. Damit haengen beide Festlegungen zusammen: Ohne Verschluesselung
gibt es keine verlaessliche Loeschung.
Drei Stufen fuer drei Absichten, die zweite und dritte mit Loeschnachweis
auf USB — bei einem Produkt, dessen Verkaufsargument der Nachweis ist,
waere eine Loeschung ohne Beleg ein Widerspruch in sich.
Die harte Stelle ist der Schluessel beim Start. Er bindet an den
Sicherheitsbaustein, dessen Messung sich mit jedem Update aendert. Wird er
nicht vorher auch fuer die neue Fassung hinterlegt, steht nach dem
Umschalten ein Geraet da, das oben ist und an seine eigenen Daten nicht
herankommt — nicht ein misslungenes Update, sondern ein Datenverlust.
Daraus ein zweiter Nachweis: Nach Fassungswechsel und Ruecksprung ist der
Bestandsbereich erreichbar.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die schuetzbare Eigenart liegt in Xinion, nicht im beschreibenden Zusatz
OS. Ein Name, dessen unterscheidungskraeftiger Teil dem Haus ohnehin
gehoert, ist tragfaehiger als ein eigenes Kunstwort, das zusaetzlich
verteidigt werden muesste.
Die Kurzform XinOS ist geprueft und verworfen: Nach Abzug des
beschreibenden OS bleibt die Silbe Xin, damit ist die
Unterscheidungskraft gering — und mit Xinuos gibt es bereits einen
Anbieter von Betriebssystemen mit klanglich aehnlichem Namen.
Die Abhaengigkeit ist festgehalten: Die Marke Xinion ist noch nicht
eingetragen, solange ist der Name benutzbar aber nicht
verteidigungsfaehig. Bei der Anmeldung sind Klasse 9 und Klasse 42 noetig
— eine Eintragung nur fuer IT-Dienstleistungen hilft einem
ausgelieferten Betriebssystem nicht.
Faellig ist die Klaerung, bevor der Name auf ein Geraet, in ein
CRA-Dossier oder auf ein Datenblatt kommt. Nicht bevor er auf einen
Ordner kommt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Geraeteschicht — Abbild, zwei Wurzeln, Selbstprueflauf, Ruecksprung —
verlaesst die Ablage der ersten Appliance und wird ein eigenes Erzeugnis
mit eigenem Takt und eigenem Nachweis.
Drei Gruende, nach Gewicht: Der Cyber Resilience Act verpflichtet fuer das
gesamte Produkt einschliesslich der Betriebssystemschicht — vier gewachsene
Basissysteme waeren vier Stuecklisten und vier Schwachstellenprozesse, eine
gemeinsame Basis ist ein Dossier. Der Ruecksprung wird nur einmal richtig
gebaut, weil er nur geprueft wird wenn ihn jemand braucht. Und eine
abgegrenzte Aufgabe laesst sich ausschreiben, was unmittelbar auf das
groesste benannte Risiko des Hauses einzahlt.
Der Einwand der Vertraeglichkeitsmatrix wird durch den Nutzlast-Vertrag
entkraeftet statt weggeredet: Die Nutzlast liegt in der Wurzel und wird mit
ihr getauscht. Eine Fassung, ein Rueckweg, keine Matrix.
Das OS kennt kein Produkt — Regel 1. Alle Namen sind entkoppelt, die
Statusseite ist auf die Standardbibliothek umgestellt, weil jede
Abhaengigkeit im Grund-OS eine Verpflichtung ueber die Produktlebensdauer
ist.
Nichts davon ist gelaufen. Der Inhalt gilt als Bauplan.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
