Gatekeeper Enforcement Model
The Gatekeeper is the enforcement node. The Registry is the authority. They must remain structurally separated.
1. Authority vs. Execution (Non-Negotiable Separation)
A GovenAI-compatible architecture prohibits “silent overrides” by ensuring the system that defines governance state is not the system that executes work.
Registry (Authority)
- Stores governance facts (targets, checks, waivers).
- Maintains immutable audit trail for governance events.
- Does not execute runtime actions.
Gatekeeper (Enforcement)
- Intercepts actions and evaluates readiness deterministically.
- Consults Registry via RGIS v1.0 before permitting.
- Fails closed on ambiguity or authority unreachability.
2. Fail-Closed Semantics
The default posture of a Gatekeeper is denial unless explicit governance state proves permission.
| Condition | Gatekeeper result | Rationale |
|---|---|---|
| Registry unreachable / timeout | DENY | Authority cannot be verified. |
| Target unknown / not registered | DENY | No governance facts exist. |
| Any required check = fail/blocked and no active waiver | DENY | Deterministic non-compliance. |
| All required checks pass OR valid waivers exist | ALLOW | Compliance proven by state. |
3. Evidence Discipline
“Pass” without evidence is not a standard. Gatekeepers and operators must require evidence references for affirmative states where applicable (e.g., audits, penetration tests, signed attestations).
Implementation binding
The Gatekeeper must implement RGIS v1.0 and consume registry readiness deterministically.
See RGIS v1.0 and Universal Primitives.