Skip to content
Olivares AI docs

Modules catalog

Olivares AI integrates, manages and secures AI in the enterprise, one ground truth: Claude Code at the deepest level, Codex and Grok Build alongside. It is a modular platform — one engine, one console, and 35 selectable modules in the catalog — that observes where agents run, governs what they are allowed to do, and (on a growing subset) acts on your real infrastructure. Every module (a) consumes normalized events/data from the core, (b) declares its entities in the shared data model, and (c) exposes its own API endpoints and UI views — without touching the core or other modules.

These 35 selectable modules are implemented by 32 module packages; the governance package provides four separately selectable modules. They are organized by the nine capability areas below. Read each module’s status as two halves: Govern/Observe (catalog, observe, gate, report) is built and wired today; Actuate (acting on real infrastructure — deploy, dispatch, send, enforce, run) falls into honest states — live in the default binary for a subset, on-demand for several (the backend is built and wired to an injection point but stays deny-closed or degraded until an operator provisions it via env config), PARTIAL where the surface is gated/opt-in, and a declared deny-closed seam for the rest. In particular deploy plans and governs deployments but does not apply them to live infrastructure until an executor is provisioned: apply/retire return a clear 503. Deploy is a Business feature; Community answers 501 on every deploy route. Depth varies by module, and much of the product is pre-1.0 / design-stage where noted (see Honesty & limits).

The access map (iii-access-map) — the read/read-write graph of what each agent can and does touch, with least-privilege drift = Permitted ≠ Observed — is one of the most useful capabilities among the 35, not the whole product. The breadth is the point: nine areas, one engine, one console.

The 35 selectable modules, by capability area

Section titled “The 35 selectable modules, by capability area”

Each row links to its module page (/reference/modules/<slug>/). The Actuate column is the honest state of the acting half; — means the module governs/observes by nature and has no actuation surface.

Observe

Section titled “Observe”
Module Actuate Purpose
Inventory & discovery — Discover and catalog the agents, sessions, MCP servers, tools, models and identities that connectors observed.
Live operation & sessions — Real-time state of each agent and session; also hosts the governed Claude Code session runtime.
Access & resource map (R/RW) — What each agent accesses, and whether it reads or writes; least-privilege drift = Permitted ≠ Observed.
Orchestration & A2A on-demand Observe-and-govern the live delegation/communication graph; dispatch is wired on-demand, deny-closed until provisioned.
MCP, skills & capabilities — Govern agents’ tools and capabilities, visually.
Health, SLA & uptime — Reliability of the estate’s agents and MCP servers; checks, incidents, dependency map.
Observability read-model — The engine’s read-model of itself: pinned interop standards, W3C-correlated ledger/trace view, supply-chain attestation.
Claude Code adoption — Read-model of Claude Code adoption/productivity: sessions, lines of code, commits, PRs, tool accept-reject, per-model tokens, by team/developer/day; per-team default, per-developer drill-down opt-in. Claude-API-only boundary; never carries cost.
Live-ingest PARTIAL In-process producer of detective events a connector can’t emit; env-gated, deny-closed, minimal-data.

Govern & enforce

Section titled “Govern & enforce”
Module Actuate Purpose
Identity, permissions & governance — Who and what can do what, granular: Cedar RBAC + deny-overlay + scoped grants, roster reconciliation, scoped admin/custom roles, break-glass, kill-switch.
Identity (identity) — Read-only workload identity federation, SSO, external-key and residency posture.
Source & credential scoping — Bind sources to a workspace/agent-group; deny-closed scoped resolver + scoped credentials at resolution time.
Deployment & integration Business, on-demand (503) Business feature: Community answers 501. Plan and govern deployments to real infrastructure; the executor is on-demand — live apply/retire return 503 until provisioned.
Governed Git publication on-demand Push commits, open pull requests and merge through approved Git-host bindings, with current caller authority and retained intent outcomes.

