Verified Controls

Everything on the preceding pages assumes the controls being enforced are correct. This page covers how that is established.

A policy set assembled by hand across a dozen AI surfaces will contain contradictions, gaps, and rules that can never fire. Those defects are not visible by reading, a contradiction between two policies written six months apart by different people looks like two reasonable policies. They surface as an incident, or as a denial nobody can explain, or as an access that should not have been possible.

Lattix addresses this by deriving controls from a governed data model and machine-checking them before they can take effect.

The lifecycle

A control set moves through five states. Nothing skips a state, and nothing enforces before the last one.

Governed data model  ->  Compiled controls  ->  Validation  ->  Approval  ->  Enforcement
   (published)            (hash-bound)        (signed record)   (explicit)      (active)

1. Governed data model

Your classifications, the relationships between them, and the rules that connect them are expressed in a governed model rather than as a flat list of tags.

The distinction that matters for configuration: your tag schema is the authoritative vocabulary that policy evaluates against. The data model describes how those terms relate, which classifications imply others, which categories nest, which combinations are meaningful, how a derived artifact's classification follows from its inputs.

Both are needed. The vocabulary is what policy references. The model is what makes it possible to reason about the vocabulary as a whole rather than one rule at a time, which is what makes validation possible.

The model is versioned and published under change control. A draft is not a published model. An imported model is not an approved one.

2. Compiled controls

A published model version compiles into a control set. Each control set is bound by cryptographic hash to the exact model version it was compiled from.

That binding is what eliminates drift. A control set cannot be silently edited out from under the model that justified it, and a control set cannot outlive the model version it was derived from without that being detectable. If either the model or the control set changes, the hashes no longer agree and the control set is not valid.

The operational consequence: you do not hand-maintain policy per AI surface. A new agent, retriever, tool, or data source inherits the compiled control surface. This is the property that makes governance scale with the model rather than with the number of AI surfaces you run.

3. Validation

Before a control set can be activated, it is machine-checked. The checks establish properties about the control set as a whole rather than testing individual rules:

• Consistency. No two controls can require contradictory outcomes for the same request.
• Completeness. Every request shape the model admits resolves to a defined outcome. There is no request that falls through to an implicit default.
• Reachability. Every control can actually fire for some request. An unreachable control is usually a symptom of a defect elsewhere.
• Non-escalation. No sequence of permitted operations yields authority that no single operation grants. This is the check that catches privilege escalation through delegation chains and multi-step agent workflows.

The result is recorded as a signed validation record bound to the model version, the control set hash, and the exact validation input.

The negative outcomes are as important as the positive one, and each is distinct:

Note that four of the five block. An unverified control set is not activated with a warning. Validation is a gate, not a report.

4. Approval

Validation does not activate anything. A verified control set becomes active only through explicit approval by an authorized administrator, recorded in the ledger with the approver, the validation record it relied on, and the model version.

This separation is deliberate. Automatic activation on successful validation would make the validator an authority, and the validator is a checker, it establishes properties about a control set, which is not the same as deciding that the control set is what your organization wants. Those are different judgments and they belong to different parties.

5. Enforcement

The active control set is what the enforcement points evaluate against, per the preceding pages.

Evidence, not authority

The invariant that governs how the rest of the system treats a validation record:

A validation record is evidence. It is never authorization.

A validation record proves a control set was checked against a specific model version. It does not grant access to anything, and no runtime component treats it as a grant.

Every live request is still evaluated against current policy, current attribute state, and current revocation state. Every key release is still authorized independently at the cryptographic boundary. A request denied by live policy stays denied regardless of what any validation record says.

This is worth understanding because it is the difference between a system whose correctness claims hold and one where they quietly stop holding. If a proof could authorize, then a stale proof authorizes stale access, and staleness is exactly the condition that is hardest to detect. Keeping validation and enforcement as separate boundaries means a validation record can go stale without becoming a security hole; it just stops being eligible.

Operating this

Publish before you compile. A draft model produces a control set that cannot be approved. Complete the review and publication cycle first.

Read the counterexamples. A failed validation reports the specific request shape that breaks the property. That counterexample is the most useful debugging artifact the system produces — it is a concrete case, not a warning about a category.

Expect the first validation to fail. An existing policy set brought under validation for the first time will usually surface real defects. That is the control working. Budget time for it rather than treating it as a blocker to work around.

Re-validate on model change. A model version change invalidates control sets compiled from the previous version. This is by design, and it is why model changes are batched and reviewed rather than made continuously.

Keep validation records with the approval. The record and the approval that relied on it are the evidence pair an auditor will ask for. Retain them together, for as long as the decisions made under that control set are in scope.

Verification

1. A control set compiled from a draft model cannot be approved.
2. A control set whose validation failed cannot be activated.
3. A control set with a stale validation record (model or control hash changed) cannot be activated.
4. Activation requires an explicit approval, recorded with the approver identity.
5. A successful validation record does not, by itself, permit any data access.
6. A live policy denial remains a denial regardless of validation state.
7. A model version change causes control sets compiled from the prior version to require re-validation.

Test 5 explicitly. It is the invariant the entire assurance argument depends on.

Related

• Policies and ABAC, the runtime decision model this feeds.
• Tag Schema, the authoritative vocabulary the model is built over.
• Policy Workflow, authoring, review, and publication mechanics.
• Immutable Ledger, where validation records and approvals are retained.