Our approach

What is adaptive governance?

Governance that documents what should happen isn't the same as governance that makes it happen. Here's how we think about the difference — and why it matters for AI.

01 — The starting point

Most governance is designed to satisfy auditors.

Not to prevent harm. Not to build trust. To produce the right artefacts at the right time so that when someone comes looking, there is a document that says the right things.

This works, after a fashion. Auditors are satisfied. Certifications are issued. Board papers report that governance is in order. And then something breaks — because the document that said the right things described a process that nobody actually ran, or that ran fine until the system changed, or the team did, or the evidence moved.

Cruise had governance structures and safety documentation. Over a hundred employees knew about a pedestrian-dragging incident. Nobody disclosed it to regulators. Leadership minimised rather than escalated. The DOJ charged obstruction. The company collapsed from a thirty-billion-dollar valuation. They didn't fail because they lacked governance. They failed because their governance was theatre.

This is not a failure of intent. It's a failure of design.

02 — The design problem

Designed for a snapshot. Not for what comes after.

This is the default failure mode of traditional GRC. The register is the point. Map your controls, document your processes, file the evidence. AI governance compounds it: models are retrained, vendors change, regulations get amended, new systems are deployed that nobody thought to run through the risk framework. The team responsible for oversight restructures, and the new team inherits a framework they didn't design and don't fully understand.

HireVue assessed their video interview system once and assumed the assessment held. As evidence mounted against affect recognition — including a large-scale meta-analysis of hundreds of studies — they had ethical principles on paper and an advisory board in place. They dropped facial analysis only after sustained external pressure, two years later. The governance wasn't absent. It just couldn't adapt when the ground shifted beneath it.

The governance breaks not because of negligence, but because it was built for a static moment — and the moment passed.

03 — The chain

From artefact to operation.

There is a chain between a requirement and a running process. It goes: artefact, expectation, control, mechanism. Every link matters. An artefact without extracted expectations is a document. An expectation without a control is a wish. A control without a mechanism is a sentence in a policy. A mechanism without inputs, outputs, ownership, and metrics is governance theatre.

Most organisations have most of the chain somewhere — spread across a legal team's documents, a risk team's spreadsheets, an engineering team's tickets, and a compliance tool nobody else looks at. Nobody has the whole thing in one place, and nobody can see the breaks.

Artefact → Expectation → Control → Mechanism

04 — Good intentions aren't enough

You need good mechanisms.

A bias-testing mandate is not a mechanism. It becomes one when code cannot deploy until tests pass, results log automatically, and newly-discovered biases feed back into strengthened test suites. A human oversight protocol is not a mechanism. It becomes one when it has a defined trigger, a named owner, a documented output, and metrics that tell you whether it's actually running.

The difference matters because stated intentions decay. Mechanisms have feedback loops built in — they surface when they're breaking before something goes wrong. That's the design property that makes governance adaptive: not that it's reviewed annually, but that it senses change, surfaces gaps, and can be improved without starting over.

Waymo doesn't run their safety program because regulators require it. Every mile is automatically analysed, improvements tested across millions of simulated scenarios before any system reaches the fleet. The feedback loop that makes the driving better is the same loop that makes it safe. When governance is designed right, compliance becomes a byproduct of doing the work well — not the purpose of it.

05 — Where the name comes from

The balcony and the dance floor.

Ronald Heifetz uses this image to describe what good leadership requires: the ability to move between the balcony — where you can see the whole system, the patterns, the gaps — and the dance floor, where the work actually happens and where governance either functions or doesn't.

Most organisations are stuck at one level or the other. Leadership sees frameworks and dashboards. The teams doing the work see approval queues, manual processes, and controls nobody questions. When bad news gets softened at each layer between them, governance fails — not because nobody cared, but because the information never arrived intact.

This is what Balcony is built around. The canvas in Nexus is the balcony view: the whole structure of your governance, what's covered and what isn't, visible at once. The mechanisms in Mechanic are the dance floor: where the work actually runs. The goal is for both views to reflect the same truth.

Try it in practice.

The best way to understand adaptive governance is to design one. Balcony is in early access — start with a single mechanism and see what the chain looks like when it's made explicit.