> 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/11.-public-proof-and-validation/11.5-six-core-execution-scenarios-and-artifact-verification.md).

# 11.5 Six Core Execution Scenarios & Artifact Verification

The current validation model contains two distinct tracks:

> **Track A — Execution-Path Validation**

and:

> **Track B — Artifact Verification / Audit Reconstruction**

They must not be merged.

***

### Track A — Six Core Execution Scenarios

#### Scenario 1 — Valid Execution

**Objective**

Verify that a correctly authorized action can traverse the governed execution path.

**Observed result**

> `ADMIT / OK`

Validated property:

A valid action can proceed rather than being universally blocked.

***

#### Scenario 2 — No Permit

**Objective**

Verify that governed execution cannot proceed without a required Permit.

**Observed result**

> `DENY / NO_PERMIT`

Validated property:

> **No valid Permit → No governed execution**

***

#### Scenario 3 — Scope Violation

**Objective**

Verify that a Permit cannot authorize an execution outside its approved scope.

**Observed result**

> `DENY / SCOPE_FAIL`

Validated property:

Execution authorization is scope-bound.

***

#### Scenario 4 — Permit Tampering

**Objective**

Verify that modification of a signed Permit invalidates the execution path.

**Observed result**

> `DENY / SIG_FAIL`

Validated property:

Permit integrity is cryptographically enforced.

***

#### Scenario 5 — Replay

**Objective**

Verify that previously consumed authorization cannot be reused.

**Observed result**

First execution:

> `ADMIT / OK`

Replay:

> `DENY / REPLAY`

Validated property:

Consumed authorization state cannot simply be replayed through the demonstrated path.

***

#### Scenario 6 — Post-Revocation Execution

**Objective**

Verify that revoked authority no longer supports later governed execution.

**Observed result**

> `DENY / REVOKED`

Validated property:

Revocation affects subsequent execution eligibility.

The published Public Proof v2.0 reports all six scenarios as observed according to expectation.

***

## Track B — Admission Artifact Verification / Audit Reconstruction

Artifact Verification is **not a seventh execution scenario**.

It evaluates the evidence and reconstructability path rather than introducing another ADMIT / DENY scenario.

The protocol-level Admission Artifact Verification Specification defines seven verification categories:

1. Signature Validation
2. Policy Integrity Check
3. Authority State Reconstruction
4. Scope Validation
5. Replay Protection Check
6. Revocation Check
7. Execution Result Integrity

The purpose is to determine whether the authority-bound basis of consequential execution can be reconstructed from evidence.

### Current MVP Artifact-Verifier Boundary

The current final MVP mechanically performs six direct reconstruction checks in its Artifact Verification endpoint:

1. CP signature
2. policy hash
3. authority-state hash
4. scope hash
5. execution-result hash
6. artifact-chain linkage

Replay and revocation remain part of the broader reconstruction model, but in the current MVP they are primarily exercised through execution-path and state validation rather than represented as two additional standalone endpoint checks.

Therefore:

> **Protocol-level Artifact Verification categories ≠ current MVP endpoint check count**

and:

> **Current MVP endpoint check count ≠ Public Proof verifier check count**

These are different layers.

### Public Evidence Verifier

Public Proof v2.0 additionally provides a standalone evidence verifier for the disclosed release package.

Current result:

> **113/113 PASS**

The 113 checks validate the integrity and consistency of the **publicly disclosed evidence set**.

They are not:

* 113 LPP protocol requirements,
* 113 independent MVP scenarios,
* or a completed conformance suite.

***

### Validation Set Boundary

Therefore:

> **Six Core Execution Scenarios**\
> \= Execution-Path Validation Set

not:

> **Six Core Execution Scenarios**\
> \= Complete MVP Validation

Likewise:

> **113/113 Public Evidence Verification**\
> \= disclosed evidence-package verification

not:

> **113/113 independent reproduction of the private MVP**

The correct interpretation is:

> Six core scenarios validate selected execution-boundary behavior.

> Artifact Verification validates evidence reconstruction through a separate track.

> Public Proof v2.0 makes the disclosed evidence package mechanically recheckable.

> Together, these remain narrower than complete LPP protocol validation.