> For the complete documentation index, see [llms.txt](https://docs.lpp-minduniverse.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lpp-minduniverse.org/lingua-pactum-protocol-lpp-documentation/3.canonical-governance-architecture/3.4-admission-plane.md).

# 3.4 Admission Plane

The Admission Plane determines whether the formed Action Candidate is constitutionally qualified to proceed.

Its core component is:

> **LPP Admission Kernel — Layer 0 Constitutional Admissibility Kernel**

The Admission Kernel is the point at which the upstream governance state is evaluated as an admissibility decision.

#### Admission Inputs

Depending on the applicable protocol profile, the Admission Kernel may evaluate:

* Authority Object,
* Human-Authorized Intent,
* authority–intent binding,
* Execution Intent,
* scope,
* authority lifecycle,
* revocation state,
* delegation state,
* LPP consequence class,
* material mutation,
* Semantic Verification results,
* SVNN evidence where required,
* policy or institutional constraints,
* and applicable constitutional invariants.

The kernel does not infer legitimacy merely because the action successfully passed earlier modules.

Every upstream component provides an input or constraint.

None individually substitutes for admission.

#### Admission Decisions

The current LPP decision model contains four states.

**ADMIT**

Required Layer 0 conditions are satisfied.

An admitted action may proceed toward Execution Permit issuance.

**DENY**

A required admissibility condition has failed.

Execution is not permitted under the evaluated governance state.

**DEFER**

Admissibility cannot yet be determined because required authority, evidence, verification, or review remains unresolved.

The action is not treated as admitted while the condition remains unresolved.

**COLLAPSE**

A constitutional failure prevents valid admissibility from being established under the governing model.

Collapse is conceptually distinct from ordinary runtime denial.

It represents failure of the legitimacy basis itself.

#### Only ADMIT Produces the Execution Path

The architectural rule is:

```
ADMIT
        ↓
Execution Permit may be issued
```

while:

```
DENY
DEFER
COLLAPSE
        ↓
No valid execution path
```

#### Current Validation Boundary

The protocol decision model and the current executable validation scope are not identical.

At present:

```
ADMIT
Specified
Implemented
Validated
```

```
DENY
Specified
Implemented
Validated
```

while:

```
DEFER
Specified
Not currently validated as an MVP decision path
```

and:

```
COLLAPSE
Specified
Not currently validated as an MVP decision path
```

Therefore:

> **Protocol completeness does not imply implementation completeness.**

The architecture describes the complete decision model.

Validation claims remain bounded to the demonstrated implementation scope.