Skip to main content
Request demo

Architecture and deployment

A modular architecture for sovereign, isolated and federated training environments.

Scale the learning and control plane independently from range compute and high-volume telemetry while preserving clear authority, isolation and evidence boundaries.

Discuss your deploymentVisit the Trust Center

CLIP · Public-safe reference layers

Illustrative view
  1. 07Experience and access
  2. 06Learning, competency and exercise control
  3. 05Policy, identity and workflow
  4. 04Range and lab orchestration
  5. 03Isolated workloads and simulation
  6. 02Telemetry, evidence and analytics
  7. 01Operations, supply chain and assurance

Conceptual layers only. No deployable network detail is published.

Reference architecture

Seven layers with explicit responsibilities.

Layers are separated so that authority, blast radius and scaling behaviour are all explicit rather than emergent.

  1. 01Experience and accessPortal, workspace and remote-access termination.
  2. 02Learning, competency and exercise controlPathways, role profiles, scenario execution.
  3. 03Policy, identity and workflowAuthentication, authorization, approvals, target binding.
  4. 04Range and lab orchestrationTemplates, provisioning, isolation and lifecycle.
  5. 05Isolated workloads and simulationPer-exercise environments with default-deny egress.
  6. 06Telemetry, evidence and analyticsNormalisation, provenance, immutable artifacts, replay.
  7. 07Operations, supply chain and assuranceConfiguration, updates, SBOM and component risk.

Trust zones

Default-deny between zones.

Connectivity between management, learning, range, telemetry and evidence zones is denied unless explicitly authorized.

  • AccessNo direct access to range workloads
  • ManagementPrivileged, highly monitored and isolated
  • LearningNo implicit trust into range or evidence zones
  • Exercise controlController actions are authoritative and audited
  • Standard rangePer-exercise isolation and default-deny egress
  • High-risk rangeStronger isolation and an independent kill switch
  • SOC / DFIRControlled access to exercise telemetry and evidence copies
  • EvidenceAppend or controlled write; tightly restricted read and export
  • Content supply chainUntrusted content cannot bypass validation
  • External exchangeInspect, label and authorize every transfer

Deployment models

Five supported operating models.

Selecting a model changes isolation, update workflow and governance obligations — not the product's capabilities.

Fully disconnected operation for classified or otherwise isolated enclaves, updated through signed offline bundles.

Benefits

  • No public-Internet dependency for learning, range or evidence functions
  • Signed offline content and software update bundles with rollback metadata
  • Local model inference for AI-supported training

Considerations

  • Update cadence is governed by the offline transfer and quarantine process
  • Internal mirrors are required for packages, images and models
  • Time synchronisation must be provided inside the enclave for evidence quality

Reference scale profiles

Planning profiles, not capacity commitments.

These are starting points for infrastructure conversations. Final sizing must be validated by workload testing against your actual scenario topology.

Reference deployment profiles with indicative concurrent users and lab instances
ProfileIntended usePortal usersActive labs
P0 — Developer / PoCIntegration and demonstration2010
P1 — InstitutionUniversity, training centre or enterprise500100
P2 — Multi-institutionGovernment, defence or sector academy2,000400
P3 — Federated nationalMultiple sovereign regional ranges5,000+1,000+

Planning profiles only

These figures are architectural planning inputs. They are not performance claims, and they do not constitute a capacity commitment for any deployment.

Air-gap update lifecycle

Disconnected does not mean unmaintained.

Content and software reach a disconnected enclave through a signed, quarantined and reversible process.

  1. 01AcquireFrom an approved source.
  2. 02ValidateSchema, malware, licence and provenance.
  3. 03SignManifest and hashes recorded.
  4. 04TransferControlled offline movement.
  5. 05QuarantineNo use until validation completes.
  6. 06ReleaseApproved into the internal mirror.

In sequence: A bundle is acquired, validated against its manifest, signed, transferred into the enclave, quarantined until validation completes, released for use, and remains reversible through recorded rollback metadata.

Rollback metadata accompanies every bundle, so a release can be reversed without an external network dependency.

Interoperability

Open standards, backed by conformance tests.

Using a compatible file extension or endpoint name is not interoperability. Every claim below is intended to be demonstrated by a conformance test.

  • OpenID Connect / OAuth 2.x

    Baseline

    Identity

    Authentication and federation with the approved identity provider.

  • LTI 1.3 / LTI Advantage

    Conditional

    Learning launch

    Secure tool launch and result exchange where applicable.

  • xAPI / cmi5

    Conditional

    Learning activity

    Detailed laboratory and simulation event profiles.

  • Open Badges 3.0

    Conditional

    Credentials

    Verifiable completion and skill badges. Not regulated certification.

  • STIX 2.1 / TAXII 2.1

    Conditional

    Threat intelligence

    Threat and exercise-content exchange for approved use cases.

  • MITRE ATT&CK / D3FEND / ATLAS

    Baseline

    Technique mapping

    Scenario, detection and AI-threat mapping.

  • OpenTelemetry

    Baseline

    Observability

    Traces, metrics and context propagation across services.

  • SPDX / CycloneDX

    Baseline

    Software bill of materials

    Component transparency for distributed artifacts.

  • OpenAPI / AsyncAPI

    Baseline

    Interfaces

    Documented synchronous and asynchronous contracts.

Applicability is deployment-dependent

Standards listed here are engineering inputs, not certifications. Exact applicability depends on deployment scope, customer obligations and formal assessment.

Architecture questions

Common evaluator questions.

  • Can the range run without any public-Internet access?

    Yes. Core learning, range, evidence and reporting functions are designed to operate without public-Internet dependency, with updates delivered as signed offline bundles.

  • What happens to a running exercise if the central link fails?

    Federated sites are designed to continue local exercise execution during an approved wide-area disconnection. Analytics and reporting may degrade; safety controls do not.

  • Does the application hold infrastructure administrator credentials?

    No. Range lifecycle is reached through a narrow, least-privilege provider interface. The application never receives container-engine, cluster-admin or hypervisor credentials.

  • Can range compute scale separately from the control plane?

    Yes — that separation is an architectural requirement, so a large exercise does not degrade portal or evidence services.

  • How is evidence protected from a compromised exercise workload?

    The evidence zone accepts controlled writes only, and range workloads have no route to it. A compromise inside an exercise cannot alter sealed evidence.

Discuss your deployment.

Bring your isolation requirements, identity landscape and capacity expectations. We will work through the architecture against them.

Discuss your deploymentOpen-source ecosystem
Architecture and Sovereign Deployment | CLIP