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

  1. 01

    Menschlicher Projektinhaber

    Trägt Ergebnis und Autorität.

  2. 02

    Orchestrierung

    Begrenzt Aufgabe und Umfang.

  3. 03

    Architektur

    Definiert die Systemgrenze.

  4. 04

    Implementierung

    Setzt gegen den Entwurf um.

  5. 05

    Unabhängige Prüfung

    Hinterfragt die Änderung.

  6. 06

    Sicherheit + Validierung

    Beweist die Änderung deterministisch.

  7. 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.

Menschlicher Projektinhaber
01Orchestrator

Architektur

Architect

Implementierung

Coder

Senior Coder

Qualität

QA

02Senior Reviewer
FreigabeReparatur

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.

  1. 01

    Architekturmodell

    Plant die Änderung und ihre Grenze.

  2. 02

    Implementierungsmodell

    Schreibt die Änderung.

  3. 03

    Anderes Review-Modell

    Hinterfragt den Diff unabhängig.

  4. 04

    Reparatur

    Führt die Änderung zurück, bis das Review sauber ist.

  5. 05

    Deterministische Validierung

    Beweist den Endzustand mit festen Gates.

Führt die Änderung zurück, bis das Review sauber ist. Deterministische ValidierungBeweist 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.

  1. 01Menschlicher ProjektinhaberErgebnis und Autorität.
  2. 02OrchestrierungAufgabenbegrenzung und Übergänge.
  3. 03ArchitekturGrenz- und Designentscheidungen.
  4. 04ImplementierungBegrenzte Bauarbeit.
  5. 05Unabhängige PrüfungHerausforderung gegen den Auftrag.
  6. 06Sicherheit + ValidierungDeterministischer Nachweis.
  7. 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.

  1. 01

    Planen

    Begrenzte Aufgabe, Auftrag und Umfang werden offen definiert.

  2. 02

    Implementieren

    Eine Spezialrolle setzt gegen den Auftrag um.

  3. 03

    Review

    Ein unabhängiger Reviewer hinterfragt den tatsächlichen Diff.

  4. 04

    Reparieren

    Befunde führen zur Implementierung zurück, bis sie sauber ist.

  5. 05

    Erneut reviewen

    Der reparierte Zustand wird erneut geprüft — nie als behoben angenommen.

  6. 06

    Validieren

    Deterministische Gates laufen auf dem Endzustand.

  7. 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.

Wiederverwendbares EngineeringsystemProjekt-SSOTDomänen-PolicySicherheit + ValidierungProjektspezifische Lieferung

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.

    Geliefert
  • Buchhaltungs-Workflow-Delivery

    Számlaflow-Rechnungsverarbeitung, Audit und Validierung.

    Geliefert
  • Wiederverwendbare Übernahme in weiteren Kundendomänen

    Breitere Anwendung des Betriebsmodells über die heutigen Flächen hinaus.

    Entworfen
  • Breitere 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.