> 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.2-authority-plane.md).

# 3.2 Authority Plane

The Authority Plane establishes legitimate origin.

It answers the first architectural question:

> **Where did the authority and authorized meaning come from?**

Its primary elements are:

* Authority Object,
* Human-Authorized Intent,
* Authority–Intent Binding,
* authority lifecycle,
* validity,
* revocation,
* and delegation constraints.

The Authority Plane does not execute actions.

#### Authority Object

The Authority Object represents the structured conditions under which authority exists.

Its role is to convert authority from an implicit assumption into an explicit governance object.

Depending on the applicable specification, it may represent information such as:

* authority identifier,
* issuer,
* subject,
* scope,
* validity,
* required signatures,
* lifecycle state,
* delegation conditions,
* revocation state,
* consequence requirements,
* and responsibility references.

The central idea is:

> **Authority should be machine-verifiable rather than merely inferred.**

#### Human-Authorized Intent

Authority alone does not fully answer what the authority permitted.

Human-Authorized Intent represents the human or institutional meaning from which execution legitimacy derives.

This distinction prevents the architecture from treating:

```
Person X possesses authority
```

as equivalent to:

```
Person X authorized every action
that an AI system can technically derive.
```

Authority answers:

> **Who can authorize?**

Intent answers:

> **What was authorized?**

#### Authority–Intent Binding

The two objects must remain connected.

Without binding, a valid Authority Object could become a reusable authorization token for unrelated semantic objectives.

The architectural requirement is therefore:

```
Authority Object
        ↕
Human-Authorized Intent
```

A changed objective may require a new binding or re-admission.

#### Authority Lifecycle

Authority is stateful.

It is not assumed to remain valid forever because it was valid once.

Relevant state changes may include:

* activation,
* expiry,
* suspension,
* revocation,
* degradation,
* invalidation,
* or other protocol-defined lifecycle transitions.

The important architectural rule is:

```
Authority valid at T₀
⇏
Authority valid at T₁
```

#### Delegation

Delegation does not permit unlimited authority expansion.

If authority moves across:

```
Principal A
→ Agent B
→ Agent C
```

the delegated authority must remain bounded by the legitimate authority of the upstream source.

The architecture rejects silent privilege inheritance.

It also rejects the idea that adding more agents can create more authority than existed at the beginning.

#### Authority Plane Boundary

The Authority Plane may establish and maintain legitimate authority state.

It does not:

* perform the action,
* substitute for task governance,
* determine physical safety,
* or allow the Execution Plane to authorize itself.

Its output becomes an input to later governance.