Inputs
- Caller identity and session assertions
- Published intent and translated contract requirements
- Evidence references and compiler certificates
- Proposed action, target and digest
Verification and admission
Gatekeeper
Admission is a decision, not a side effect.
Independent admission and authorisation, gate evaluation and signed permit issuance bound to the action.
Responsibility
What Gatekeeper is responsible for
Gatekeeper is the independent admission authority. It evaluates a fixed set of requirement gates against the caller, the intent, the evidence and the proposed action, then issues a scoped, single-use permit bound to the action digest — or refuses with a specific reason.
The point of an independent admission authority is that the component which executes an action does not also decide whether the action is allowed. Gatekeeper evaluates the requirement gates and issues a permit only when every gate it needs is established.
A permit is not a generic approval. It is scoped to a caller, tenant, target, operation and action digest, carries an expiry and nonce, and is verified again at the execution boundary. A permit that cannot be verified is not permission.
Lifecycle position
Where it sits in the governance lifecycle
Stage numbering is canonical across the site. Open the interactive lifecycle to see every component with responsibilities at each stage.
Admission
Establish authority independently of the executor.
Verified capabilities
What is verified today
Capabilities are drawn from the product register. Each one is bounded by the limitations stated further down this page.
- 13-gate admission evaluation with explicit refusal reasons
- Signed permit issuance with scope, expiry, nonce and action-digest binding
- Replay and duplicate-delivery protection
- Separation of admission authority from execution
- Verification of λ-Safe bundles and evidence at admission
Outputs
- ADMIT or DENY decision with gate-level reasons
- Signed permit bound to the admitted action
- Admission record for the audit chain
- Replay/nonce state
Evidence and maturity
What the evidence supports
Maturity describes verified engineering evidence in a bounded environment. It is not a production-readiness statement.
Maturity note
13-gate admission, signed permit issuance and replay/nonce protection are implemented and were exercised in the local demonstration stack: eight invalid-permit cases were refused with no effect written. Live network admission remains platform-blocked while policy context is unobserved.
Not production-qualified
This label describes verified engineering evidence only. No production deployment, certification, benchmark or customer outcome is claimed.
Evidence recorded
- 86 unit and integration tests across admission and permit paths.
- Eight invalid-permit cases refused with zero effects written (acceptance step 3).
- One permit-v2 artifact verified by Control Plane, Substrate and NARG with identical JCS digests.
- Local admission history and detail read APIs returned real records in the November 2026 audit.
Dependencies
- λ-Safe Enterprise verifier
- Chinje authority context
- Control Plane policy context
- Identity provider
Dependencies are stated as the product register records them. A dependency is not automatically production-qualified; see its own product or component page for its maturity and limitations.
Limitations
What this product does not do (yet).
Limitations are stated before the evaluation questions so they cannot be missed, downplayed or treated as future-work footnotes.
Limitations — read before evaluating
- Live D8 admission is platform-blocked in the reviewed environment because policy context is unobserved (POLICY_CONTEXT_UNOBSERVED).
- Approval and separation-of-duties code exists but no approver identities are configured, so it is unexercised.
- External OIDC is unavailable; only local development identity was available.
- Gatekeeper admits against facts supplied by other components and trusts them unless separately attested.
No capability on this page should be read as production qualification. If a limitation is material to your use case, it belongs in the evaluation scope — not after it.
Relationship to the platform
How it fits
Gatekeeper is the only component that issues permits. NARG and Substrate verify those permits at the execution boundary; the Control Plane coordinates decisions but does not admit actions on Gatekeeper's behalf.
Evaluation questions
- Which gates can be established with the evidence available in your environment?
- What happens when a gate cannot be established rather than failing?
- How are permits scoped, expired and revoked?
Next step
Evaluate Gatekeeper against a real control problem.
Bring a system boundary, an action class and a failure mode. The first step is to agree what should be governed and what evidence would count.