Was ein OSIRIS-JSON-Producer tun soll
OSIRIS-JSON-Producer sind der Ort, an dem der Standard real wird.
Die Producer-Leitlinien und die Dokumentation zum Producer-SDK machen das ausdrucklich. Ein Producer ist nicht nur ein Parser, der zufallig JSON ausgibt. Er ist die Grenze, an der proprietare Inventare in einen deterministischen, portablen und sicheren OSIRIS-Snapshot ubersetzt werden, dem andere Werkzeuge vertrauen konnen.
Ein Producer ist ein Ubersetzer im Nur-Lesen-Modus
Der erste wichtige Punkt in den Producer-Leitlinien ist, was ein Producer nicht ist.
Er provisioniert keine Infrastruktur. Er verandert keine Gerate. Er erfindet keine fehlenden Daten. Er interpretiert die Spezifikation nicht neu. Die Aufgabe eines Producers ist enger und strenger: erkennen, was existiert, es in OSIRIS normalisieren, unsichere oder irrelevante Daten entfernen und einen Snapshot ausgeben, der von der kanonischen OSIRIS-Toolchain validiert werden kann.
Das klingt offensichtlich, aber genau dort sollte die Grenze gezogen werden. In dem Moment, in dem Producer anfangen, sich wie Control Planes zu verhalten, oder eigene Vorstellungen davon einzubetten, was OSIRIS bedeutet, bricht die Interoperabilitat auseinander.
Der Producer-Workflow ist bewusst aufgebaut
Die Dokumentation beschreibt den Lebenszyklus eines Producers in vier Schritten: discovery, normalization, redaction und emission.
Diese Reihenfolge ist wichtig, weil jede Phase eine andere Verantwortung hat:
- discovery sammelt Daten vom Vendor oder von der Plattform
- normalization ordnet sie den standardisierten OSIRIS-Strukturen zu
- redaction entfernt Geheimnisse, PII und nutzloses Rauschen
- emission serialisiert das Dokument und validiert es vor der Veroffentlichung
Die Leitlinien lassen auch Raum fur die Realitat. Teilweise Inventare sind akzeptabel. Einzelne discovery-Fehler sollten in der Regel protokolliert und ubersprungen werden, statt den gesamten Export absturzen zu lassen. Aber diese Flexibilitat endet an der Sicherheitsgrenze: Wenn Geheimnisse erkannt werden, soll der Producer sicher fehlschlagen.
Determinismus ist eine Funktion, kein Feinschliff
Eines der starksten Themen in beiden Dokumenten ist Determinismus.
Es wird erwartet, dass Ressourcen-IDs, Verbindungs-IDs und Gruppen-IDs zwischen Laufen stabil bleiben. Die Producer-Dokumentation warnt nachdrucklich vor Zufall, instabiler Sortierung und Ad-hoc-Benennung. Der Grund ist einfach: Wenn dieselbe Umgebung jedes Mal eine andere Ausgabe erzeugt, werden Diffs, Korrelation und nachgelagerte Automatisierung unzuverlassig.
Das SDK unterstutzt das mit konkreten Hilfen:
- deterministische ID-Erzeugung aus kanonischen Schlusseln
- zweiphasige Kollisionsbehandlung uber ein
IDRegistry - ein
DocumentBuilder, der$schema,version, Generator-Metadaten und sortierte Topologie-Ausgabe verwaltet - Test-Helper, die Byte-fur-Byte-Determinismus und die Konsistenz von Golden Files prufen
Das ist eines der klarsten Zeichen dafur, dass OSIRIS fur langlebiges Tooling entworfen wird und nicht fur einmalige Exporte.
Sicherheit ist Verantwortung des Producers
Die Producer-Leitlinien sind in Bezug auf Redaction genauso klar.
OSIRIS-Dokumente durfen keine Zugangsdaten, Tokens, privaten Schlussel oder Verbindungszeichenfolgen mit eingebetteten Geheimnissen enthalten. Von Producers wird erwartet, dass sie vor der emission nach haufigen Mustern suchen, unsichere Werte zerlegen statt sie vollstandig zu ubernehmen und einen expliziten Fehlermodus wahlen.
Die empfohlene Standardeinstellung ist fail-closed. Es gibt einen optional aktivierbaren log-and-redact-Modus, aber auch dort bleiben die Regeln streng: Niemals den geheimen Wert selbst protokollieren, das Dokument immer als redigiert kennzeichnen und Redaction niemals stillschweigend passieren lassen.
Das ist die richtige Haltung. Producer sitzen am nachsten an den rohen Quellsystemen und sind deshalb der gefahrlichste Ort fur Nachlassigkeit.
Das SDK ist da, um Drift zu verhindern
Das Go-Producer-SDK wird nicht als magische Infrastruktur prasentiert. Es wird als Mittel prasentiert, um Producer-Drift zu stoppen.
Es standardisiert den Vertrag Collect(ctx), stellt gemeinsamen Laufzeitkontext, Ressourcen- und Beziehungs-Factories, Normalisierungs-Helper, deterministische Builder und ein Test-Harness bereit. Genauso wichtig ist, dass es sich weigert, ein zweiter Validator zu werden. Das SDK besitzt die V-*-Diagnosen nicht und importiert @osirisjson/core nicht als Bibliothek. Producer validieren ihre Ausgabe, indem sie die kanonische CLI als externen Schritt aufrufen.
Diese Trennung ist architektonisch sauber. Sie halt die Mapping-Logik in den Producers und die Validierungslogik in der gemeinsamen OSIRIS-Engine.
Vertrauen kommt aus Tests
Die abschliessende Aussage in der Producer-Dokumentation ist, dass Producer-Ausgabe reproduzierbar und uberprufbar sein muss.
Golden Files werden als wichtigste Absicherung gegen Regressionen behandelt. Der erwartete Workflow ist einfach: den Vendor-Eingang simulieren, das OSIRIS-Dokument erzeugen, es mit dem Golden File vergleichen und dieses Artefakt dann mit der kanonischen CLI unter dem Profil strict validieren. Das Test-Harness des SDK liefert Helfer fur diesen Ablauf und fur deterministische Wiederholungen mit festen Uhren und Fixtures.
Das ist wichtig, weil Producer-Qualitat nicht nur davon abhangt, ob der Export “einmal funktioniert”. Es geht darum, ob dieselbe Eingabe weiterhin vertrauenswurdige Ausgabe erzeugt, wahrend sich das Okosystem weiterentwickelt.
Die Producer-Dokumentation lesen
Die Producer-Leitlinien sind im Architekturabschnitt der Dokumentation verfugbar: