Engineeringsysteme
Governed AI Engineering für komplexe Softwareentwicklung
Salvoc baut komplexe Software mit einem gesteuerten Multi-Agenten- und Multi-Modell-Engineeringsystem — über Marktplatz-, Transaktions-, Workflow-, Buchhaltungs- und Plattformdomänen hinweg: spezialisierte KI-Rollen, unabhängige modellübergreifende Prüfung, deterministische Validierung, Sicherheitskontrollen und explizite menschliche Autorität arbeiten als ein System.
Multi-Agent
6 Kernrollen im Engineering
Multi-Modell
Modellübergreifende Prüfung
Kontrolle
Deterministische Validierung
Sicherheit
Integrierte Leitplanken
Autorität
Menschlich kontrollierte Git-Aktionen
- 01
Menschlicher Projektinhaber
Trägt Ergebnis und Autorität.
- 02
Orchestrierung
Begrenzt Aufgabe und Umfang.
- 03
Architektur
Definiert die Systemgrenze.
- 04
Implementierung
Setzt gegen den Entwurf um.
- 05
Unabhängige Prüfung
Hinterfragt die Änderung.
- 06
Sicherheit + Validierung
Beweist die Änderung deterministisch.
- 07
Menschliche Autorität
Gibt die Änderung explizit frei.
Eine gesteuerte Delivery-Pipeline vom Projektinhaber bis zur expliziten menschlichen Freigabe.
Was wir bauen
Was wir bauen — und wie wir es bauen
Komplexe Softwareentwicklung ist keine einzelne Aufgabe. Sie ist eine Kette: eine Domäne verstehen, ihre Architektur formen, Frontend-, Backend-, Daten- und Integrationsflächen implementieren und das Ergebnis unter realen Randbedingungen beweisen.
Salvoc führt diese Kette als gesteuertes Engineeringsystem. Spezialisierte KI-Rollen erledigen begrenzte Arbeit; unabhängige Prüfung und deterministische Validierung testen sie; Sicherheitskontrollen umgeben sie; und ein direkt verantwortlicher Engineer hält die finale Autorität über jede Freigabe.
Die Engineering-Herausforderung
Fähigkeit allein genügt für komplexe Systeme nicht
Komplexe Systeme konzentrieren Risiko an den Nahtstellen: Zustand, der Servicegrenzen überschreitet, Geld, das durch Workflows fliesst, Berechtigungs- und Auditpflichten, Integrationen, die leise statt laut scheitern.
Solche Systeme belohnen Fähigkeit — aber nur, wenn Fähigkeit gesteuert ist. Geschwindigkeit ohne Architektur erzeugt Schulden. Automatisierung ohne Validierung erzeugt Störfälle. KI ohne menschliche Autorität erzeugt Unberechenbarkeit.
Komplexe Software braucht beides: Fähigkeit und Kontrolle. Das Salvoc-Betriebsmodell ist um diese Kombination gebaut — nicht um nur eine der beiden Seiten.
Multi-Agenten-Engineering-Team
Ein Multi-Agenten-Team mit klaren Rollen
Die Ausführungsebene des Systems ist ein Team aus sechs Kernrollen: Orchestrator, Architect, Coder, Senior Coder, Senior Reviewer und QA.
Das sind KI-Rollen innerhalb eines gesteuerten Betriebssystems — keine Aussage über eine Personalgrösse. Jede Rolle erfüllt eine begrenzte Funktion, und ein verantwortlicher Engineer trägt Architektur und Lieferung durchgehend selbst.
Architektur
Architect
Implementierung
Coder
Senior Coder
Qualität
QA
Rollenstruktur: Aufgaben fliessen nach unten, Befunde nach oben, und ohne Review-Gate wird nichts freigegeben. · Independent Reviewer · Chief Architecture Supervisor
Multi-Modell-Cross-Review
Erzeugung und Freigabe sind bewusst getrennt
Verschiedene Engineering-Funktionen können auf unterschiedlichen Modellfamilien laufen. Die Implementierung bestätigt sich nicht selbst: Eine Änderung, die ein Modell erzeugt hat, wird von einem anderen Review-Modell geprüft als dem, das sie erzeugt hat.
Modellvielfalt erzeugt echte Herausforderungspfade statt Bestätigungsschleifen. Das Ziel ist eine bewusste Reduktion der Abhängigkeit von einem einzelnen Modell — kein Anspruch, Verzerrung eliminiert zu haben.
Verschiedene Engineering-Funktionen fordern einander heraus, statt einander nur zu bestätigen.
- 01
Architekturmodell
Plant die Änderung und ihre Grenze.
- 02
Implementierungsmodell
Schreibt die Änderung.
- 03
Anderes Review-Modell
Hinterfragt den Diff unabhängig.
- 04
Reparatur
Führt die Änderung zurück, bis das Review sauber ist.
- 05
Deterministische Validierung
Beweist den Endzustand mit festen Gates.
Führt die Änderung zurück, bis das Review sauber ist. Deterministische Validierung — Beweist den Endzustand mit festen Gates.
Engineering-Architektur
Eine Pipeline, mehrere Modellfamilien-Lanes
Arbeit durchläuft eine feste Sequenz: Orchestrierung, Architektur, Implementierung, unabhängige Prüfung, Sicherheit und Validierung, schliesslich menschliche Autorität. Jede Stufe hat eine definierte Rolle und eine definierte Grenze.
Durch diese Sequenz laufen Modellfamilien-Lanes nach Funktion: Architektur- und Review-Reasoning, Implementierung und Ausführung sowie deterministische Durchsetzung. Keine Lane umgeht die Sequenz, und nichts erreicht eine Repository-Grenze ohne Nachweis und Freigabe.
Die Pipeline ist fest; die Modell-Lanes darin werden nach Funktion zugewiesen, nicht aus Gewohnheit.
- 01Menschlicher ProjektinhaberErgebnis und Autorität.
- 02OrchestrierungAufgabenbegrenzung und Übergänge.
- 03ArchitekturGrenz- und Designentscheidungen.
- 04ImplementierungBegrenzte Bauarbeit.
- 05Unabhängige PrüfungHerausforderung gegen den Auftrag.
- 06Sicherheit + ValidierungDeterministischer Nachweis.
- 07Menschliche AutoritätExplizite Freigabe.
Architektur- und Review-Reasoning
Unabhängige Prüfung auf stärkerer Fähigkeit.
Implementierung und Ausführung
Schnelle, begrenzte Coding-Arbeit.
Deterministische Durchsetzung
Werkzeuge und Gates statt Modellurteil.
Sicherheit durch Delivery-Design
KI-generierte Änderungen gelten bis zur Validierung als nicht vertrauenswürdig
Sicherheit ist ein erstklassiger Teil der Lieferung, keine Fussnote. Das Betriebsmodell behandelt KI-generierte Änderungen wie jeden externen Beitrag: Sie erreichen weder ein Repository noch eine Laufzeit, bis deterministische Sicherheitsprüfungen bestanden sind und ein Mensch sie autorisiert hat.
Modell-Reasoning und Review schlagen Arbeit vor; eine deterministische Durchsetzungsschiene entscheidet, was weitergehen darf.
KI-Reasoning und Review
Schlägt die Änderung vor und hinterfragt sie.
KI-generierte Änderung: Bis zur Validierung nicht vertrauenswürdig
01 · Secrets
Zugangsdaten und Schlüssel landen nie im Code.
02 · SAST
Statische Analyse bei jeder Änderung.
03 · Abhängigkeiten
Prüfung auf bekannte Schwachstellen.
04 · Image / Container
Prüfung von Basis-Images und Layern.
05 · SBOM
Software-Stückliste.
06 · Laufzeit
Posture- und Verhaltensprüfungen.
07 · Egress / Netzwerk
Grenzen für ausgehenden Verkehr.
08 · Mailer / externe Kommunikation
Kontrollen für ausgehende Nachrichten.
Deterministisches Gate
Feste Prüfungen, kein Modellurteil.
Menschliche Autorität
Explizite Freigabeentscheidung.
Die Kontrollen sind mehrschichtig und bewusst konservativ. Sie verkleinern die Risikofläche KI-gestützter Lieferung; sie sind kein Anspruch auf universelle Sicherheit oder ein perfektes Gate.
Deterministische Kontrollen
Deterministische Kontrollen um probabilistische Arbeit
KI kommt dort zum Einsatz, wo Urteil und Synthese Wert schaffen: Reasoning, Planung, Implementierung und Review.
Deterministische Systeme kommen überall dort zum Einsatz, wo Gewissheit verfügbar und erforderlich ist: Tests, Verträge, Linting, Typen, Builds, Sicherheitsscans, Laufzeitprüfungen, Policy-Gates und Git-Grenzen.
KI einsetzen für
- Reasoning
- Planung
- Implementierung
- Review
Deterministische Systeme einsetzen für
- Tests
- Verträge
- Lint
- Typen
- Build
- Sicherheitsscans
- Laufzeitprüfungen
- Policy-Gates
- Git-Grenzen
Probabilistische Werkzeuge schlagen vor. Deterministische Systeme entscheiden, was landen darf.
Reale Liefernachweise
Liefernachweis statt Theorie
Das Betriebsmodell ist nicht abstrakt. Die folgenden Flächen sind reale Software, die damit geliefert wurde — Marktplatz-, Buchhaltungs- und Plattform-Engineering, das produktiv läuft.
SCAPE
Marktplatz-Betriebsplattform
- Marktplatz
- Buchung
- Zahlungen
- Rückerstattungen
- Abrechnung
- Partnerbetrieb
Számlaflow
Buchhaltungs-Workflow-Plattform
- Buchhaltungs-Workflows
- Rechnungsverarbeitung
- Audit und Review
- Backend-Dienste
- Validierung
Salvoc Platform
Delivery- und Produktplattform
- Plattform-Engineering
- Frontend
- Sicherheitskontrollen
- Laufzeit und Egress
- Publikations-Gates
Fähigkeitsbereiche werden nach Domäne gezeigt; Implementierungsdetails bleiben innerhalb der Projektgrenzen.
Repräsentativer Delivery-Zyklus
Ein kompakter Zyklus für jede Änderung
Der meiste Aufwand im System folgt demselben kompakten Zyklus: offen geplant, von einer Spezialrolle umgesetzt, von einem unabhängigen Reviewer hinterfragt, bis zur Sauberkeit repariert, deterministisch validiert und nur durch explizite menschliche Autorität freigegeben.
- 01
Planen
Begrenzte Aufgabe, Auftrag und Umfang werden offen definiert.
- 02
Implementieren
Eine Spezialrolle setzt gegen den Auftrag um.
- 03
Review
Ein unabhängiger Reviewer hinterfragt den tatsächlichen Diff.
- 04
Reparieren
Befunde führen zur Implementierung zurück, bis sie sauber ist.
- 05
Erneut reviewen
Der reparierte Zustand wird erneut geprüft — nie als behoben angenommen.
- 06
Validieren
Deterministische Gates laufen auf dem Endzustand.
- 07
Menschliche Autorität
Eine explizite Freigabe durch den verantwortlichen Engineer.
Stützendes Beispiel
Ein begrenztes Backend-Delivery-Item (Referenz SF-BE-011) durchlief diesen Zyklus vollständig. Das Beispiel ist repräsentativ; interne Session-Identifikatoren werden nie offengelegt.
Projektspezifische Governance
Ein wiederverwendbares System, das jedes Projekt respektiert
Salvoc bringt ein wiederverwendbares Betriebsmodell mit, ohne die Architektur- und Governance-Anforderungen des Kundensystems zu übersteuern.
Jedes Engagement trägt seine eigene Quelle der Wahrheit: Domänenregeln, Datenverträge, Architekturentscheidungen und Sicherheitsrandbedingungen des Projekts. Das Engineeringsystem passt sich ihnen an, statt sie zu ersetzen.
Das Betriebsmodell ist wiederverwendbar; die Governance jedes Projekts bleibt projektspezifisch.
Grenze menschlicher Autorität
Menschliche Autorität ist die Freigabegrenze
Das Engineeringsystem kann vieles planen, schreiben, testen und reparieren. Es entscheidet nicht, was geliefert wird.
Ein direkt verantwortlicher Engineer hält jede Freigabeentscheidung. Dieselbe Person, die das Problem bespricht, trägt die technischen Entscheidungen und die Lieferung — Architektur und Implementierung bleiben verbunden, ohne Übergabe an ein separates Delivery-Team.
Erfordert immer explizite menschliche Autorität
- Repository-Schreibzugriffe
- Commit- und Release-Umfang
- Produktionsänderungen
- Kundenorientierte Zusagen
Fähigkeitsübersicht
Was das System bietet
Das Betriebsmodell lässt sich am besten als sechs Fähigkeiten verstehen, die als ein System wirken.
Multi-Agent-Engineering
Spezialisierte Rollen — Orchestrierung, Architektur, Coding, Review, QA — in einem gesteuerten System.
Multi-Modell-Cross-Review
Erzeugung und Freigabe sind getrennt; verschiedene Modellfamilien fordern einander heraus.
Deterministische Validierung
Tests, Verträge, Lint, Typen, Builds und Policy-Gates entscheiden, was landen darf.
Sicherheits-Leitplanken
Secrets, SAST, Abhängigkeiten, Container, SBOM, Laufzeit- und Egress-Prüfungen umgeben KI-gestützte Lieferung.
Projektspezifische Governance
Das wiederverwendbare System passt sich SSOT, Domänen-Policy und Sicherheitsrandbedingungen jedes Projekts an.
Menschliche Autorität
Ein verantwortlicher Engineer hält die Freigabegrenze; nichts wird ohne explizite Autorisierung ausgeliefert.
Aktuelle Systemrichtung
Fähigkeit wird ehrlich ausgewiesen
Das Betriebsmodell wird gezielt und kontinuierlich weiterentwickelt. Reife wird in drei Zuständen ausgewiesen — geliefert, entworfen, Roadmap — nur dort, wo Fähigkeitsreife zählt.
Marktplatz-Delivery
SCAPE-Transaktionsflächen: Buchung, Zahlungen, Rückerstattungen, Abrechnung.
GeliefertBuchhaltungs-Workflow-Delivery
Számlaflow-Rechnungsverarbeitung, Audit und Validierung.
GeliefertWiederverwendbare Übernahme in weiteren Kundendomänen
Breitere Anwendung des Betriebsmodells über die heutigen Flächen hinaus.
EntworfenBreitere Modell- und Tooling-Härtung
Erweiterte Modellvielfalt, Review-Tooling und Gate-Abdeckung.
Roadmap
Die Status beschreiben die Reife der Lieferfähigkeit — keine Teamgrösse und keine universelle Garantie.
Für Kunden
Was das für Kunden bedeutet
Mit Salvoc zu arbeiten bedeutet, ein Lieferungssystem zu engagieren — nicht isolierte KI-Unterstützung zu kaufen. KI-Fähigkeit wird in der Breite genutzt — aber so gesteuert, wie ernsthafte Engineering-Arbeit gesteuert wird: Architektur vor Beschleunigung, unabhängiges Review vor Merge, deterministischer Nachweis vor Release, menschliche Autorität, bevor etwas produktiv geht.
Das Ergebnis ist der nützliche Teil KI-gestützter Softwareentwicklung — Tempo, Tiefe und Breite — ohne die Engineering-Disziplin aufzugeben, die komplexe Systeme schützt.
Gestalten Sie Ihr AI-Engineering-Betriebsmodell
Strukturieren Sie KI-gestützte Lieferung um spezialisierte Engineering-Rollen, unabhängige Herausforderung, deterministische Validierung, Sicherheitskontrollen und explizite menschliche Autorität.
