Where GMAA Applies
GMAA governs a shape of problem, not an industry. Wherever independent actors, people or AI agents, change shared state that has to stay coherent, the same failure appears: each change is sound on its own, and the combination breaks a rule none of them touched. GMAA answers it the same way everywhere. The complete set of pending changes is reviewed against the rules the state must keep, and ratified by an accountable human before any member commits. Per-change review stays; the set is the layer that was missing.
This page maps that pattern onto the uses and industries where it shows up. The examples are illustrations of where set-level governance fits, meant to help you recognize the shape in your own systems. They are not claims of existing deployments, and they carry no performance figures.
Is GMAA the solution?
A system is a fit when four things are true at once:
- More than one actor changes the same state. People, teams, or autonomous agents, working in parallel, none seeing the whole.
- A change can be correct alone and wrong in company. The failure lives in the set, so reviewing changes one at a time cannot find it.
- The state has rules it must keep. A ledger must balance; a schema and its readers must agree; a validated system must stay validated.
- Catching an incoherent set before it lands is worth more than catching it after. The cost, in money, safety, compliance, or trust, justifies a governed pause.
If those hold, the label on the industry does not change the discipline. The two views below are the same control seen from two angles: by the kind of work, and by the kind of business.
By use
Change and release governance
The closest fit. A change board is meant to judge the week's changes both individually and as a group, and the group judgment is the part that slips. Set-level governance makes that second job structural: one accountable owner, independent of the work, approves the whole set against the environment's rules before release. The board becomes a real gate rather than a status meeting.
Software and product delivery
A codebase is a coherence boundary. When several developers or AI coding agents work it in parallel, each branch can pass its own tests while the merged result breaks a contract between them: one change renames a field, another still reads the old name, a third assumes both. An accountable review of the integrated set, before it merges, asks not only whether each change passes but whether the set coheres. This is the setting GMAA was first built for.
Program and portfolio management
Large programs run parallel workstreams that must fit together at a milestone. Each reports itself on track, and the integration is where the surprises appear. An accountable owner over the combined deliverable, validating that the workstreams cohere against the program's constraints before the milestone is declared done, moves that discovery earlier, where it is cheap.
Regulated operations and data integrity
Where a system is validated and its data integrity is governed, every change has to leave the system still compliant. Individually compliant changes can still move a system out of its validated state in combination. An accountable review of the set against the validation rules, before commit, keeps the control and the audit trail intact.
IT and infrastructure operations
Configuration changes across connected systems are a classic combination trap. A certificate rotation on one system is fine until the machines that never trusted the new certificate start failing. The dependency lives across the set, not in the single change, which is exactly what per-change review misses and what a governed review of the whole set is built to catch.
By industry
These describe where the four conditions tend to hold. Each names the coherence boundary, the set-level failure, and where the accountable seat sits.
Financial services
The boundary is the ledger and the rules that keep it balanced and compliant. Multiple systems and teams change shared financial state, and a set of individually valid entries can still violate an invariant or a regulatory limit together. The exposure is financial and regulatory, and the seat governs the set against those invariants before it posts.
Healthcare and life sciences
The boundary is a validated system and the integrity of the data it holds, under interlocking clinical, quality, and regulatory rules. Coherence across the combined change is what keeps the system trustworthy and compliant, and what an accountable review protects before the change is applied.
Manufacturing and supply chain
The boundary is a set of interlocking process and system parameters. A change to one step can be correct in isolation and break a downstream assumption when it lands with others. Governing the set before it commits prevents the individually reasonable change that stops the line.
Public sector and critical infrastructure
The boundary is a system the public relies on, where an incoherent change is measured in outages and lost trust rather than only cost. The value of a governed pause before commit is highest exactly where the state cannot tolerate an incoherent set.
What it does not claim
Set-level governance is a control on the coherence of a change, not a replacement for testing each change well, and not a guarantee that every possible conflict is caught, since some depend on facts outside the state or on ties no check was told to look for. Whether a given implementation catches the full range is answered by testing it honestly, by planting problems you already know about and owning the ones your system misses, not by asserting it. GMAA puts human judgment at the right unit and the right moment. It reduces a class of risk and strengthens the oversight posture. It does not remove the need to earn trust in any particular build.
Read the rest
The full argument for why the set is the right unit to govern is in the thesis, and the complete specification is in the architecture, both at gmaa.ai. If you are putting AI agents into shared state that has to stay coherent, that is the conversation to have: arch@gmaa.ai.