> 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.8-object-relationship-model.md).

# 4.8 Object Relationship Model

The governance objects form a dependency graph.

The shortest public representation is:

```
Authority
→ Intent
→ Admission
→ Permit
→ Execution
→ Evidence
```

The expanded object model is:

```
Human / Institutional Authority
        ↓
Authority Object
        +
Human-Authorized Intent
        ↓
Authority–Intent Binding
        ↓
Task / Agent Trajectory
        ↓
Action Candidate
        ↓
Canonical Intent Commitment
        ↓
Execution Intent
        ↓
Semantic / Governance Verification
        ↓
LPP Admission Decision
        ↓
ADMIT only
        ↓
Execution Permit
        ↓
Execution
        ↓
Admission Artifact
```

#### Authority Object → Human-Authorized Intent

The Authority Object establishes legitimate authority.

Human-Authorized Intent establishes authorized meaning.

Both are required because:

```
Who may authorize?
```

and:

```
What was authorized?
```

are different questions.

#### Human-Authorized Intent → Canonical Intent Commitment

Authorized meaning must survive transformation into a form suitable for trajectory verification.

The Canonical Intent Commitment provides that reference.

#### Canonical Intent Commitment → Execution Intent

The system compares evolving action proposals against the authorized semantic reference.

The concrete Execution Intent represents the specific action now being requested.

#### Execution Intent → Admission

The Admission Kernel evaluates the Execution Intent together with relevant governance state.

A successful result is:

```
ADMIT
```

A failed or unresolved result may be:

```
DENY
DEFER
COLLAPSE
```

#### Admission → Execution Permit

Only `ADMIT` may produce the normal execution authorization path.

```
ADMIT
→
Permit
```

not:

```
DENY
→
Permit
```

#### Permit → Execution

The Execution Plane must present and verify the Permit at the execution boundary.

The Permit is therefore both:

* a constrained credential,
* and a bridge between Control Plane admission and Execution Plane actuation.

#### Execution → Admission Artifact

The Artifact preserves the governance basis and relevant execution evidence.

This allows the lifecycle to be reconstructed later.

#### No Reverse Authority Flow

The architecture does not permit authority to flow backward from execution.

The following is invalid:

```
Execution succeeded
        ↓
Therefore it must have been legitimate.
```

Likewise:

```
Permit exists
        ↓
Therefore authority must exist.
```

and:

```
Many agents agreed
        ↓
Therefore authority exists.
```

The valid authority direction remains upstream:

```
Authority
        ↓
Intent
        ↓
Admission
        ↓
Permit
        ↓
Execution
```