Peace of mind at AI speed.
Know what changed. What shipped. What’s running.
Wir machen Software Delivery für Menschen und AI Agents nachvollziehbar. Damit Ihr Team Fragen zu Änderungen, Releases und Deployments beantworten kann, ohne jedes Mal von vorn zu suchen.
30 Minuten. Kostenlos und unverbindlich.
Ist der Fix wirklich in Produktion angekommen?
Das Repository zeigt den Code. Die Pipeline kennt den Build. Die Registry enthält das Artefakt. Das Deployment-System zeigt, was ausgerollt wurde. Eine wichtige Frage braucht oft Informationen aus mehreren dieser Systeme.
Die Teile sind da. Ihr Zusammenhang fehlt. Also sucht jemand erneut, fragt im Team nach oder arbeitet mit Annahmen.
Die Antwort sollte nicht davon abhängen, wer sich noch erinnert.
- Was hat sich geändert?
- Zwei tatsächliche Releases vergleichen: Code, Dependencies, Build-Eingaben, Konfiguration und zugehörige Checks. So beginnt die Untersuchung bei den relevanten Unterschieden.
- Was wurde ausgeliefert?
- Die gelieferte Software ihrem Build, ihren Komponenten und den dokumentierten Checks und Entscheidungen zuordnen. Für Release-Prüfung, Support und Fragen zu betroffenen Versionen.
- Was läuft tatsächlich?
- Die eingesetzte Version mit Build und Release verbinden. Für den aktuellen Stand das Deployment-System abfragen. Ein Branch, ein Tag oder der gestrige Rollout reicht dafür nicht.
Gleicher Code. Anderes Verhalten.
Nach einem Update verhält sich Produktion anders. Der Code ist gleich geblieben. Das Basis-Image nicht.
Voriges Release
Neues Release
Noch offen: Ein relevanter Konfigurationswert wurde nicht verifiziert.
Worauf stützt sich dieser Vergleich?
- Code: Source-Revisionen der beiden Builds.
- Basis-Image: Aufgezeichnete Build-Eingaben und Image-Digests.
- Deployment: Abfrage von Staging und Produktion zum Untersuchungszeitpunkt.
Die Angaben zeigen, welche Quellen ein solcher Vergleich benötigt. Das Beispiel enthält keine echten Systemdaten.
Das beweist keine Ursache. Es zeigt, was zu untersuchen ist und was noch fehlt. Ein Engineer kann den Quellen folgen. Ein Agent kann dieselben Fakten verwenden.
Gespeicherte Historie erklärt, was passiert ist. Eine aktuelle Abfrage zeigt den Stand des Deployment-Systems zu diesem Zeitpunkt.
Eine wichtige Frage. Ein Ablauf, der sie beantwortet.
Wir setzen bei einem realen Produkt und einer wiederkehrenden Frage an. Zum Beispiel: Wenn der Support eine Meldung zu diesem Release erhält, wie findet Ihr Team den Build, seine Bestandteile und die Änderungen zur Vorversion?
Die Frage bestimmt den Umfang. Wir verbinden die benötigten Informationen, beheben vereinbarte Lücken bei der Zuordnung oder Erfassung und automatisieren die wiederholbaren Schritte.
Die Antwort festlegen
Gemeinsam bestimmen wir, was eine brauchbare Antwort enthalten muss, welche Quellen sie benötigt und wie Ihr Team sie prüft.
Den Ablauf umsetzen
Wir verbinden die vereinbarten Systeme und Datensätze in Ihrer Umgebung. Vorhandene Tools, passende Adapter und wiederverwendbare Regeln bilden die Grundlage.
Am nächsten Release prüfen
Ihr Team führt den Ablauf erneut aus. Quellen und verbleibende Lücken sind sichtbar. Konfiguration, Integrationen, Checks und Anleitung bleiben bei Ihnen.
Sie erhalten einen wiederholbaren Workflow.
Die Abnahme ist praktisch: Kann Ihr Team die vereinbarte Frage für das nächste Release erneut beantworten, mit sichtbaren Quellen und offenen Punkten?
Fakten für Menschen und AI Agents.
Menschen brauchen eine Erklärung, die sie prüfen und hinterfragen können. Agents brauchen maschinenlesbare Fakten mit nachvollziehbaren Quellen.
Dieser Build hat dieses Artefakt erzeugt. Dieser Check gehört zu diesem Artefakt. Dieses Deployment nutzt diese Version. Wo eine Verbindung fehlt, bleibt sie ausdrücklich offen.
So muss der nächste Arbeitsschritt die Release-Historie nicht erneut rekonstruieren. Ob ein Agent damit seine Aufgabe besser löst, prüfen wir am konkreten Fall: etwa an korrekteren Antworten, weniger Verifikationsaufwand oder einer kürzeren Untersuchung.
- Fakten vor Annahmen.
- Beziehungen aus ihren Quellen festhalten, damit der nächste Mensch oder Agent sie nicht erraten muss.
- Erst zuordnen, dann beurteilen.
- Klären, welcher Build, welches Artefakt, welches Release und welches Deployment gemeint ist.
- Unbekannt bleibt unbekannt.
- Fehlende Informationen gehören zur Antwort. Auch ein Agent muss seine Schlussfolgerungen daran prüfen lassen.
rio. Der Open-Source Evidence Compiler für Software Delivery.
Was Ihre Pipeline weiß, soll später noch nutzbar sein.
rio ist unsere wiederverwendbare technische Grundlage. Die Entwicklungsrichtung: unterstützte Engineering-Eingaben in strukturierte Datensätze übersetzen, die Fakten, Verarbeitungsschritte, Quellen und verbleibende Lücken festhalten.
rebaze setzt den vereinbarten Workflow um. rio verarbeitet die unterstützten Daten darin. Für den aktuellen Betriebsstand bleiben Deployment-Systeme die Quelle.
Heute verfügbar und nächste Richtung
Heute verfügbar
rio normalisiert CycloneDX-SBOMs, korrigiert unterstützte Komponenten-IDs und prüft deklarierte Qualitätsanforderungen. Die Ausgaben halten Änderungen und ungelöste Zuordnungen fest.
rio ergänzt keine fehlenden Komponenten und sucht nicht selbst nach Schwachstellen. Ein bestandener Qualitätscheck bestätigt die deklarierten Anforderungen, nicht die Vollständigkeit der SBOM.
Entwicklungsrichtung
Weitere Eingaben und Beziehungen sollen hinzukommen, wenn ein konkreter Anwendungsfall sie braucht. Die gesamte Verbindung von Code, Release und Deployment ist keine heute verfügbare rio-Funktion.
Sie können rio ohne rebaze einsetzen. Eine Zusammenarbeit mit rebaze setzt rio nicht voraus.
Für welche Frage öffnen Sie heute mehrere Tools?
Oder suchen die Person, die sich noch erinnert? Bringen Sie ein reales Beispiel aus Ihrer Software Delivery mit. Gemeinsam klären wir, wie die Antwort wiederholbar wird.
Support, Entwicklung, Security, Compliance oder ein Agent-Workflow können der Anlass sein. Wir beginnen mit Ihrer Frage.
Ihr Beispiel besprechen