> 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.1-authority-object.md).

# 4.1 Authority Object

The **Authority Object (AO)** is the structured, machine-verifiable legitimacy carrier used by LPP to represent upstream authority for AI-triggered execution.

It answers:

> **What authority existed before execution?**

An Authority Object exists upstream of the Execution Permit.

It establishes why legitimate permission may exist.

The Execution Permit later constrains what may actually be executed.

The distinction is:

```
Authority Object
=
Why legitimate execution authority may exist

Execution Permit
=
What constrained execution is allowed now
```

#### Core Properties

A canonical Authority Object has five essential characteristics.

**Externally Grounded**

Authority must originate outside the AI system's self-generated reasoning.

An agent cannot establish valid authority merely by concluding that an action is reasonable.

```
AI reasoning
⇏
Authority
```

**Scoped**

Authority applies only within defined boundaries.

Relevant boundaries may include:

* principal,
* action type,
* target,
* domain,
* jurisdiction,
* parameters,
* consequence class,
* institutional conditions,
* or other authorized limits.

Authority is therefore not equivalent to a global permission.

**Lifecycle-Bound**

Authority is stateful.

It may be:

* created,
* activated,
* degraded,
* invalidated,
* expired,
* or revoked.

The validity of an Authority Object must therefore be evaluated at the relevant time.

```
Valid once
⇏
Valid forever
```

**Verifiable**

The object may carry or reference machine-verifiable evidence such as:

* signatures,
* approval state,
* policy binding,
* validity conditions,
* revocation state,
* or consensus / verification evidence where required.

The exact verification requirements depend on the applicable LPP profile and consequence class.

**Admission-Bearing**

The Authority Object is evaluated by the Admission Kernel.

It does not directly execute an action.

It provides the legitimacy state against which a proposed Execution Intent may be evaluated.

#### Canonical Authority Object Structure

The published Authority Objects specification defines a canonical grammar containing fields conceptually corresponding to:

```
AuthorityObject {
    authority_id
    subject_identity
    issuer_identity
    jurisdiction_scope
    action_scope
    irreversibility_class
    required_signatures
    signature_status
    validity_window
    temporal_decay_model
    revocation_state
    revocation_log
    cross_system_transfer
    policy_binding
    consensus_signature
    status
}
```

The exact public schema used by GitBook v2.0 is defined separately in the public schema appendix.

The important semantic point is that authority is represented as a **structured lifecycle object**, not as an informal approval statement.

#### Authority Lifecycle State

Published Authority Object research uses the lifecycle domain:

```
UNMINTED
MINTED
INVALID
EXPIRED
REVOKED
```

The precise implementation representation may vary.

The architectural rule does not:

> An Authority Object must be in a valid state at the time its authority is relied upon.

#### Authority Object Is Not an Access Token

An access or capability token primarily answers:

> What resource or operation may this holder access?

An Authority Object answers a different question:

> What legitimate upstream authority supports this AI-triggered action?

Therefore:

```
Access Token
≠
Authority Object
```

#### Authority Object Is Not a Consent Note

A human approval record may prove that someone agreed to something.

For consequential AI execution, that approval must still be bound to relevant governance conditions such as:

* subject,
* action,
* scope,
* time,
* consequence,
* revocation,
* and the meaning actually authorized.

A generic approval statement is therefore weaker than a structured Authority Object.

#### Authority Object Is Not an Audit Log

Audit logs describe events.

Authority Objects exist before execution and help determine whether execution may legitimately proceed.

A complete record of an unauthorized action does not make the action authorized.

#### Authority Object and Admission

A simplified relationship is:

```
Authority Object
        ↓
Authority validation
        ↓
Scope validation
        ↓
Lifecycle / revocation validation
        ↓
Other applicable predicates
        ↓
LPP Admission Kernel
```

A valid Authority Object is a necessary upstream legitimacy carrier.

It does not alone guarantee final admission.

This becomes especially important once authorized intent and trajectory-level semantic preservation are introduced.

***