Identity is a separately selectable module for the read-only identity posture console. It shares the governance package and requires governance, which owns the authorization model and identity lifecycle. A shared package does not mean a shared module switch.

Claude & agent ecosystem

Section titled “Claude & agent ecosystem”
Module Actuate Purpose
Claude Code managed policy (claude-policy) — Validate and preview managed policy; Business publishes it fleet-wide and inspects distribution and observed drift.
Claude agent confirmations (claude-agents) — Read managed-agent thread events and approve or reject a pending tool confirmation.
Skills catalog & assignments — Immutable skills catalog and pinned assignments: digest-validated skill packs installed under /v1/m/skills/packs, pinned per target, never edited in place.
Model & provider management on-demand (503) Govern across the whole model/provider stack: model-access, per-surface context-window, model-group gate; model execution is on-demand — 503 until an inference credential is provisioned.
Inline inference proxy PARTIAL Per-tenant inference-egress config + DLP for the inline /v1/messages PEP proxy; module config is live, the listener is opt-in, loopback-default, fail-CLOSED.
Internal catalog & marketplace — Curated marketplace of approved/signed agents, MCP servers and skills.
Voice & realtime agents on-demand Observe-and-govern conversational/realtime agents (default-DENY, two-phase HITL); never opens a media stream; dispatch on-demand.

Security & data protection

Section titled “Security & data protection”
Module Actuate Purpose
Security, guardrails & audit live Guardrails (PII/injection/jailbreak), anomalies, incident timelines; BYOK/DLP/RTBF/retention/WORM/residency live in this plane.
Privileged-session recording live PAM-aligned recording of privileged sessions: hash-chained frames, redact-on-write, ledger-anchored.
Data, knowledge & context on-demand Governed data plane: KBs + RAG, governed retrieval, lineage, prompt registry, agent memory; model-backed semantic embeddings are on-demand.

Compliance & evidence

Section titled “Compliance & evidence”
Module Actuate Purpose
Compliance & regulatory — 26 framework catalogs + sealed, ledger-derived evidence with live chain-verify.
SIEM/ITSM forwarder live Ships the sealed ledger + findings to SIEM towers (OCSF 1.8/CEF/LEEF/syslog/OTLP), leader-gated cursor walk, at-least-once.
Posture export PARTIAL Read-only posture/inventory pull for control towers (neutral JSON); does not claim a verified downstream push.
Reporting — Professional PDF/HTML report generation from the platform’s compliance, audit and FinOps data — five built-in report types; an auditor downloads a document instead of copy-pasting JSON.

FinOps

Section titled “FinOps”
Module Actuate Purpose
Cost & AI FinOps live Acting budgets that deny/throttle at the cap, cost-per-outcome, cancellation-risk; budget firm to identity.

Evals & safety

Section titled “Evals & safety”
Module Actuate Purpose
Quality, evals & testing — Calibrated LLM-judge + a blocking CI regression gate; offline judge → SKIPPED, never a silent pass.
Agent sandbox on-demand Safe environment to test agents before production; real OS isolation (gVisor/Firecracker) is on-demand.
Red-teaming & adversarial testing on-demand Consent-gated adversarial battery; DEGRADED — never a false pass — until a sandbox runtime is provisioned.

Platform & integrations

Section titled “Platform & integrations”
Module Actuate Purpose
Output integrations & notifications live Notification router to the systems the company already runs; dispatch is wired live, destinations operator-provisioned.
Eventing live External subscription surface over the bus: typed subscriptions, durable at-least-once delivery, retry/backoff, DLQ, cursor replay.
Saved console views — Named, shareable snapshots of console view state (filters, ranges), stored server-side per tenant: save an investigation, share it with the team. Accepts a size-capped (4096-byte) JSON object intended for view parameters — do not store sensitive data or query results in it. Create/update are owner-only; tenant admins/owners and superadmins can delete for cleanup; every mutation is audited.

