OperativeOps

OperativeOps / Enterprise

Reading arc: 01 Mechanism02 Operation — this page03 Terms

Operation — written for the person on call

Installs from a compose file. Runs behind your firewall.

OperativeOps ships as containers you run — one host, a Kubernetes cluster, or fully air-gapped. This page is what you would be signing up to operate: install, sizing, upgrades, identity, and the code you can extend.

Nothing phones home · License check is offline

Fig. 01 — Topologies

Deployment options — as a spec, not a promise.

Three supported topologies. Sizing figures are the current reference configuration — your evaluation engineer validates them against your corpus before pilot.

Fig. 01 — Supported deployment topologies and their requirements
SpecificationA — Docker ComposeB — KubernetesC — Air-gapped
TargetEvaluation to small-team productionDepartment to company-wide, HAClassified or regulated networks
Installdocker compose uphelm install operativeopsSigned offline bundle, verified by hand
Nodes1 host3+ (control plane + workers)1 host or cluster
Reference sizing8 vCPU · 32 GB · 250 GB SSDper worker: 8 vCPU · 32 GBas A or B, + GPUs for local models
Network egressOptional — gated model API onlyOptional — gated model API onlyNone. Verified at the firewall.
Updatescompose pull · monthlyRolling via Helm, zero-downtimeSigned bundle, applied offline
High availabilityNot in this topologyReplicated services + PostgresAs deployed (A or B)
BackupVolume snapshot + pg_dumpVelero + pg_dump, tested restoreSame, to offline media

Fig. 02 — Model routing

Your models. Routed per agent.

The prompt goes where you decide — including to a model on your own GPUs. Routing is configuration, set per agent, changed without redeploying.

Model routing: each agent's policy sends its prompts either to a local runtime inside the perimeter (Ollama or vLLM, nothing leaves) or through a gated, logged egress to a hosted provider API (OpenAI, Anthropic, Azure OpenAI), where the prompt and retrieved passages do leave the network.YOUR PERIMETERagent.opspolicy: local onlyagent.engpolicy: anthropic apiagent.analyticspolicy: local onlyModel routingper agent · set by adminconfig, not codeLocal runtimeOllama · vLLM · your GPUsnothing leaves. ever.egress gate · TLS · loggedOpenAI APIAnthropic APIAzure OpenAIwhat crosses: prompt + retrievedpassages, under the provider's terms.
Fig. 02 — Routing policy · mixed fleets are normal

Local — Ollama · vLLMNothing leaves the network. Documents, embeddings, prompts and answers stay on your hardware. Required for air-gapped.

Hosted — OpenAI · Anthropic · Azure OpenAISomething does leave: the prompt and the retrieved passages inside it, over TLS, through the egress gate, every call logged. We say this plainly because a “zero data leakage” badge next to a cloud provider would be false.

Either wayYour keys, your endpoint, your choice per agent. Documents at rest, the vector store and the audit ledger never route anywhere.

Fig. 03 — Governance

Identity, roles, and access control.

SSO over SAML 2.0 or OIDC, provisioning via SCIM. Six roles, enforced everywhere — for this buyer the role matrix is a feature, so here it is in full.

Fig. 03 — Role permission matrix
CapabilityAdminAuditorAgent mgrEditorMemberGuest
Configure deploymentGrantedNot availableNot availableNot availableNot availableNot available
Grant agent scopesGrantedNot availableGrantedNot availableNot availableNot available
Approve agent actionsGrantedNot availableGrantedNot availableNot availableNot available
Read audit ledgerGrantedGrantedGrantedNot availableNot availableNot available
Export ledger to SIEMGrantedGrantedNot availableNot availableNot availableNot available
Manage connectors + sourcesGrantedNot availableNot availableGrantedNot availableNot available
Ask, with cited answersGrantedGrantedGrantedGrantedGrantedRead-only
Audited themselvesGrantedGrantedGrantedGrantedGrantedGranted

■ = granted · — = not available to the role · every grant and every use is a ledger entry

Fig. 04 — The SDK

Your systems. Your connector.

The ERP nobody has heard of still counts. Custom MCP connectors are TypeScript against the SDK — a tool definition, a scope declaration, and the audit call you get for free. They run in your deployment, reviewed by your people.

packages/sdk · TypeScript · Apache-2.0

connectors/warehouse-erp.ts
import { connector } from "@operativeops/sdk";

export default connector("warehouse-erp", {
  scopes: ["erp.read"],            // declared, not assumed
  tools: {
    "stock.lookup": async ({ sku }, ctx) => {
      ctx.audit("erp.stock.lookup", { sku });  // ledger entry
      return erp.query(
        "SELECT qty, site FROM stock WHERE sku = ?", [sku]
      );
    },
  },
});

A connector cannot exceed its declared scopes — the runtime enforces them, not the author.

Pointers

Threat model, cryptography, incident process and subprocessors live on the security page; the GDPR, EU AI Act, NIS2 and BSI C5 control mappings live in the compliance hub. We keep them there so your auditor reads one canonical version.

→ /security→ /compliance

Fig. 05 — The path in

From here to running.

  1. 01 · Weeks 1–2

    Technical evaluation

    The compose bundle, a sample corpus, and two working sessions with an OperativeOps engineer. On your hardware from day one.

  2. 02 · Weeks 3–4

    Security review

    Architecture dossier, threat model, current pen-test summary, and the DPA draft — everything your security team asks for, unprompted.

  3. 03 · Weeks 5–10

    Pilot

    One department, agreed success criteria, weekly reviews. Real documents, real permissions, real ledger from the first question.

  4. 04 · From week 11

    Rollout

    SSO cutover, runbooks, admin training, and a named engineer you can reach — the same one from step 01.

Next — 03 TermsWhat it costs →Tiers by deployment model, the full comparison table, procurement FAQ.Or — talk to a humanTalk to engineering →Not a sales call. Bring your architecture diagram and your hardest question.