Solutions

One place the rules are actually enforced

A governance document is a wish. A control plane that refuses non-compliant requests is a control.

The problem

Model approval, tool approval, privacy rules and budget rules are usually enforced separately, manually, and in different systems — so compliance depends on every team remembering, and drift is invisible until an incident.

How Planverity addresses it

Layered policy with one composition rule

Central policy composes with team and project policy by deny-overrides and monotonic tightening. A team can be stricter than the organisation; it can never be looser. The effective compiled policy is visible, not just the layer someone authored.

Approved pools, not the whole registry

Candidates are drawn from an immutable pool version, never from every model the platform knows about. An unresolvable pool throws rather than falling back to 'everything' — a silent fallback would defeat the primitive entirely.

Versions you can point at

Policies and pools are immutable and versioned, and every execution records the exact refs in force. When someone asks what the rules were in March, the answer is a version number rather than a reconstruction.

Approval workflow is out of scope

Planverity enforces the policy you publish. It does not implement the human approval chain that produces it — publishing is an authenticated admin action, and who may perform it is your identity provider's question.

Other solutions