Actuate column: live = actuation is wired and live in the default binary, no provisioning required (e.g. FinOps budget enforcement denies at the cap, the notification router dispatches); on-demand / on-demand (503) = the backend is built and wired to an injection point but stays deny-closed or degraded until an operator provisions it via env config (deploy, a Business feature, answers 501 in Community and 503 until an executor exists; orchestration/voice dispatch is deny-closed until configured; red-team runs DEGRADED until a sandbox runtime is provisioned; model execution and semantic embeddings return 503 until a credential is provisioned); PARTIAL = the surface is real but gated/opt-in or does not claim a verified downstream (the inference-proxy listener is opt-in and loopback-default; live-ingest is env-gated; posture-export is a neutral read-only projection); — = the module governs/observes by nature and has no actuation surface. This split is the honest contract: the product observes and governs broadly today, and actuates on a growing, mostly provision-gated subset — see Honesty & limits. The selectable catalog comes from core/modulespec/modules.json, the same source used by olivares modules ls and the console’s Edition & modules list. npm run test:modules checks each selectable namespace for a linked reference page and verifies the count.

Edition availability seam (not counted among the 35 selectable modules)

Section titled “Edition availability seam (not counted among the 35 selectable modules)”

The catalog above covers the 35 selectable modules in the shared module spec. Separately, Community registers an availability descriptor under the session-cockpit API namespace. It is not one of those 35.

Platform & core capabilities (not counted among the 35 selectable modules)

Section titled “Platform & core capabilities (not counted among the 35 selectable modules)”

These are real, shipped capabilities, but they are engine/core/web capabilities, not separately selectable modules — so they are not counted in the 35:

  • Own API + manage-as-code — Engine/core capability. The engine’s own versioned REST/gRPC API plus the Terraform provider; manage the platform itself by API and IaC.
  • Multi-tenancy & org management — Engine/core capability. Org hierarchy and delegated admin, with Postgres row-level-security tenant isolation.
  • Executive dashboards — Web capability. Leadership console views alongside the technical UI. (Its report-generation backend is the reporting module, which IS counted among the 35.)
  • Model operations (own models) — Capability of the models module (counted through module X’s row, not a separate row): the governed registry of owned models, signed-model admission, dataset/fine-tune-job lineage records, local-inference deployment governance and AIBOM/model-card evidence.

Planned: own-model fine-tuning and local-inference execution (xxiii-fine-tuning) — the platform governs and records that work today (see model operations above) but does not run training or serve inference itself; the executing half is documented planned work, not shipped and not one of the 35.

How modules show up in the API and the bus

Section titled “How modules show up in the API and the bus”
  • REST. The API reference renders the stable core REST surface from the product’s OpenAPI 3.1 contract. The module routes (/v1/m/<ns>/…) are published separately as a beta document — the module-route reference; their field-level contracts live in the product’s typed interfaces.
  • Events. Modules react to the event bus: the access map consumes edge.observed, FinOps consumes cost.sampled, and security consumes finding.reported and guardrail.observed.

Layers

Section titled “Layers”

The 35 selectable modules build on layers over the engine, alongside the engine/core and web capabilities above:

  • Engine (layer 0) — the own-API/manage-as-code and multi-tenancy capabilities (core, not counted in the 35).
  • Core (layer 1) — inventory, sessions, access-map, models, health, observability.
  • Management (layer 2) — capabilities, governance, identity, claude-policy, claude-agents, skills, sourcescope, deploy, gitpublish, knowledge.
  • Intelligence (layer 3) — orchestration, security, recording, inference proxy, finops, evals, compliance, reporting, siemforward, posture-export, catalog, notify, eventing, voice, sandbox, redteam, live-ingest, consoleviews.
  • Web (layer 4) — the UI and the executive-dashboards capability.

See the architecture overview for how the engine and these layers compose.