Skip to main content

Architecture Overview and Interfaces

CDPG separates governance, data movement, and governed autonomous execution into three cooperating planes. The separation is about responsibility, not deployment: planes may share a cluster, but they do not share business ownership.

Status: Partially implemented. Control and Data Plane services are available with named gaps; the Agentic Plane is implemented for local integration but not deployable through GitOps. See Current & Target.

planes_and_interfaces · govern, serve, act
Actors enter through a shared gateway. The Control Plane governs identity-linked records, policy and decisions. The Data Plane executes governed data operations with carried decisions. The Agentic Plane obtains delegated authority and invokes tools through the normal gateway. Events and audit connect all planes.actors & public edgecontrol plane · govern & decidedata plane · enforce & deliveragentic plane · delegated executioncarried decision + obligationsaudit · usage · lifecycle eventssole egressidentity · grantsPeople / appsGateway · PEPauthenticate · route · enforceSources / providersIdentity recordsuser · org · agentCatalogueresources · discoveryPolicy · PAPauthor · revokeAuthorizationcompose · decideCommerce · registry · credits · audit · notifyNGSI-LDentity · temporalOGC APIsspatial · processesFile Exchangeobjects · jobsSubscriptionsstreams · deliveryquery compilation · filtering · metering · deliveryAgent RegistryAgent RuntimeMCP Gateway
actorsControl PlaneData PlaneAgentic Planeshared contracts & events

Platform goals

  • Enable providers to publish discoverable resources and control how they are used.
  • Enable consumers and applications to discover, obtain entitlement, and access data through standard APIs.
  • Preserve organization boundaries, provider ownership, auditability, and revocation across synchronous and asynchronous paths.
  • Support real-time, temporal, spatial, file, subscription, and standards-native access models.
  • Let agents act under narrow, time-bound, reviewable authority without turning model output into policy.
  • Run the same service images under centrally operated or configuration-selected federated topologies.

Actors and personas

ActorPrimary goalsPrincipal type
ConsumerDiscover, request, purchase, query, download, or subscribeUser or application
ProviderOnboard resources, upload data, publish products, grant and revoke accessUser within an organization
Organization administratorManage membership and govern organization-owned resourcesPrivileged user scoped to an organization
Platform operatorOperate infrastructure, registries, policy distribution, incidents, and auditPrivileged workload/user with narrowly scoped operations
Client applicationIntegrate programmatically without a human sessionApplication/workload principal
Agent ownerRegister an agent, delegate authority, approve risk, review activity, revokeUser
AI agentPropose tools within a delegation and templateAgent actor plus runtime workload
External providerSupply identity, payments, email, object storage, source data, or LLM capabilityExternal system with protocol-specific trust

Plane responsibilities

PlaneOwnsDoes not own
Control PlaneIdentity-linked profiles and organizations, resource metadata, grants, authorization decisions, commerce, registries, credits, audit, notifications, governanceResource payload delivery and model reasoning
Data PlaneIngestion, storage, query, spatial/temporal processing, files, subscriptions, data filtering and deliveryGrant authoring, identity issuance, global policy evaluation
Agentic PlaneAgent/template lifecycle, sessions, token exchange, tool mediation, HITL, kill switch, agent audit contextIndependent standing authority or direct datastore access
Shared platformCross-cutting service runtime, contracts, identity plumbing, events, persistence, cache, health, observability, resilienceBusiness rules or service-owned data

Standard interfaces

InterfacePurposePrimary ownersStatus
Identity (OIDC/OAuth 2.0)Authenticate users, applications, agents, and workloads; publish keys; exchange tokensKeycloak, Gateway, Agent RuntimeImplemented / Partially implemented
Discovery (JSON-LD/search)Register and find resource metadata and access capabilitiesCatalogueImplemented
Policy administrationCreate, validate, list, expire, and revoke grants and access requestsPolicy ServiceImplemented with projection gaps
AuthorizationAuthorize(subject, actor, operation, resource, context) → decision + obligationsGateway/application PEP, dx-authz-go, OpenFGA, OPAPlanned composite target
Resource accessNGSI-LD entity/temporal queries and subscriptionsData PlanePartially implemented
Geospatial accessOGC Features, Tiles, Coverages, Processes, RecordsOGC Data PlanePartially implemented
File exchangeMultipart upload, processing, listing, preview, download, object accessFile ExchangePartially implemented
Internal service APITyped, workload-authenticated calls between Go servicesgRPC platform surface and service protobufsIn development
Domain eventsVersioned facts and durable projectionsRabbitMQ, platform event bus, outboxesPartially implemented
Agent toolsDiscover and invoke schema-bound operations under delegation and risk policyMCP GatewayPartially implemented

Deployment models and configuration

  • Central: the full fleet runs behind one gateway in a Kubernetes cluster or local Compose environment.
  • Federated: selected data and trust components run in an independently operated network; this shape is Deferred until its trust and conformance gates close.
  • Feature gates: Agentic Plane and federation components are absent or disabled unless deliberately selected.
  • Persistence: new deployments provision service-owned databases/schemas through versioned Go migrations. Schema execution is an explicit deployment mode with one migration actor.
  • Environment: configuration is typed and environment-driven; secrets are injected by a secret manager and never committed.

Continue with System Architecture, then the Control Plane, Data Plane, Agentic Plane, and Security Architecture.