As Global Advisors' AI estate expanded, the firm built a control-plane approach to describe services, relationships, ownership, routes, management methods, dependencies and validation evidence in versioned artefacts. The objective was to prevent rapid experimentation from becoming an ungovernable set of endpoints and hidden operational assumptions.

This work connected architecture, service management, security evidence, data control and change history. It made the difference between “software exists” and “capability is known, managed and verified” explicit.

Maturity: implemented and actively used across significant parts of the estate; coverage, reconciliation and institutional ownership continue to mature.

AI platform growth creates unusual governance pressure. New model endpoints, retrieval workers, agents, data services and user interfaces can be added faster than traditional architecture processes update. The result may be impressive demonstrations but weak knowledge of:

• what is running and where responsibility sits;
• which applications call which services;
• how access and secrets are managed;
• whether a declared endpoint is actually usable;
• which version or configuration produced an output;
• what breaks when a component changes; and
• which experimental capability has become operational by accident.

Global Advisors needed governance that moved at implementation speed and was useful to both people and agents.

We treated architecture records as versioned operational artefacts. The control plane combines:

• service manifests: canonical identities, roles, owners and maturity;
• relationship maps: upstream, downstream and cross-initiative dependencies;
• route and interface records: declared access paths without embedding them throughout applications;
• management-pattern classification: how a service can be configured, observed, backed up or recovered;
• architecture decisions: the rationale and trade-offs behind durable choices;
• validation evidence: tests that show whether the declared capability works;
• change history and handover: what changed, why, how it was checked and what remains; and
• security and dependency evidence: component, image and software-supply-chain visibility.

The control plane is not a single dashboard. It is a governed set of machine-readable and human-readable records from which views and checks can be produced.

• A conceptual model connecting inference, knowledge, agents, workflows, applications and governance;
• canonical service and route manifests;
• per-service operating notes and validation history;
• explicit management categories reflecting how deeply each service could be controlled;
• repository-level instructions, standards and handover requirements;
• dependency and component inventory practices for internally operated software;
• metadata and catalogue surfaces for technical discovery;
• control records for data sources, provenance and analytical artefacts;
• reconciliation checks between declared architecture and observed state;
• fail-closed patterns where identity, scope, evidence or an approved route was incomplete; and
• public-disclosure rules separating useful capability explanation from sensitive topology.

The architecture work was designed to enable change as well as review it. Agents and engineers could use the same records to discover the approved integration path, understand dependencies, find the relevant source-of-truth file and verify a result.

This reduces a common failure of architecture governance: diagrams that are polished but operationally inert. A machine-readable service record can drive validation; a repository instruction can constrain an agent; a change log can preserve context; and a dependency inventory can trigger a focused response.

Centralisation and federation must be balanced

One central record improves discovery, but product repositories retain essential local truth. The control plane points to and reconciles sources rather than copying every detail into one giant document.

Public proof and operational security conflict

Demonstrating depth can tempt organisations to publish exact topology or weaknesses. We developed a capability-level disclosure approach: explain architecture patterns, difficult lessons and controls while withholding host, route, credential and exploit-relevant detail.