Overview#
A platform engineering team managing a production deployment across multiple government tenants needs more than a checklist before releasing a schema change. They need to know which tenants will be affected, whether rollout gates have cleared, and how to roll back cleanly if something goes wrong. The Platform Control Plane provides that coordinated workspace: deployment console, release orchestration, ontology governance, and incident integration in one surface, so release decisions are based on verified readiness rather than optimistic assumptions.
The control plane is for organisations running the platform as critical infrastructure who need disciplined release, governance, and operational oversight rather than disconnected admin utilities.
Key Features#
- Deployment Console: Monitor rollout posture, environment readiness, and change execution from a dedicated deployment surface. Visibility into what has deployed, what is pending, and what needs attention before proceeding.
- Release Orchestration: Coordinate staged releases, readiness checks, approval gates, and rollout sequencing across environments. Releases do not proceed until gates confirm readiness at each stage.
- Ontology Studio: Manage governed changes to operational object models, managed types, and platform structure with visibility into downstream effects across dependent tenants and integrations.
- Developer Console: Expose the runtime and integration context needed for advanced diagnostics, extension work, and controlled platform operations without requiring direct database access.
- Agent Studio: Configure and supervise automation and operator-assistance services as managed platform capabilities rather than isolated scripts.
- Governance Snapshots: Capture point-in-time governance and deployment state for review, audit, and release confidence. Snapshots provide the evidence trail for regulated deployment environments.
- Incident Workflow Support: Connect control-plane actions to active operational workflows where change and incident management intersect, keeping platform operations and incident response coordinated.
Use Cases#
- Controlled Production Releases: Stage and govern platform changes with visibility into readiness, risks, and release sequencing across multiple tenant environments.
- Platform Model Governance: Evolve shared operational structures while maintaining confidence in compatibility and downstream impact for all connected organisations.
- Operational Diagnostics: Give platform operators a structured workspace for deep platform oversight and controlled intervention without resorting to ad hoc tooling.
- Automation Service Management: Supervise agent and developer-facing capabilities as managed services, with full audit trails and governance oversight.
Integration#
- Platform administration and deployment services
- Ontology and managed-object governance workflows
- Release approval, audit, and incident-management processes
- Developer tooling, automation, and observability systems
Open Standards#
- STIX 2.1 (OASIS CTI TC): Threat intelligence objects, indicators, malware records, attack patterns, threat actors, and campaigns, are represented and exchanged as STIX 2.1 bundles using the
application/stix+jsonmedia type, enabling bidirectional interoperability with any OASIS-compliant threat intelligence platform. - TAXII 2.1 (OASIS CTI TC): The platform polls and publishes STIX 2.1 indicator bundles via TAXII 2.1 collections (
application/taxii+json;version=2.1), allowing federated sharing of intelligence with partner platforms and national CERT networks without proprietary integration. - GraphQL (June 2018 specification): All platform queries, mutations, and real-time subscriptions are exposed exclusively through a Strawberry GraphQL API, providing a typed, introspectable, and version-stable contract for internal services and external SDK consumers.
- OAuth 2.0 (RFC 6749) and OpenID Connect 1.0: Platform authentication and delegated authorisation follow the OAuth 2.0 framework with PKCE (RFC 7636); identity tokens conform to the OpenID Connect Core 1.0 specification, enabling standards-based SSO and federated identity across tenants.
- NIEM 5.0 (National Information Exchange Model): Person, organisation, incident, and case management data exchanged with justice and emergency management partners is structured against NIEM 5.0 namespaces, producing independently verifiable JSON-LD objects consumable by any NIEM-aware system.
- CAP v1.2 (OASIS Emergency Management TC): Public safety alerts, natural disaster warnings, and CBRN notifications are ingested and published as Common Alerting Protocol v1.2 messages, enabling the same alert feed to reach both Argus and any other CAP-capable alerting platform.
- OWASP ASVS 5.0: Platform security controls are verified against OWASP Application Security Verification Standard 5.0 at L2 baseline across all services, with L3 applied to the authentication gateway and API layer; per-service compliance chapters are maintained under each repository's
docs/security/directory.
Last Reviewed: 2026-03-25 Last Updated: 2026-04-14