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

# 12.1 Cross-System Authority

AI-triggered execution increasingly crosses system boundaries.

A task may begin in:

```
System A
```

and eventually produce an action in:

```
System B.
```

The central governance question is:

> **Does authority recognized in System A remain legitimate when the action crosses into System B?**

LPP does not assume that authority is automatically portable.

The general rule is:

```
Authority Valid in System A
⇏
Authority Automatically Valid in System B
```

Cross-system authority requires recognition.

#### Transfer Model

The Authority Object model includes an explicit cross-system relationship.

Conceptually:

```
Authority Object
        ↓
Origin System
        ↓
Recognition Boundary
        ↓
Target System
```

The published security invariant is:

```
Transfer(AO, S₁, S₂)
requires
MutualRecognition(AO, S₂) = VERIFIED
```

Therefore:

```
No Cross-System Recognition
        ↓
No inherited admissibility
```

#### What Must Survive Transfer

A cross-system transfer must not reduce the Authority Object to a bare identifier.

The receiving system must preserve or be able to verify the governance-relevant properties on which authority depends.

These may include:

* issuer identity,
* subject identity,
* scope,
* validity,
* revocation state,
* applicable signatures,
* policy binding,
* consequence constraints,
* delegation state,
* and authority–intent binding.

The exact representation may differ between systems.

The semantic constraints may not silently disappear.

#### Recognition Is Not Copying

Cross-system interoperability does not mean:

```
Copy AO JSON
        ↓
Automatically trust it.
```

The receiving system must determine whether:

* the issuer is recognized,
* the signature or proof is valid,
* the authority class is understood,
* the scope is interpretable,
* the relevant policy state is compatible,
* revocation can be checked,
* and the receiving system recognizes the authority relationship.

#### Policy Compatibility

Authority may be valid under one policy state but incompatible with another system's governing state.

The Authority Object security model therefore includes the invariant:

```
AO.policy_hash ≠ G.P.current_hash
        ↓
No ADMIT

unless an applicable
mutual-recognition relationship exists.
```

Interoperability does not require identical internal policy engines.

It requires a defined way to determine whether the relevant governance states are compatible.

#### Cross-System Intent Preservation

Authority portability alone is insufficient.

Suppose System A sends a legitimately authorized task to System B.

If System B materially transforms the task:

```
Authorized Intent H
        ↓
System A
        ↓
Cross-System Transfer
        ↓
System B Transformation
        ↓
Action H'
```

then the system must still evaluate whether:

```
H' preserves H.
```

Thus cross-system interoperability also depends on Chapter 6:

> **Material Mutation ⇒ Re-Admission**

#### Revocation Across Systems

Cross-system authority is only meaningful if revocation can propagate or remain discoverable.

The receiving system must not preserve stale authority indefinitely after the upstream legitimacy state has changed.

Potential implementations may vary.

The invariant remains:

```
Revoked upstream authority
⇏
continued legitimate downstream execution
```

#### Legacy Protocol-Core Boundary

Earlier Protocol Core versions represented cross-system recognition using fields and mechanisms including:

* mutual-recognition status,
* sovereign badge concepts,
* and SVNN consensus signatures.

GitBook v2.0 preserves the **cross-system recognition requirement** but does not make every legacy mechanism a universal interoperability requirement.

In particular:

```
Legacy SSB field
≠
mandatory current cross-system standard
```

and:

```
SVNN evidence
≠
authority source
```

The current canonical rule is narrower:

> **Cross-system authority must remain verifiable, recognized, bounded, and traceable.**