01
AI inventory. What AI systems exist, who owns them, and how risky each one is.
Foundational layer
The layer beneath the stack.
Every framework for AI governance describes layers. Inventory the systems. Govern the data. Control access. Assure the models. Keep humans in oversight. Audit against the regulations. The frameworks are good and the layers are real. They share one assumption. Each layer takes for granted that someone already decided this system was allowed to operate, defined what it was allowed to do, and accepted responsibility for what it produces. That decision is a layer too. It sits underneath all the others, and in most organizations it was never designed.
Operational stack
What most frameworks govern.
The common model of AI governance is a stack of operational layers. Each one answers a real question and each one matters.
Run all six well and the organization still cannot answer one question: who decided this system should operate at all, and where is that written down.
02
Data foundation. Where the data comes from, whether it is accurate, and whether it carries bias.
03
Data security and access. Who can reach the data and under what controls.
04
Model assurance. Whether the model performs, stays fair, and holds up over time.
05
Human oversight. When a person reviews, escalates, or overrides what the system does.
06
Compliance and audit. Whether the whole arrangement satisfies the regulators and leaves a trail.
Assumption
The decision every layer assumes.
Model assurance assumes someone defined what the model is for. Human oversight assumes someone decided which choices require a person. Compliance assumes someone accepted accountability for the outcome. Each operational layer is built on a decision that happened, or should have happened, before the layer was designed.
In most enterprises that decision is missing. The closest thing to it is a procurement approval that cleared the system to be purchased. That approval rarely defines what the system is allowed to do or who answers when it does the wrong thing. Access was granted. Authorization was assumed.
This is the pattern across regulated AI deployment. The operational controls are mature and the authorization record does not exist. A monitoring dashboard can have every alert configured, with no document naming who approved the agent to act in the first place. The remediation costs months. The original decision would have taken under an hour to write down.
The operational layers tell you the system is behaving. The authorization layer tells you it was ever allowed to.
Layer contents
What this layer is made of.
The authorization layer is a sequence of design decisions and records that have to exist before the operational layers have anything to govern. The framework library on this site is the design work for that layer, organized in the order the work happens.
01Core concepts
Name the risk.
The language that makes the authorization failure visible before it becomes an incident.
02Diagnose frameworks
Diagnose.
Measure the gap between what is deployed and what was actually authorized.
03Authorize frameworks
Authorize.
Make and record the decision before go-live.
04Operate frameworks
Operate.
Keep authorization current as the system and the organization change.
05Agent Authorization Document
Keep the record.
Turn the decision into the evidence an examiner reads.
Sequence
Why this comes first.
An organization can build the full operational stack and still fail the first question a regulator asks. The controls may be strong, but they govern a system no one formally authorized. Authorization comes before the operational layers are running. It is the decision the operational layers exist to enforce. Build it first and every layer above it has something real to govern. Skip it and the rest is a well-instrumented record of a decision nobody made.
Framework library
Start with the layer the stack assumes.
The framework library turns authorization from an assumption into a record, a sequence, and a governance habit.