Anfragen und Entscheidungen
Gespräche, Issues, Anforderungen, Abnahmekriterien und Freigaben behalten ihre eigene Bedeutung und klare Zuständigkeiten.
Ein Gespräch sollte seine Bedeutung nicht verlieren, wenn daraus eine Aufgabe, eine Codeänderung oder eine Bereitstellung wird. Orion Workspace soll der vernetzte Ort für die Menschen, Entscheidungen und Belege hinter einer Anwendung werden.
Die hier beschriebene Arbeitsumgebung ist unsere Zielrichtung für NatusAI Orion. Produktumfang und Verfügbarkeit werden gesondert qualifiziert; dies ist keine Release-Ankündigung.

Eine Beispielanfrage zeigt die geplante Kette. Jede Stufe erzeugt etwas, das die nächste Person – oder ein autorisierter Agent – prüfen kann.
Den Bedarf festhalten. Vereinbaren, welche Sendungen betroffen sind, was als Verspätung gilt und wer die Information erhalten darf. Eingehendes Feedback wird erst zur Anforderung, wenn es angenommen wird.
Die exakte Quellcodeänderung mit einer Vorschau, den Testergebnissen und der Entscheidung über ihre Übernahme verknüpfen. Fehlgeschlagene Prüfungen bleiben sichtbar.
Ein unveränderliches Release erstellen, die Zielumgebung festhalten und beobachten, ob die Anwendung dort ihre Abnahmeprüfungen erfüllt.
Die daraus folgenden Beobachtungen zu Zustand, Support und Nutzung bleiben mit dem Release verknüpft. Neue Belege prägen die nächste Verbesserung.
Illustrativer Ablauf, kein laufender Workspace und keine Demonstration einer veröffentlichten Anwendung.
Vier Arten von Aufzeichnungen bleiben verknüpft. So sieht jeder, der eine Anwendung prüft, warum sie sich geändert hat – nicht nur, dass sie sich geändert hat.
Gespräche, Issues, Anforderungen, Abnahmekriterien und Freigaben behalten ihre eigene Bedeutung und klare Zuständigkeiten.
Dokumentation, Quellcodeverweise und Entwicklungshistorie bleiben versioniert und zuordenbar. Geplant ist eine Git-basierte Zusammenarbeit; die Forge ist noch nicht ausgewählt.
Aufgaben, Versuche, Checkpoints, Diagnosen, Evaluierungen und Verifikationsartefakte sind mit den Eingaben und der Quellcodeversion verknüpft, auf die sie sich beziehen.
Eine gemergte Änderung, ein veröffentlichtes Release und eine stabile Bereitstellung sind unterschiedliche Ergebnisse – mit getrennten Aufzeichnungen und Prüfungen.
Eine Aufgabe sollte zuerst die relevante Fähigkeit und Version finden und dann die Schemas, Beispiele oder Belege abrufen, die sie benötigt. Eine kleine Änderung sollte nicht erfordern, ein ganzes Repository oder einen kompletten Gesprächsverlauf zu laden.
Dauerhafte Versuche, Abbruch, Checkpoints und Budgets machen laufende Arbeit verständlich. Zusammenfassungen behalten Quellenverweise und Aktualität, während Anwendungswissen nur für berechtigte Beteiligte sichtbar bleibt.
Kompakte Diagnosen und präzise Diffs helfen Menschen und Agenten, das Ergebnis zu prüfen – ohne wichtige Informationen zu Korrektheit oder Berechtigungen zu verbergen.


Menschen behalten die Kontrolle über Geschäftsziele, Zugriffe, Budgets und Betriebsrichtlinien. Sichtbarkeit auf Plattformebene gewährt keinen Zugriff auf vertrauliche Anwendungsdaten.
Der Agent, der eine Änderung vorschlägt, kann weder seine eigenen erweiterten Berechtigungen freigeben noch seine Abnahmekriterien abschwächen oder seinen eigenen Nachfolger aktivieren.
Sagen Sie uns, was Ihr Unternehmen braucht. Wir helfen Ihnen, einen praktischen Einstieg zu finden.
Oder schreiben Sie an contact@natusai.com
