Domains & Topics

Balcony's unified control framework organises AI governance into twelve domains. Every control, expectation node, and mechanism in the platform sits within this structure. The domains are your primary navigation layer across both Nexus and Mechanic.

Each domain has a two-letter code, a consistent colour in the UI, and a set of numbered topics that group related governance concerns.

[Screenshot needed] PLACEHOLDER IMAGE: A visual layout of all twelve governance domains as coloured tiles, each showing the domain code (GL, RM, DL, etc.) and name, arranged to convey the full scope of the framework at a glance

The twelve domains

Code	Domain	Governance territory
GL	Governance & Leadership	Board oversight, governance structures, accountability frameworks, ethical principles
RM	Risk Management	Risk identification, assessment, classification, mitigation, and monitoring
DL	Data & Learning	Data governance, data quality, training data, system design and development
SA	Safety	Safety assessment, fail-safes, resilience, operational safety measures
SE	Security	Cybersecurity, access control, adversarial robustness, system integrity
HO	Human Oversight	Human-in-the-loop, override capability, autonomy calibration, user interfaces
PR	Privacy	Data protection, consent, anonymisation, privacy impact assessments
OM	Operational Management	Deployment, monitoring, maintenance, change management, documentation
IM	Incident Management	Detection, response, notification, root cause analysis, remediation
SC	Supply Chain	Third-party assessment, vendor governance, procurement requirements, sub-processor management
RO	Reporting & Obligations	Regulatory reporting, transparency, registration, conformity declarations
AA	Audit & Assurance	Internal audit, external audit, conformity assessment, evidence management

Topics within domains

Each domain is subdivided into numbered topics that group related governance concerns. Topics give you finer-grained navigation within a domain without jumping directly to individual controls.

For example, within the Data & Learning domain (DL):

• DL-1 — Data Governance
• DL-2 — System Design

Topics are numbered sequentially within their domain: GL-1, GL-2, RM-1, RM-2, and so on. The topic number does not carry inherent significance beyond its position in the domain.

Controls within topics

Each topic contains the actual controls — specific, actionable governance requirements. Controls are the leaf level of the framework hierarchy, numbered within their topic: DL-1-1, DL-1-2, and so on.

Controls are what external regulatory obligations map to in Nexus, and what mechanisms are linked to in Mechanic. They are the translation layer that lets a clause from the EU AI Act and a provision from a client contract both resolve to the same governance territory.

The colour system

Each domain has a consistent colour that appears throughout the platform:

• Domain colour chips on Explore view nodes indicate which domains a clause maps to.
• Domain filter controls in the board header use the same colours.
• Portfolio views in Mechanic use domain colours to categorise mechanisms.

The colour system is purely navigational — it carries no compliance significance. Its purpose is to make domain boundaries legible at a glance across large canvases and complex crosswalks.

Using domains for analysis

Domain filtering in Nexus is one of the most powerful analytical tools in the platform. Load two or three frameworks onto a board, then filter to a single domain — say, Incident Management (IM). You see every incident-related requirement from every loaded artefact in one view, regardless of which regulation it came from.

This makes convergence visible: where multiple frameworks make demands in the same domain, your governance response can address all of them with shared mechanisms. It also makes divergence visible: where one source creates obligations in a domain that others do not reach.