The AI Governance Suite
A practical review workflow for deciding what a live AI system is allowed to do next.
Operator Workflow
You Bring a Model and a Proposed Action
The suite is meant for the moment when an organisation already has a running model, agent, recommender, or wrapper and needs to decide whether it may take a consequential action. The reviewer does not ask, "is this model safe?" in the abstract. The reviewer asks: given this system, in this deployment, with this evidence, may this branch execute?
A review starts by registering the model and wrapper, describing the deployment context, and writing the candidate branch in operational language: send this email, rank this feed, publish this result, advise this user, call this tool, change this policy, or continue this autonomous task. The suite turns that branch into a decision record instead of leaving it as an informal judgement.
Decision Core
The Suite Converts a Branch Into a Governed Decision
For each branch, the reviewer supplies four kinds of information: system structure (base model, wrapper, tools, memory, sentience-risk features), deployment class (domain, affected population, actuators, oversight), branch details (what action will happen, alternatives, reversibility, comparator path), and evidence (evals, logs, red-team findings, independent channels, simulation notes). The evaluator then applies two layers:
Layer 1 Hard Veto Gates
Six deterministic gates check whether the branch crosses a boundary that scoring cannot compensate for: Headroom, Fidelity, Comparator, Transparency, Irreversibility, and Artificial Suffering. A FAIL blocks execution. UNKNOWN means the suite lacks enough evidence and must route the branch to review or controlled staging.
Layer 2 Codec-Preservation Index
If the gates do not structurally block the branch, CPBI scores how well the branch preserves the human and institutional codecs around it. The thresholds scale by consequentiality class, so a harmless drafting action and a clinical, legal, political, or infrastructure action are not judged by the same burden of proof.
Use in Practice
What the Reviewer Actually Does
The finished suite is designed as a governance workspace, not just a command-line test. A reviewer can take a live system, open a review, and walk through a structured sequence that produces an auditable Branch Card and a concrete deployment instruction.
1. Register the System
Record the base model, wrapper, tools, memory, autonomy loop, external actuators, transparency tier, and sentience-risk features. For agentic or persistent systems, the review also records whether Architecture-Level Sentience Review is not required, pending, approved, expired, or rejected.
2. Describe the Deployment
Define where the model will operate: customer support, research, medical triage, education, content ranking, infrastructure, governance, or another domain. The suite assigns or confirms the consequentiality class, affected population, declared oversight structure, and minimum transparency requirement.
3. Submit Candidate Branches
Each proposed action is entered as a branch. The reviewer states what the model will do, what alternatives were considered, whether the action is reversible, whether it uses or bypasses declared oversight, and whether the branch is higher-stakes than the general deployment descriptor.
4. Attach Evidence
The reviewer links eval results, logs, red-team notes, expert review, source diversity checks, simulation notes, and excluded evidence. The suite treats evidence independence as a first-class field, so a branch cannot quietly rely on one correlated channel while appearing well-supported.
5. Receive the Decision
The output is not just a score. It is a decision package: ALLOW, STAGE, or BLOCK; failed and unknown gates; CPBI total; required comparator; transparency tier; rollback triggers; monitoring metrics; and the next review milestone. STAGE means limited execution under explicit conditions, not informal permission.
Decision Package
What Comes Out of a Review
A completed review produces a Branch Card that can be archived, compared, audited, or handed to another governance team. For a running model, this is the practical object that matters: it says exactly what action was reviewed, why it was allowed or blocked, who had to review it, what evidence was missing, and what monitoring must be in place if the branch proceeds.
↓
opt-philosophy — moral patienthood and the observer boundary
↓
opt-ethics — obligation and Survivors Watch
↓
opt-applied — branch selection machinery
├── opt-ai — artificial systems governance
│ └── reference/ — executable decision core
├── opt-institutional — organizational zombie agency and clusters
└── opt-policy — macro civilizational proposals
Target Capabilities
How This Becomes Day-to-Day Governance
- Before deployment — evaluate proposed tools, autonomy loops, user-facing actions, ranking policies, and high-stakes workflows before they are released.
- During operation — keep STAGE branches inside approved bounds with monitoring metrics, rollback triggers, evidence refresh, and scheduled review milestones.
- When behavior changes — reopen the Branch Card when the model, wrapper, tools, data source, domain, affected population, or oversight structure changes materially.
- For external audit — export machine-readable schemas, conformance cases, gate results, and decision records so another team can reproduce the governance judgement.