Skip to content

Control Plane — Overview

Target

This page describes intended behaviour or structure. No implementation is claimed unless a section is explicitly marked Current implementation or Evidence.

Rewritten 2026-10-09 (design plan P1)

This page replaces the June-2026 overview, which described ten bounded contexts and sixteen independently deployed MassTransit services. The 2026 design keeps the responsibilities, moves identity, policy and audit to their canonical owners, merges the orchestration rows into one run authority and ships the platform as a single modular host. The June-2026 catalog pages are archived under catalogs 2026-06.

The Control Plane is the administrative and authoritative center of the Factory. It defines desired state (projects, environments, published releases, budgets, subscriptions) and it is the single authority for the state that makes a run trustworthy (run, step, attempt, lease, approval). The runtime executes an immutable snapshot derived from it; the Studio reads from it; every other platform consumes its events.
Platform PF-01 Control Plane (Control)
Bounded contexts BC-01, BC-03, BC-04, BC-05, BC-32, BC-33, BC-34
Services 29 (1 hosts, 19 modules, 8 external, 1 later) — 8 modelled
Gateways GW-01, GW-03
Status target

Purpose

Every piece of work in the Factory is a run submitted by a trusted scope, pinned to immutable assets, gated by policy, paid for from a budget and observable end to end. The Control Plane exists so that those five properties hold by construction rather than by convention:

  • Scope is trusted. Tenant, project, environment and requester come from the authenticated context under canonical ADR-0100 and ADR-0101; no prompt, header or payload supplies them.
  • Assets are immutable. A run pins a release id, a policy revision, a model profile and a resolved snapshot at acceptance; aliases select, they never mutate.
  • Decisions are exact. An approval authorizes one action on one proposal version, by an eligible person who is not the requester, before it expires (ADR-0014, D21).
  • Spend is reserved first. A run has budget before its first step is dispatched, and unknown usage is reconciled, never zeroed.
  • Truth is committed. Every transition and its outbox record commit in one transaction (ADR-0012).

Bounded contexts and services

Context Owns Services (granularity)
BC-01 Project & Environment Projects, memberships, delegations, source scope, policy overrides; environments with policy classes and freeze state ProjectService, EnvironmentService (modules); ModuleCatalogService, DependencyService merged into ProjectService
BC-03 Run Control Run, step, attempt, lease, approval request and decision, cancellation, recovery journal RunControlService (module); WorkflowOrchestrator, TaskAssignmentService, ProcessStateService, AgentTaskService, ApprovalService, ReviewCenterService merged; WorkflowReplayService later
BC-04 Asset Publication Immutable releases with closure, hashes, evaluation evidence; aliases; A2A agent cards AgentRegistryService, AgentCardService (modules); SkillRegistryService, WorkflowDefinitionService merged
BC-05 Usage Accounting Budgets, reservations, usage records, pricing revisions, reconciliation CostUsageService (module); QuotaService, CostTelemetryService merged
BC-34 Factory Commercial Editions, subscriptions, invoices, period meters for the Factory itself FactoryCommercialService (module on the SaaS templates)
BC-32 Identity & Access (external) Authentication, tokens, workload identities IdentityService, AuthorizationService, ServiceIdentityService, ApiTokenService — canonical Identity Platform
BC-33 Tenancy & Entitlements (external) Tenants, editions, subscriptions, feature flags TenantService, EditionService, SubscriptionService (SaaS templates), FeatureFlagService (Config Platform)
Host Process composition, edge enforcement, transactional infrastructure ControlPlaneApi (standalone)
Service Context Granularity Status
AgentCardService BC-04 module of host target
AgentRegistryService BC-04 module of host target
AgentTaskService BC-03 module of host unmodelled
ApiTokenService BC-32 external / canonical unmodelled
ApprovalService BC-03 module of host unmodelled
AuthorizationService BC-32 external / canonical unmodelled
ControlPlaneApi BC-01 standalone host target
CostTelemetryService BC-05 module of host unmodelled
CostUsageService BC-05 module of host target
DependencyService BC-01 module of host unmodelled
EditionService BC-33 external / canonical unmodelled
EnvironmentService BC-01 module of host target
FactoryCommercialService BC-34 module of host target
FeatureFlagService BC-33 external / canonical unmodelled
IdentityService BC-32 external / canonical unmodelled
ModuleCatalogService BC-01 module of host unmodelled
ProcessStateService BC-03 module of host unmodelled
ProjectService BC-01 module of host target
QuotaService BC-05 module of host unmodelled
ReviewCenterService BC-03 module of host unmodelled
ServiceIdentityService BC-32 external / canonical unmodelled
SkillRegistryService BC-04 module of host unmodelled
SubscriptionService BC-33 external / canonical unmodelled
TaskAssignmentService BC-03 module of host unmodelled
TenantService BC-33 external / canonical unmodelled
WorkflowDefinitionService BC-04 module of host unmodelled
RunControlService BC-03 module of host target
WorkflowOrchestrator BC-03 module of host unmodelled
WorkflowReplayService BC-03 later stage unmodelled

