> 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/2.lpp-positioning/2.3-layer-0-vs-layer-1.md).

# 2.3 Layer 0 vs Layer 1

The distinction between Layer 0 and Layer 1 is foundational to LPP.

#### Layer 0 — Constitutional Admissibility

Primary question:

> **Is this AI-triggered action qualified to become an execution candidate at all?**

Relevant considerations include:

* authority origin,
* Authority Object validity,
* authorized intent,
* scope,
* authority lifecycle,
* revocation,
* responsibility,
* delegation validity,
* consequence requirements,
* material mutation,
* constitutional invariants,
* and required evidence.

Possible LPP decisions are defined later as:

```
ADMIT
DENY
DEFER
COLLAPSE
```

#### Layer 1 — Runtime Policy / Authorization

Primary question:

> **Should this already-formed request be permitted under operational policy?**

Layer 1 may evaluate conditions such as:

* current runtime policy,
* user or workload permissions,
* tool authorization,
* access constraints,
* environment state,
* security rules,
* runtime risk controls,
* or organizational policy.

Its decision environment typically assumes that the request has already become a valid object of evaluation.

#### Execution — Operational Actuation

Primary question:

> **How is the permitted action actually performed?**

Execution systems may be responsible for:

* API invocation,
* tool execution,
* workflow mutation,
* infrastructure changes,
* device control,
* asset movement,
* runtime monitoring,
* interruption,
* logging,
* or recovery.

#### The Complete Relationship

The canonical dependency is:

```
Layer 0
Constitutional Admissibility

        ↓

Layer 1
Runtime Authorization

        ↓

Execution
Operational Actuation
```

For an LPP-governed action:

```
Execution(E)
⇒
Admit₀(E, G)
∧
Permit₁(E, P)
```

Layer 1 permission is therefore necessary where applicable.

It is not sufficient by itself.

#### Policy Pass Does Not Imply Admissibility

A runtime policy system may determine:

```
Permit₁(E, P) = ALLOW
```

while Layer 0 determines:

```
Admit₀(E, G) = FALSE
```

Examples include:

**Valid policy, invalid authority**

The caller satisfies runtime policy, but the underlying authority has expired or been revoked.

**Valid identity, invalid responsibility chain**

The system knows exactly which agent made the request, but cannot establish a legitimate authority origin for the action.

**Valid tool permission, invalid intent**

The agent possesses permission to call the tool, but the current objective has materially departed from what was originally authorized.

**Valid individual operations, invalid trajectory**

Each local operation may satisfy policy, while their accumulated trajectory exceeds the original legitimate scope.

**Valid runtime rule, invalid governance boundary**

The request satisfies a policy whose governing boundary was itself changed without legitimate authority.

Therefore:

> **Policy compliance does not imply constitutional admissibility.**

#### Strengthening Layer 1 Does Not Eliminate Layer 0

A runtime system may become increasingly sophisticated.

It may add:

* policy provenance,
* immutable registries,
* authority lifecycle checks,
* multi-signature authorization,
* formal invariants,
* revocation mechanisms,
* or governance-boundary validation.

This does not demonstrate that Layer 0 is unnecessary.

If Layer 1 begins evaluating:

* who had authority to establish the policy,
* whether the policy was legitimately modified,
* whether constitutional invariants remain preserved,
* and whether the action has a valid legitimacy root,

then Layer 1 has begun implementing Layer 0 functions internally.

The architectural distinction therefore remains:

```
A Layer 1 system either:

depends on Layer 0 externally,

or

internalizes Layer 0 functions.
```

The naming or deployment boundary may vary.

The governance function does not disappear.