Core concepts
The vocabulary and structure behind Balcony — artefacts, expectation nodes, controls, mechanisms, and how they connect.
Everything in Balcony is built around a single analytical chain:
Artefact → Expectation → Control → MechanismEach step narrows the focus: from a broad regulatory document to a concrete operational process. Understanding these four concepts — and the structures that organise them — is enough to use both tools effectively.
Artefacts
An artefact is a regulatory framework, standard, or governance document that has been loaded into Nexus. The EU AI Act, ISO 42001, NIST AI RMF, a client contract — each becomes an artefact in Balcony.
Artefacts are structured as navigable trees that mirror the original document's organisation: parts, chapters, articles, annexes, or whatever hierarchy the source uses. You navigate this tree to find individual requirements and map them to controls.
Expectation nodes
An expectation node is a specific clause, article, or requirement within an artefact — the unit of mapping. When you create a mapping in Nexus, you are connecting one expectation node to one or more controls.
Expectation nodes carry a type that reflects their compliance weight:
| Type | Meaning |
|---|---|
| Obligation | A hard requirement — the organisation must comply |
| Requirement | A strong expectation, typically assessed in audit |
| Practice | A recommended approach, not a binary pass/fail |
| Commitment | A voluntary or contractual undertaking |
| Informative | Context or guidance, not directly actionable |
The type matters for mechanism design: an obligation demands a stricter mechanism than a practice covering the same territory.
The unified control framework
At the centre of Balcony is a structured governance framework that organises all AI governance territory into domains, topics, and controls. This framework is the shared vocabulary that translates between the diverse language of different regulatory sources and the operational work your organisation does.
Domains
Domains are the twelve top-level categories. Each covers a distinct governance territory. See Domains & Topics for the full list with colour codes.
Topics
Topics group related governance concerns within a domain. A topic such as Data Governance (DL-1) or Incident Reporting (IM-2) identifies a coherent area of practice. Topics are numbered within their domain: GL-1, GL-2, RM-1, RM-2, and so on.
Controls
Controls are the specific, actionable governance requirements at the leaf level of the framework. Each control represents a precise governance expectation — something your organisation either addresses or does not. Controls are numbered within their topic: DL-1-1, DL-1-2, and so on.
The crosswalk
The crosswalk is the complete picture of how your external regulatory sources map to your internal controls. It is the first structured artefact the methodology produces, and it lives in Nexus.
The crosswalk reveals three patterns that are invisible when you look at regulations one at a time:
- Convergence — where multiple sources require the same control. One mechanism can satisfy several frameworks simultaneously.
- Divergence — where only one source drives a control. Governance effort here is source-specific.
- Gaps — controls with no mapped expectations from sources you are subject to, or expectations that have no corresponding control.
Coverage states
Each control in your crosswalk carries a coverage state based on what exists behind it:
| State | Meaning |
|---|---|
| Gap | No mechanism is linked to this control. The regulatory obligation exists, but there is nothing operational behind it. |
| Covered | A mechanism exists and is linked to this control in Mechanic, but has not yet been assessed as functioning. |
| Implemented | The linked mechanism has been assessed and confirmed as operational. |
Gap → Covered → Implemented is the progression from a documented obligation to a functioning governance practice. The How it fits together page explains this in detail.
Mechanisms
A mechanism is the operational process behind a governance control. While a control describes what territory must be covered, a mechanism is how you cover it. A control without a mechanism is governance on paper.
Balcony assesses mechanisms by examining several components — Inputs, Outputs, Objective, Scope, Tooling, Metrics, and Ownership — each of which must be present and adequate for a mechanism to function reliably. The pattern of which components are present, absent, or weak creates a diagnostic profile that points toward specific interventions.
See Building a mechanism for a full description of each component.
Chains
A chain is a connected sequence of mechanisms where one mechanism's output becomes another's input. Chains make governance dependencies explicit: if one mechanism in a chain is absent or broken, every downstream mechanism that depends on its output is also at risk.
Workspaces
A workspace is the shared environment where all governance work lives. Artefacts, boards, mappings, mechanisms, chains, and dashboards all belong to a workspace. Team members can collaborate within a workspace and see each other's contributions in real time.
You can belong to multiple workspaces — common when a practitioner supports several clients or governance programmes — and switch between them at any time.