> 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/8.-security-and-enforcement/8.9-admission-artifact-verification.md).

# 8.9 Admission Artifact Verification

The **Admission Artifact** provides reconstructable governance evidence.

The current verification specification defines the Artifact as a:

> **signed, structured, tamper-evident proof object**

rather than an ordinary narrative log.

The verification objective is that a qualified verifier can reconstruct the governance basis of execution without relying solely on internal system assertions.

The reference verification path includes seven principal checks.

***

#### 1. Signature Validation

The verifier checks the Control Plane signature using the appropriate public verification key.

Conceptually:

```
Verify(
    AA.CP_Signature,
    CP_Public_Key
)
```

If the signature is invalid:

```
Artifact invalid
```

The Artifact cannot be trusted as authentic Control Plane evidence.

***

#### 2. Policy Integrity

The verifier reconstructs or retrieves the governing policy version corresponding to the Artifact timestamp.

The stored:

```
Policy_Version_Hash
```

is compared with the authoritative versioned policy record.

A mismatch may indicate:

* policy downgrade,
* policy substitution,
* or evidence tampering.

***

#### 3. Authority Snapshot Reconstruction

The verifier reconstructs the relevant authority state at the time of the admission or execution event.

Relevant conditions include:

```
Authority_ID
State = ACTIVE
Expiry > T
Revoked = FALSE
```

This prevents present-day authority state from being incorrectly substituted for historical authority state.

The question is:

> **Was the authority valid then?**

not merely:

> **What is the authority state now?**

***

#### 4. Scope Validation

The verifier reconstructs the authorized scope and compares the execution intent against it.

Conceptually:

```
Execution Intent
⊆
Authorized Scope
```

If the actual execution exceeded the authority envelope:

```
Scope violation
```

is established.

***

#### 5. Replay Protection Check

The verifier evaluates:

```
Permit_ID
+
Nonce
```

and confirms that the authorization material was not improperly reused.

It also checks the Execution Intent binding.

This connects Artifact verification to the execution-boundary replay model.

***

#### 6. Revocation Check

The verifier determines whether a revocation event occurred:

* before execution,
* or during the relevant execution window where continuous authority was required.

A valid signature from an earlier time does not erase a later revocation state.

***

#### 7. Execution Result Integrity

The Artifact carries:

```
Execution_Result_Hash
```

or an equivalent result commitment.

The verifier compares this with the authoritative execution outcome record.

The purpose is to establish that:

```
Governance Evidence
```

corresponds to:

```
Actual Effect
```

rather than to a different or fabricated execution record.

***

#### Reconstruction Path

The reference audit path is:

```
Admission Artifact
        ↓
Control Plane Public Key
        ↓
Policy Registry Snapshot
        ↓
Authority Ledger
        ↓
Scope Registry
        ↓
Revocation Log
        ↓
Execution Result / Log Hash
```

The goal is:

> **Independently reconstructable governance.**

#### Chain Integrity

The Artifact specification requires tamper-evident custody.

Reference mechanisms include:

* append-only storage,
* cryptographic chaining,
* trusted timestamps,
* and optional distributed replication.

The exact production storage architecture may vary.

The public invariant is that evidence integrity must not depend only on a mutable narrative database record.

#### Evidence Grades

The existing verification specification also describes different evidence-strength profiles.

A stronger evidence profile may include:

* complete signature chain,
* policy-registry anchoring,
* and immutable ledger evidence.

A more limited profile may rely primarily on Control Plane verification.

GitBook v2.0 treats these as technical deployment profiles rather than universal proof that every current Artifact reaches the highest possible evidence grade.

#### Artifact Verification Non-Goal

Admission Artifact verification does not independently prove:

* model correctness,
* ethical alignment,
* general legal compliance,
* or organizational maturity.

It proves and reconstructs the defined authority-bound governance state represented by the Artifact.