> 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/4.-governance-objects/4.6-execution-permit.md).

# 4.6 Execution Permit

The Execution Permit is the constrained execution credential produced after successful admission.

It answers:

> **What constrained execution is allowed now?**

The Permit sits between constitutional admission and operational execution.

```
ADMIT
        ↓
Execution Permit
        ↓
Permit Verification
        ↓
Execution
```

### Permit Is Downstream of Legitimacy

The Authority Object is the upstream legitimacy carrier.

The Execution Permit is the downstream execution derivative.

Therefore:

```
Authority Object
≠
Execution Permit
```

The published Authority Objects research expresses the dependency as:

```
PermitMinted(π, E, AO, G)
⇒
AuthorityAdmissible(AO, E, G)
```

If authority is not admissible, a valid Permit must not be minted.

### Permit Does Not Create Legitimacy

This is a critical boundary:

> **A Permit carries an admissibility decision. It does not create the legitimacy behind that decision.**

If the upstream Authority Object is invalid, the system must not treat possession of an old or improperly issued Permit as a new source of authority.

### Current MVP Reference Structure

The current executable MVP uses a Permit structure containing:

```
Permit {
    permit_id
    principal_id
    authority_id
    scope_hash
    policy_hash
    intent_hash
    nonce
    issued_at
    expires_at
    cp_signature
}
```

This represents the current prototype's minimal execution credential.

Future profiles may extend the structure.

### Time-Bound

The Permit has a defined lifetime.

```
issued_at
expires_at
```

It must not remain indefinitely reusable.

The Authority Objects research additionally constrains Permit expiry relative to upstream authority validity:

```
Permit expiry
≤
Authority validity end
```

A downstream Permit cannot legitimately outlive the authority on which it depends.

### Scope-Bound

The Permit is bound to admitted scope.

A Permit issued for:

```
function = isolate_host
target = host:A
```

must not silently authorize:

```
function = modify_network
target = entire_production_network
```

### Intent-Bound

The Permit is bound to the admitted Execution Intent.

```
permit.intent_hash
=
H(admitted execution intent)
```

Changing the action after Permit issuance should invalidate the binding.

### Policy-Bound

The current reference model includes a policy hash or equivalent policy-state binding.

This makes the authorization reconstructable against the governing policy version.

### Non-Replayable

The Permit includes replay-control material such as:

```
nonce
```

The current MVP specifically validates replay rejection as one of its **six core execution scenarios**.

### Signed by the Control Plane

The Permit is cryptographically signed by the Control Plane in the reference implementation.

The Execution Plane verifies that signature before performing the governed action.

The Execution Plane cannot self-mint an equivalent valid Permit.

### Permit Consumption

A Permit is an operational credential.

Depending on its profile, it may be:

* single-use,
* bounded-use,
* short-lived,
* consumed,
* or invalidated by changed authority state.

The detailed Permit lifecycle is specified later in the Appendix.