The Platform
Design your governance, then run it.
Most AI governance stalls in the gap between the policy that says what should happen and the process that has to make it happen. Balcony closes that gap with two modules: Nexus, where you work out what you owe and what covers it, and Mechanic, where those commitments become processes with owners, inputs and measurements.
Nexus
Governance you can see.
Most governance lives in documents, which is why nobody can answer a simple question about it quickly. Nexus puts it on a canvas instead: the things that govern you, the controls you have written, and the honest state of the join between them.
It is the difference between believing you are covered and being able to show it.
Four frameworks asking for the same thing is one piece of work.
Teams are rarely answering to one thing. It is the EU AI Act and ISO 42001 and the NIST framework and whatever your largest customer wrote into their contract — each usually held in its own document, each spawning its own workstream.
Nexus maps all of them onto a single control set. When four artefacts expect a risk assessment, that is one control with four mapped expectations. You build it once, and you can show any of the four exactly where their requirement is met.
Three states, and no fourth
- Gap
- Nothing is mapped to it yet.
- Covered
- A control is mapped, but nothing runs it.
- Implemented
- A control is mapped and a mechanism runs it.
Nothing is allowed to sit in an undefined middle. Either something runs behind an expectation, or the board says plainly that nothing does.
The reading, done for you
Parsing a regulation into discrete expectations and mapping each to a control is months of careful, boring work. The assistant does the volume — it reads the artefact and proposes mappings. Your team approves them. It never maps anything behind your back.
Bring in what governs you
Drop in a regulation, standard, internal policy or client contract. You get back a structured clause tree with each leaf classified by what it actually demands of you.
Scope boards the way you work
By regulation, by AI system, by project — whatever the unit of work is on your team. Controls are coloured by governance domain, so thin coverage is visible before anyone goes looking for it.
Follow any thread, either direction
Expand a control to see every expectation riding on it, or start from a running mechanism and walk back to the clause that required it in the first place.
Watch coverage compound
Add a framework next quarter and most of it lands on controls you already built. The work you have done carries forward instead of resetting.
Nobody can design this on their own.
Legal reads the obligation but cannot always say what is feasible to build. Engineering knows exactly what is feasible but has not read the obligation. Risk sits between them, usually working from a summary of both.
So Balcony is one shared board rather than three private ones. The whole team maps requirements, argues about controls and designs mechanisms in the same place, against the same picture — and the reasoning stays attached to the thing it was about.
Mechanic
A control is a claim. A mechanism is the proof.
“We assess risk before deployment” is a sentence. It becomes real when somebody can say what triggers the assessment, what it consumes, who is accountable for doing it, what it produces, and how you would know if it quietly stopped happening.
Mechanic is where your team designs that, and where it stops being possible to pretend a control is operating when it is not.
Mechanism
Risk Classification Process
- InputsWhat sets it off, and what it consumesFunctioning
- OutputsWhat it produces, and who receives itFunctioning
- ObjectiveThe controls it claims to satisfyPartial
- ScopeWhich AI systems it applies toFunctioning
- ToolingThe tools, and the ordered playbookPartial
- MetricsLeading and lagging, with targetsAbsent
- OwnershipA named person, not a functionFunctioning
Honest, part by part
A mechanism can look complete on paper and still be weak in practice — ownership that is a name with nobody behind it, metrics that measure nothing useful, inputs that technically exist but never actually arrive.
So there is no single score. Each part is read on its own, and a mechanism missing its metrics says so plainly instead of averaging out to a comfortable number that nobody questions.
If you cannot name who owns it and how you would know it stopped working, it is not a mechanism yet.
Governance rarely happens in one step.
A triage produces a severity rating that a classification needs. That classification produces a risk tier that decides the treatment plan. These dependencies exist whether or not anyone has written them down — and when they are not written down, a break in one place surfaces somewhere else weeks later.
Chains make them explicit: one mechanism’s output becomes the declared input of the next. When a link fails, you can see everything sitting downstream of it.
A chain
- Incident triageSeverity rating
- Risk classificationRisk tier
- Treatment plan
The output of one is the declared input of the next, so the dependency is a fact about the design rather than something held in somebody’s head.
A dashboard
Risk classifications
14
this month
Avg. classification time
2.4h
per review
Oversight reviews overdue
0
3 due this week
Incidents resolved
6
last 30 days
Classification volume, 10 weeks
The numbers your board will ask for.
Metrics do not have to stay buried inside the mechanism that produces them. Build dashboards that pull from across your whole portfolio — classification volumes, review cadences, incident resolution times — into one operational view.
Every team gets asked different questions, so choose the mechanisms, choose the metrics, and arrange them for whoever actually has to answer.
Branch it before you change it
Fork a mechanism, redesign it in isolation and open it for review. The diff shows exactly what changed — and warns you which chain connections a merge would break.
Feed it real numbers
Push measurements in over the API, upload a CSV, or type them in. The same figures drive the health read and every dashboard built on it.
See the whole portfolio
Every mechanism your organisation runs, in one view, so you can find the weak ones without opening them one at a time.
Start from a template
Common mechanisms come pre-structured, so the first one your team designs is not a blank page.
Start with one board.
Bring in the one artefact that is causing you the most work right now, and map it. The gaps will be obvious within an afternoon — and the mechanisms you build to close them are the start of the rest of it.