> 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.4-identity-access-permission-authority-admissibility.md).

# 2.4 Identity ≠ Access ≠ Permission ≠ Authority ≠ Admissibility

One of the most important LPP distinctions is that several commonly merged governance concepts represent different questions.

The canonical sequence is:

```
Identity
≠ Access
≠ Permission
≠ Authority
≠ Admissibility
```

These concepts may depend on one another.

They are not interchangeable.

#### Identity

**Question:**

> Who is acting?

Identity systems may determine:

* user identity,
* workload identity,
* service principal,
* agent identity,
* cryptographic identity,
* or organizational identity.

A valid identity establishes who the system recognizes as the principal.

It does not establish that the requested action is legitimate.

```
Valid Identity
⇏
Valid Authority
```

#### Access

**Question:**

> What can the principal reach?

Access concerns the resources, interfaces, systems, or tools available to a principal.

Examples include:

* API availability,
* database connectivity,
* tool access,
* network access,
* filesystem access,
* device reachability,
* or application privileges.

Access establishes technical reach.

It does not establish legitimate action authority.

```
Can reach
≠
May legitimately cause
```

#### Permission

**Question:**

> What does runtime policy currently allow?

Permission is generally evaluated under a defined policy or authorization system.

For example:

```
Principal X
may invoke
Function Y
on Resource Z.
```

This is necessary for secure systems.

But runtime permission still does not establish why the consequential action itself is legitimate.

A financial agent may have permission to invoke a transfer API.

That fact alone does not establish that a particular asset transfer remains supported by valid authority and preserved intent.

#### Authority

**Question:**

> What legitimate source allows this action to be proposed?

Authority concerns the legitimacy source upstream of execution.

In LPP, authority must be explicit and lifecycle-bound.

It may include conditions relating to:

* issuer,
* subject,
* scope,
* validity period,
* signatures,
* delegation,
* revocation,
* consequence class,
* or applicable institutional conditions.

Authority is not inferred from capability.

It is not inferred from access.

It is not inferred from policy permission.

#### Admissibility

**Question:**

> Does the complete authority-bound action remain constitutionally qualified to become executable?

Admissibility evaluates the action in context.

It may require more than a valid Authority Object.

The system may need to determine whether:

* authority remains valid,
* the action remains in scope,
* authorized intent is preserved,
* delegation remains legitimate,
* revocation has not occurred,
* material mutation has not invalidated prior admission,
* required consequence conditions are satisfied,
* and applicable constitutional constraints remain preserved.

Thus:

```
Valid Authority
is necessary

but does not automatically imply

Admissibility.
```

#### Complete Distinction

A principal may therefore simultaneously have:

```
Valid Identity
Valid Access
Valid Runtime Permission
```

and still lack:

```
Valid Authority
```

Or it may possess valid authority while the specific current action has become:

```
Inadmissible
```

because the action has moved outside:

* authorized intent,
* scope,
* validity,
* delegation constraints,
* or other constitutional conditions.

This distinction is central to the entire protocol.