Modulkatalog
Olivares AI integriert, verwaltet und sichert KI im Unternehmen, eine Ground Truth: Claude Code auf der tiefsten Stufe, Codex und Grok Build daneben. Es ist eine modulare Plattform — eine Engine, eine Konsole und 30 Module, verdrahtet in einem einzigen Binary — die beobachtet, wo Agenten laufen, regelt, was sie tun dürfen, und (auf einer wachsenden Teilmenge) auf Ihrer realen Infrastruktur agiert. Jedes Modul (a) konsumiert normalisierte Events/Daten aus dem Core, (b) deklariert seine Entitäten im gemeinsamen Datenmodell und (c) stellt seine eigenen API-Endpunkte und UI-Ansichten bereit — ohne den Core oder andere Module zu berühren.
Die 30 Module sind nach den neun Capability-Bereichen unten organisiert.
Lesen Sie den Status jedes Moduls als zwei Hälften: Govern/Observe
(katalogisieren, beobachten, gaten, berichten) ist heute gebaut und verdrahtet;
Actuate (das Agieren auf realer Infrastruktur — deployen, dispatchen, senden,
durchsetzen, ausführen) fällt in ehrliche Zustände — live im Standard-Binary
für eine Teilmenge, on-demand für mehrere (das Backend ist gebaut und an
einen Injektionspunkt verdrahtet, bleibt aber deny-closed oder degradiert, bis
ein Operator es per Env-Konfiguration bereitstellt), PARTIAL, wo die
Oberfläche gegatet/opt-in ist, und eine deklarierte deny-closed Naht für den
Rest. Insbesondere plant und regelt deploy Deployments, wendet sie aber
nicht auf Live-Infrastruktur an, bis ein Executor bereitgestellt ist:
apply/retire liefern ein klares 503. Die Tiefe variiert je nach Modul, und
ein Großteil des Produkts ist pre-1.0 / im Designstadium, wo vermerkt (siehe
Ehrlichkeit & Grenzen).
Die access map (iii-access-map) — der Read-/Read-Write-Graph dessen, was
jeder Agent berühren kann und tatsächlich berührt, mit Least-Privilege-Drift =
Permitted ≠ Observed — ist eine der nützlichsten Capabilities unter den 30,
nicht das gesamte Produkt. Die Breite ist der Punkt: neun Bereiche, eine Engine,
eine Konsole.
Die 30 Module, nach Capability-Bereich
Abschnitt betitelt „Die 30 Module, nach Capability-Bereich“Jede Zeile verlinkt auf ihre Modulseite (/reference/modules/<slug>/). Die
Spalte Actuate ist der ehrliche Zustand der agierenden Hälfte; — bedeutet,
dass das Modul von Natur aus regelt/beobachtet und keine Actuation-Oberfläche
hat.
Observe
Abschnitt betitelt „Observe“| Modul | Actuate | Zweck |
|---|---|---|
| Inventar & Discovery | — | Entdecken und katalogisieren Sie jeden Agenten/jede Session/jeden MCP-Server/jedes Tool/Modell/jede Identität im Estate. |
| Live-Betrieb & Sessions | — | Echtzeitzustand jedes Agenten und jeder Session; beherbergt außerdem die geregelte Claude-Code-Session-Runtime. |
| Access- & Resource-Map (R/RW) | — | Worauf jeder Agent zugreift und ob er liest oder schreibt; Least-Privilege-Drift = Permitted ≠ Observed. |
| Orchestrierung & A2A | on-demand | Beobachten und regeln des Live-Delegations-/Kommunikationsgraphen; Dispatch ist on-demand verdrahtet, deny-closed bis bereitgestellt. |
| MCP, Skills & Capabilities | — | Die Tools und Capabilities der Agenten visuell regeln. |
| Health, SLA & Uptime | — | Zuverlässigkeit der Agenten und MCP-Server des Estates; Checks, Incidents, Abhängigkeitskarte. |
| Observability-Read-Model | — | Das Read-Model der Engine über sich selbst: fixierte Interop-Standards, W3C-korrelierte Ledger-/Trace-Sicht, Lieferketten-Attestation. |
| Claude-Code-Adoption | — | Read-Model der Claude-Code-Adoption/-Produktivität: Sessions, Lines of Code, Commits, PRs, Tool-Accept-Reject, Tokens pro Modell, nach Team/Entwickler/Tag; per Team als Standard, Drill-down pro Entwickler opt-in. Nur-Claude-API-Grenze; trägt nie Kosten. |
| Live-ingest | PARTIAL | In-Process-Produzent detektivischer Events, die ein Connector nicht emittieren kann; env-gegatet, deny-closed, minimal-data. |
Govern & enforce
Abschnitt betitelt „Govern & enforce“| Modul | Actuate | Zweck |
|---|---|---|
| Identität, Berechtigungen & Governance | — | Wer und was was tun darf, granular: Cedar RBAC + Deny-Overlay + scoped Grants, Roster-Abgleich, scoped Admin-/Custom-Rollen, Break-Glass, Kill-Switch. |
| Source- & Credential-Scoping | — | Quellen an einen Workspace/eine Agent-Gruppe binden; deny-closed scoped Resolver + scoped Credentials zum Auflösungszeitpunkt. |
| Deployment & Integration | on-demand (503) | Deployments auf reale Infrastruktur planen und regeln; der Executor ist on-demand — live apply/retire liefern 503, bis bereitgestellt. |
Identität & Zugriff lebt innerhalb der Governance — es gibt kein separates Modul. NHI-Lifecycle, Agent-Identity-Federation, AAL3-Step-up und SSO/SCIM sind Governance-Capabilities.
Claude- & Agenten-Ökosystem
Abschnitt betitelt „Claude- & Agenten-Ökosystem“| Modul | Actuate | Zweck |
|---|---|---|
| Modell- & Provider-Verwaltung | on-demand (503) | Über den gesamten Modell-/Provider-Stack regeln: Model-Access, Kontextfenster pro Oberfläche, Model-Group-Gate; die Modell-Ausführung ist on-demand — 503, bis ein Inferenz-Credential bereitgestellt ist. |
| Inline-Inferenz-Proxy | PARTIAL | Inferenz-Egress-Konfiguration pro Tenant + DLP für den Inline-/v1/messages-PEP-Proxy; die Modulkonfiguration ist live, der Listener ist opt-in, loopback-default, fail-CLOSED. |
| Interner Katalog & Marketplace | — | Kuratierter Marketplace genehmigter/signierter Agenten, MCP-Server und Skills. |
| Voice- & Realtime-Agenten | on-demand | Konversations-/Realtime-Agenten beobachten und regeln (default-DENY, zweiphasiges HITL); öffnet nie einen Media-Stream; Dispatch on-demand. |
Sicherheit & Datenschutz
Abschnitt betitelt „Sicherheit & Datenschutz“| Modul | Actuate | Zweck |
|---|---|---|
| Sicherheit, Guardrails & Audit | live | Guardrails (PII/Injection/Jailbreak), Anomalien, Incident-Timelines; BYOK/DLP/RTBF/Retention/WORM/Residency leben in dieser Ebene. |
| Aufzeichnung privilegierter Sessions | live | PAM-konforme Aufzeichnung privilegierter Sessions: hash-verkettete Frames, Maskierung beim Schreiben, ledger-verankert. |
| Daten, Wissen & Kontext | on-demand | Geregelte Datenebene: KBs + RAG, geregeltes Retrieval, Lineage, Prompt-Registry, Agent-Memory; modellgestützte semantische Embeddings sind on-demand. |
Compliance & Evidenz
Abschnitt betitelt „Compliance & Evidenz“| Modul | Actuate | Zweck |
|---|---|---|
| Compliance & Regulatorik | — | 26 Framework-Kataloge + versiegelte, ledger-abgeleitete Evidenz mit Live-Chain-Verify. |
| SIEM/ITSM-Forwarder | live | Versendet das versiegelte Ledger + Findings an SIEM-Towers (OCSF 1.8/CEF/LEEF/syslog/OTLP), leader-gegateter Cursor-Walk, at-least-once. |
| Posture-Export | PARTIAL | Schreibgeschützter Posture-/Inventar-Pull für Control-Towers (neutrales JSON); beansprucht keinen verifizierten Downstream-Push. |
| Reporting | — | Professionelle PDF-/HTML-Berichte aus den Compliance-, Audit- und FinOps-Daten der Plattform — fünf integrierte Berichtstypen; Auditoren laden ein Dokument herunter, statt JSON zu kopieren. |
| Modul | Actuate | Zweck |
|---|---|---|
| Cost & AI-FinOps | live | Agierende Budgets, die am Cap verweigern/drosseln, Cost-per-Outcome, Cancellation-Risk; Budget fest an die Identität gebunden. |
Evals & Safety
Abschnitt betitelt „Evals & Safety“| Modul | Actuate | Zweck |
|---|---|---|
| Qualität, Evals & Testing | — | Kalibrierter LLM-Judge + ein blockierendes CI-Regressions-Gate; Offline-Judge → SKIPPED, nie ein stiller Pass. |
| Agent-Sandbox | on-demand | Sichere Umgebung zum Testen von Agenten vor der Produktion; echte OS-Isolation (gVisor/Firecracker) ist on-demand. |
| Red-Teaming & Adversarial Testing | on-demand | Consent-gegatete Adversarial-Batterie; DEGRADED — nie ein falscher Pass — bis eine Sandbox-Runtime bereitgestellt ist. |
Plattform & Integrationen
Abschnitt betitelt „Plattform & Integrationen“| Modul | Actuate | Zweck |
|---|---|---|
| Output-Integrationen & Benachrichtigungen | live | Benachrichtigungs-Router zu den Systemen, die das Unternehmen bereits betreibt; Dispatch ist live verdrahtet, Ziele vom Operator bereitgestellt. |
| Eventing | live | Externe Subscription-Oberfläche über den Bus: typisierte Subscriptions, durable At-least-once-Delivery, Retry/Backoff, DLQ, Cursor-Replay. |
| Gespeicherte Konsolenansichten | — | Benannte, teilbare Snapshots des Konsolen-View-Zustands (Filter, Zeiträume), serverseitig pro Mandant gespeichert: eine Untersuchung speichern, mit dem Team teilen. Akzeptiert ein größenbegrenztes JSON-Objekt (4096 Bytes) für View-Parameter — keine sensiblen Daten oder Abfrageergebnisse darin speichern. Erstellen/Aktualisieren nur durch den Owner; Mandanten-Admins/-Owner und Superadmins können zum Aufräumen löschen; jede Mutation wird auditiert. |
Spalte Actuate: live = Actuation ist verdrahtet und live im Standard-Binary,
keine Bereitstellung nötig (z. B. die FinOps-Budgetdurchsetzung verweigert am
Cap, der Benachrichtigungs-Router dispatcht); on-demand / on-demand (503) =
das Backend ist gebaut und an einen Injektionspunkt verdrahtet, bleibt aber
deny-closed oder degradiert, bis ein Operator es bereitstellt per
Env-Konfiguration (deploy antwortet mit 503, bis ein Executor existiert;
Orchestrierungs-/Voice-Dispatch ist deny-closed, bis konfiguriert; Red-Team läuft
DEGRADED, bis eine Sandbox-Runtime bereitgestellt ist; Modell-Ausführung und
semantische Embeddings liefern 503, bis ein Credential bereitgestellt ist);
PARTIAL = die Oberfläche ist real, aber gegatet/opt-in oder beansprucht keinen
verifizierten Downstream (der Inferenz-Proxy-Listener ist opt-in und
loopback-default; live-ingest ist env-gegatet; posture-export ist eine neutrale
schreibgeschützte Projektion); — = das Modul regelt/beobachtet von Natur aus
und hat keine Actuation-Oberfläche. Dieser Split ist der ehrliche Vertrag: das
Produkt beobachtet und regelt heute breit und agiert auf einer wachsenden,
überwiegend bereitstellungs-gegateten Teilmenge — siehe
Ehrlichkeit & Grenzen. Der Katalog ist aus dem
Composition-Root abgeleitet (cmd/olivares/wire.go): alle 30 Module werden dort
konstruiert und via rt.AddModule registriert (verifiziert am 2026-08-01,
main @ f632f03f).
Plattform- & Core-Capabilities (nicht zu den 30 Modulen gezählt)
Abschnitt betitelt „Plattform- & Core-Capabilities (nicht zu den 30 Modulen gezählt)“Dies sind reale, ausgelieferte Capabilities, aber es sind
Engine-/Core-/Web-Capabilities, keine Module aus dem modules/-Set — daher
werden sie nicht zu den 30 gezählt:
- Eigene API + Manage-as-Code — Engine-/Core-Capability. Die eigene versionierte REST-/gRPC-API der Engine plus der Terraform-Provider; verwalten Sie die Plattform selbst per API und IaC.
- Mandantenfähigkeit & Org-Verwaltung — Engine-/Core-Capability. Org-Hierarchie und delegierte Administration, mit Postgres-Row-Level-Security-Mandantentrennung.
- Executive-Dashboards — Web-Capability. Leadership-Konsolenansichten neben der technischen UI. (Das Backend für die Berichtserzeugung ist das Modul Reporting, das zu den 30 gezählt wird.)
- Modellbetrieb (eigene Modelle) — Capability des Models-Moduls (über die Zeile von Modul X gezählt, keine eigene Zeile): die governte Registry eigener Modelle, Admission signierter Modelle, Lineage-Datensätze für Datasets/Fine-Tuning-Jobs, Governance lokaler Inferenz-Deployments und AIBOM-/Model-Card-Belege.
Geplant: die Ausführung von Eigenmodell-Fine-Tuning und lokaler Inferenz (xxiii-fine-tuning) — die Plattform governt und erfasst diese Arbeit heute (siehe Modellbetrieb oben), führt aber selbst kein Training aus und bedient keine Inferenz; die ausführende Hälfte ist dokumentierte geplante Arbeit, nicht ausgeliefert und keines der 30.
Wie Module in der API und im Bus erscheinen
Abschnitt betitelt „Wie Module in der API und im Bus erscheinen“- REST. Die API-Referenz rendert die stabile Core-REST-Oberfläche
aus dem OpenAPI-3.1-Vertrag des Produkts. Die Modulrouten (
/v1/m/<ns>/…) werden separat als Beta-Dokument veröffentlicht — in der Modulrouten-Referenz; ihre feldgenauen Verträge leben in den typisierten Schnittstellen des Produkts. - Events. Module reagieren auf den Event-Bus: die
access map konsumiert
edge.observed, FinOps konsumiertcost.sampled, und Security konsumiertfinding.reportedundguardrail.observed.
Schichten
Abschnitt betitelt „Schichten“Die 30 Module bauen auf Schichten über der Engine auf, neben den oben genannten Engine-/Core- und Web-Capabilities:
- Engine (Schicht 0) — die Capabilities Eigene-API/Manage-as-Code und Mandantenfähigkeit (Core, nicht zu den 30 gezählt).
- Core (Schicht 1) — inventory, sessions, access-map, models, health, observability.
- Management (Schicht 2) — capabilities, governance, sourcescope, deploy, knowledge.
- Intelligence (Schicht 3) — orchestration, security, recording, inference proxy, finops, evals, compliance, reporting, siemforward, posture-export, catalog, notify, eventing, voice, sandbox, redteam, live-ingest, consoleviews.
- Web (Schicht 4) — die UI und die Executive-Dashboards-Capability.
Siehe die Architektur-Übersicht dazu, wie die Engine und diese Schichten zusammengesetzt werden.