Skip to content

Operating Models

How your tenant is structured, isolated, and operated.

The operating model answers a question every regulated institution asks first: where does my data live, and who can touch it? The answer is built into the structure of the platform, not bolted on.

Your Tenant

You operate in your own Google Cloud tenant. That tenant is the authoritative home for your risk data, your execution, your evidence, your results, and your explainability. Vannarho operates a shared control plane that governs execution — but the control plane is not the authoritative store of your risk data. Available today.

flowchart LR
    A[Your systems and users] --> B[Governed API boundary]
    B --> C[Shared control plane: governs execution]
    C --> D[Your tenant: data, runtime, evidence, results]

The division of responsibility is deliberate:

  • The shared control plane handles authentication, authorisation, intake translation, run governance, dispatch, and Config Doctor.
  • Your tenant owns retained data, deterministic execution, evidence custody, canonical analytics, and your client-facing serving surfaces.

This is what lets you keep custody of your risk data and execution history while still consuming the platform as a managed service.

Isolation Is Structural

Isolation is enforced by the platform's structure, not by application convention. Available today.

Boundary How it isolates you
Project Your resources live in your own Google Cloud project
IAM Access is scoped by identity and workload identity
KMS Keys are managed and separable
Storage Evidence and artifacts are governed independently
Runtime Deterministic execution is isolated from API and experience layers
Analytics Your analytical truth is governed separately from mutable collaboration state

Adoption Journey

You adopt incrementally. A typical path is:

flowchart LR
    A[Your acceptance environment] --> B[Production cutover]
    B --> C[Expansion: richer analytics and operating packs]

You start with the capabilities you need, validate them in your own acceptance environment, move to production, and expand over time. There is no requirement to begin with the most complex target-state footprint.

Federated Multi-Geo (On The Roadmap)

For multinational groups, a federated model keeps raw data and execution local to each jurisdiction while allowing approved facts to aggregate for global review. On the roadmap.

flowchart TD
    A[Global governance view] --> B[Geo risk domain: Region A]
    A --> C[Geo risk domain: Region B]
    A --> D[Geo risk domain: Region C]

The principles, when delivered, will be:

  • raw data stays local
  • execution stays local
  • evidence stays local
  • only approved facts aggregate globally
  • global explanation consumes approved facts, not unrestricted raw data

This supports residency, sovereignty, and cross-border governance without collapsing all data into one jurisdiction.

What This Means For You

  • You keep custody. Your risk data, execution, and evidence stay in your tenant.
  • Isolation is provable, because it is enforced by Google Cloud project, IAM, and KMS boundaries.
  • You can grow into multi-geo as your footprint expands, without re-platforming.

Where The Platform Is Today

Single-tenant isolation with a shared, governing control plane is available today. The federated multi-geo operating model is on the roadmap — see Capability Maturity And Status.