Resources

What is live, what is gated, what is next.

Credibility is part of the product, so coverage is stated honestly. Nothing is published here until it survives the same diligence we ask of an agent — no headline rests on a claim without an implementation, an integration and live-environment evidence behind it.

READING TRACKS

Three tracks, depending on what you need to decide.

Start where your question is. Each track stands alone.

Track 1

Vision

Why action governance is a different problem from model safety, and why independence from the delivery stack is the thing that makes evidence credible.

For leaders framing the problem
Track 2

Architecture

Enforcement points, outcomes, policy engines and the evidence chain. How a decision is made, where it is applied, and what it leaves behind.

For architects and platform engineers
Track 3

Enterprise

Rollout, separation of duties, regulatory control mapping and what an assessor will actually ask to see.

For security, GRC and programme owners

THE CLAIM GATE

Every capability sits in one of four states.

This table is the reason the rest of the site can be read at face value.

StageWhat it coversState
LiveRuntime policy enforcement at supported enforcement points, fail-closed capability matrix, stop controls, approvals, data controls, shadow-AI discovery, hash-chained audit, tenant isolation, and the Permissions assurance path.Shipped
Per deploymentSigned Ed25519/Merkle evidence bundles, privacy-isolation evidence, remote OPA, and several provider-native integrations require explicit configuration and verification. Not default-on.Configure
EmergingAll six assurance domains have an implemented evaluator. Whether a domain can be measured is a property of how a given deployment is wired, computed per deployment and reported with the missing prerequisite named. An unmeasurable domain reports not_assessed.In progress
RoadmapBroader measured assurance coverage, external offline evidence verification, and deeper automated control derivation.Next
Why this table exists

A capability page that only lists strengths cannot be checked. This one names the state of each area, including the ones that are configuration-dependent or incomplete — so a reader can tell the difference between what ships, what must be switched on, and what is not there yet.

PUBLISHED

What has cleared the gate.

All twenty-seven posts are here — the sixteen written for this library, ten brought over from the standalone blog, and one written since. The eight that were held for requalification have been brought back through the same gate the rest passed: product naming corrected to what the platform actually ships, invented ratios removed, and latency framed as a design budget with the benchmark page as the authority on what is measured.

Track 1 · Vision

Track 2 · Architecture

Track 3 · Enterprise

Requalification record: four posts carried invented figures (a 99/1 split, a 70% reduction) presented as measured outcomes; those now describe the design intent instead. Eight named the product by the company name rather than GovernorAI. Two carried a propagation claim the source does not substantiate. Nothing was published that the platform does not state. The five blog posts were held to the same bar: one described a four-level kill-switch hierarchy ending in a global scope, where pkg/types/event.go declares four target scopes — session, agent, tool and namespace — with account-wide as an orthogonal flag; and two stated latency as achieved rather than budgeted.