Role in the Factory

flowchart LR
    Studio["Factory Studio BFF<br/>PF-14"] -- "commands and reads via GW-03" --> CP["Control Plane<br/>PF-01"]
    Partners["Partner and customer agents<br/>A2A via GW-01"] --> CP
    CP -- "leases, snapshots, release loading" --> Mesh["Agent Mesh<br/>PF-02"]
    Mesh -- "attempt outcomes, approval requests" --> CP
    Mesh --> MC["Model & Compute<br/>PF-03"]
    Mesh --> Tools["Tools & MCP<br/>PF-05"]
    MC -- "model receipts" --> CP
    Tools -- "tool receipts" --> CP
    CP -- "policy decisions" --> Gov["Governance<br/>PF-12"]
    CP -- "events on the envelope" --> Obs["Observability<br/>PF-13"]
    CP -- "desired deployments" --> RC["Runtime Cloud<br/>PF-09"]
    CP -- "meters" --> Commercial["Factory Commercial<br/>BC-34 in PF-01"]
Hold "Alt" / "Option" to enable pan & zoom

The Control Plane is the conductor, not the orchestra: it never calls a model, runs a tool or touches a repository. Those are the Agent Mesh, Model & Compute and Tools & MCP platforms, which act only on a lease issued here and report back only to the lease holder's authority here.

Component view

flowchart LR
    subgraph P["Control Plane"]
        ControlPlaneApi["ControlPlaneApi"]
    end
    GW_01{"GW-01 Edge ingress"} --> P
    GW_03{"GW-03 Platform domain APIs"} --> P
    P --> IntegrationService["IntegrationService"]
    P --> ext_azure_devops["ext-azure-devops"]
    P --> QualityScoreService["QualityScoreService"]
    P --> ArtifactService["ArtifactService"]
    P --> ext_identity_platform["ext-identity-platform"]
    P --> ext_config_platform["ext-config-platform"]
    P --> GovernanceHost["GovernanceHost"]
    P --> ext_saas_templates["ext-saas-templates"]
    P --> RuntimeEnvironmentService["RuntimeEnvironmentService"]
    P --> PolicyEngineService["PolicyEngineService"]
    P --> WorkflowEngineService["WorkflowEngineService"]
    P --> AgentRuntimeService["AgentRuntimeService"]
    P --> AuditService["AuditService"]
Hold "Alt" / "Option" to enable pan & zoom

The microservices catalog shows the container view (host and modules), and each service page carries its own context diagram, aggregates, DDL, APIs, events, workers, options, metrics, security, dependencies and failure modes.

Built from the ConnectSoft estate

The platform is assembled from components that exist, are extended or must be developed (ecosystem composition, D45):

Component Use here Status
API Gateway template (GW-01, GW-03) Public API and Studio BFF ingress, rate limits, token relay exists
Microservice template (BaseTemplate) with SaaS, NHibernate and Orleans messaging switches ControlPlaneApi host and every module exists
Authorization Server (OpenIddict) and Identity microservice Tokens, roles, workload identities (BC-32) exists
SaaS templates: Tenants, ProductsCatalog, Entitlements, Billing, Metering BC-33 externals and BC-34 FactoryCommercialService extend
Config Platform Feature flags and runtime configuration (FeatureFlagService) extend
MessagingModel port with the Orleans outbox/inbox adapter Transactional events of every module extend
Audit.NET integration Command and decision audit to BC-19 exists
Run authority, publication, usage accounting modules The Control Plane itself develop

Modernization (2 to 3 year horizon)

  • A2A (ADR-0023): agent cards and task lifecycle are a Control Plane projection (AgentCardService), so partner agents discover and call Factory agents without a second control path.
  • MCP (ADR-0022): MCP servers are published assets with descriptors in the release closure; the Control Plane pins them, Tools & MCP executes them.
  • Workload identity: runtime workers and partner callers carry SPIFFE-style identities issued by the Authorization Server; per-run tokens are derived from the lease.
  • Evaluation-driven release (D32): no asset is Published without an evaluation record that meets the profile's thresholds.
  • Durable execution: the Control Plane records truth; the durability of long-running agent execution is decided in the Agent Mesh (P2 spike), not here.

Current implementation

No Control Plane exists: there is no project, run, approval, release or usage API in any ConnectSoft repository. The tenancy primitives (ConnectSoft.Extensions.Saas.*), the Authorization Server, the Identity microservice, the SaaS templates and the microservice template exist and are not bound into any Factory execution. See the plane index for the evidence summary.

Final-state summary

In the final state the Control Plane is one ASP.NET Core host (ControlPlaneApi) built from the ConnectSoft microservice template, running six domain modules over one SQL store with disjoint schemas, an Orleans silo for run grains, the MessagingModel outbox and inbox, and the canonical identity and tenancy foundations. It is the authority that turns intent into governed, pinned, paid-for and observable runs, and it is extracted into separate hosts only on documented triggers.