> 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/12.-interoperability-and-standards/12.6-verifiable-governance-objects.md).

# 12.6 Verifiable Governance Objects

###

LPP interoperability depends on governance objects being externally inspectable rather than meaningful only inside one implementation.

The central objects include:

```
Authority Object
Human-Authorized Intent
Authority–Intent Binding
Canonical Intent Commitment
Execution Intent
Execution Permit
Admission Artifact
```

Not every system needs to use the same internal storage representation.

But interoperable systems need a shared understanding of the semantics they exchange.

#### Machine-Verifiable Authority

The Authority Object must carry or reference enough information to verify:

* issuer,
* subject,
* scope,
* lifecycle,
* validity,
* revocation,
* policy binding,
* and applicable evidence.

The object is therefore more than descriptive metadata.

It participates in admissibility.

#### Signed Execution Authorization

The Execution Permit must be verifiable by the execution boundary.

An external executor should be able to determine:

```
Who issued this Permit?

What action is it bound to?

What scope applies?

When does it expire?

Has it been invalidated?

Does the signature verify?
```

#### Signed Governance Evidence

The Admission Artifact provides the evidence counterpart.

An external verifier should be able to reconstruct, within the applicable profile:

* authority state,
* scope,
* intent,
* policy state,
* decision,
* Permit,
* replay status,
* revocation state,
* and resulting execution evidence.

#### Semantic Interoperability

Object interoperability is not achieved merely by agreeing on field names.

For example, two systems might both expose:

```
scope
```

while interpreting it differently.

True interoperability requires agreement or explicit mapping of meaning.

Therefore:

```
Schema Compatibility
≠
Governance Semantic Compatibility
```

#### Versioning

Governance objects must also be version-aware.

A receiving system should know which:

* object version,
* policy version,
* canonical schema,
* or protocol semantics

were used.

Without this, cross-system evidence can become ambiguous after protocol evolution.

#### Portable Proof

The longer-term objective is:

```
Governance Decision
        ↓
Signed / Verifiable Object
        ↓
Independent System
        ↓
Reconstruction
```

This is a stronger interoperability property than requiring the receiving party to trust the original runtime's narrative explanation.