> 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/13.-reference-and-governance/13.4-failure-and-reason-codes.md). # 13.4 Failure & Reason Codes LPP failure semantics have evolved across research publications, protocol specifications, and executable implementations. GitBook v2.0 therefore distinguishes four related but non-identical failure namespaces: 1. **Current Protocol / Research Reason Codes** 2. **Current MVP Operational Reason Codes** 3. **Structural Collapse Taxonomies** 4. **Historical / Legacy Reason Codes** These namespaces must not be silently merged. The same broad governance concern may be represented differently across a research model, protocol specification, executable implementation, or historical architecture. Conversely, two reason codes that produce the same final decision state may still represent different failure semantics. Therefore: > **Semantic relationship does not imply reason-code equivalence.** A failure should always be interpreted together with its: **Decision State + Reason Code + Specification Layer + Version** *** ### A. Current Protocol / Research Reason Codes **Authority Objects v0.2** provides the clearest currently published cross-domain failure mapping for authority-bound admissibility. | Condition | Decision / Reason | | --------------------------------------------- | -------------------------------- | | Malformed Authority Object | `COLLAPSE(MALFORMED_AUTHORITY)` | | No applicable Authority Object | `DENY(NO_AUTHORITY)` | | Authority never minted | `DENY(UNMINTED_AUTHORITY)` | | Authority expired | `DENY(AUTHORITY_EXPIRED)` | | Authority revoked | `DENY(AUTHORITY_REVOKED)` | | Scope not contained | `DENY(SCOPE_FAIL)` | | Required signatures incomplete | `DEFER(INSUFFICIENT_SIGNATURES)` | | Policy state mismatch | `DENY(POLICY_MISMATCH)` | | Required consensus or verification unresolved | `DEFER(CONSENSUS_FAIL)` | | Authorized intent mismatch | `DENY(INTENT_MISMATCH)` | The governing decision priority remains: > **COLLAPSE > DENY > DEFER > ADMIT** This priority reflects the non-compensatory character of Layer 0 admissibility. A lower-priority positive condition cannot override a higher-priority structural or authority failure. For example: * high model confidence cannot compensate for revoked authority; * valid runtime permission cannot compensate for scope failure; * policy compliance cannot compensate for intent mismatch; * semantic agreement cannot create missing authority. *** ### Policy Mismatch and Intent Mismatch Are Distinct The current published research model treats policy mismatch and intent mismatch as separate governance failures. #### Policy mismatch A policy mismatch occurs when the governing policy state or policy binding associated with an admissibility decision is inconsistent with the state expected by the relevant Authority Object, Permit, or execution context. Result: > `DENY(POLICY_MISMATCH)` #### Intent mismatch An intent mismatch occurs when the proposed execution does not preserve the authority-bound or Permit-bound authorized intent. Result: > `DENY(INTENT_MISMATCH)` These failures may both result in `DENY`, but they do not represent the same predicate. Therefore: > **Policy consistency ≠ Intent consistency** A valid policy binding cannot compensate for an intent mismatch. Likewise, preservation of intent cannot compensate for an invalid policy binding. *** ### Decision Mapping Is Versioned Earlier LPP research papers and protocol specifications may classify similar failure conditions differently. For example, some earlier work uses broader structural-collapse terminology, while later Authority Object research maps particular operational conditions to more specific `DENY`, `DEFER`, or `COLLAPSE` outcomes. GitBook v2.0 therefore does not assume that historical reason labels are universally interchangeable. Cross-version interpretation must preserve: * the originating document, * the specification layer, * the decision semantics, * and the version in which the reason code was defined. The centralized cross-version mapping is maintained in: **Appendix 14.14 — Decision & Failure Mapping** *** ## B. Current MVP Operational Reason-Code Set The current **Admission Kernel MVP v0.1 final implementation** uses an implementation-oriented operational reason-code namespace. Source inspection of the final MVP implementation identifies the following **12 operational reason codes**: * `OK` * `NO_PERMIT` * `SIG_FAIL` * `SCOPE_FAIL` * `REPLAY` * `REVOKED` * `EXPIRED` * `POLICY_MISMATCH` * `INTENT_MISMATCH` * `AUTHORITY_EXPIRED` * `AUTHORITY_NOT_ACTIVE` * `INTERNAL_ERROR` These codes describe executable implementation behavior. Their presence in the source implementation does **not** mean that every code has identical validation coverage. Current public evidence may establish a code through one or more different forms of evidence, including: * six-scenario execution evidence, * standalone core verification, * source-level test coverage, * implementation-path inspection, * signed Admission Artifact reconstruction. Therefore: > **Operational code existence ≠ identical validation coverage** This distinction follows the broader public documentation rule: > **Specified ≠ Implemented ≠ Validated ≠ Independently Reproduced** *** ### Current MVP Operational Mapping | MVP Condition | Operational Result | | ---------------------------------------------------------------------------------- | ---------------------------- | | Admission requirements satisfied | `ADMIT(OK)` | | Required Permit absent | `DENY(NO_PERMIT)` | | Permit signature invalid | `DENY(SIG_FAIL)` | | Requested execution exceeds authorized scope | `DENY(SCOPE_FAIL)` | | Permit nonce or bound execution has already been consumed | `DENY(REPLAY)` | | Governing authority has been revoked | `DENY(REVOKED)` | | Execution Permit validity window has expired | `DENY(EXPIRED)` | | Policy binding does not match the governing policy state | `DENY(POLICY_MISMATCH)` | | Execution Intent does not match Permit-bound intent | `DENY(INTENT_MISMATCH)` | | Underlying authority validity period has expired | `DENY(AUTHORITY_EXPIRED)` | | Required Authority Record is not in the expected active state | `DENY(AUTHORITY_NOT_ACTIVE)` | | Admission processing cannot complete because of an internal implementation failure | `DENY(INTERNAL_ERROR)` | The exact path by which an operational reason code is produced remains implementation-specific. The public reason-code mapping describes observable executable semantics; it does not redefine the entire protocol-wide failure taxonomy. *** ### Permit Expiry and Authority Expiry Are Distinct The current final MVP contains both: `EXPIRED` and: `AUTHORITY_EXPIRED` These are **not alternate labels for the same failure condition**. They represent two separate validity failures within the same implementation namespace. #### Permit Expiration `DENY(EXPIRED)` means that the **Execution Permit itself** has exceeded its permitted validity window. The underlying authority may otherwise remain valid and active. #### Authority Expiration `DENY(AUTHORITY_EXPIRED)` means that the **underlying authority itself** has exceeded its validity period. An otherwise structurally valid Permit cannot compensate for an expired authority source. Therefore: > **Permit validity ≠ Authority validity** and: > **`EXPIRED` ≠ `AUTHORITY_EXPIRED`** The distinction preserves the separation between: **temporary execution authorization** and **the continuing validity of the authority from which that authorization derives.** *** ### Revocation and Authority State Are Distinct The final MVP also distinguishes: `REVOKED` from: `AUTHORITY_NOT_ACTIVE` These reason codes may both prevent execution, but they preserve different diagnostic meanings. #### Revoked Authority `DENY(REVOKED)` identifies a revocation condition associated with the authority governing the requested execution. Revocation represents an explicit state transition that removes previously existing authority. #### Authority Not Active `DENY(AUTHORITY_NOT_ACTIVE)` represents a broader operational failure in which the required Authority Record is not in the active state expected by the admission path. This condition should not automatically be interpreted as synonymous with explicit revocation. Therefore: > **Revoked authority is a specific authority-state condition.** while: > **Not-active authority is a broader operational state failure.** The same final Layer 0 decision state does not make the underlying causes equivalent. Thus: > **`REVOKED` ≠ `AUTHORITY_NOT_ACTIVE`** *** ### Policy Mismatch and Intent Mismatch Are Distinct in the Final MVP The current final MVP explicitly distinguishes: > **Policy mismatch → `DENY(POLICY_MISMATCH)`** from: > **Execution-intent mismatch → `DENY(INTENT_MISMATCH)`** These are separate operational reason codes. #### Policy Mismatch The Permit-bound policy state or policy hash is inconsistent with the policy state governing the current execution. Result: > `DENY(POLICY_MISMATCH)` #### Intent Mismatch The current Execution Intent does not match the intent bound to the Permit or otherwise fails the applicable intent-binding predicate. Result: > `DENY(INTENT_MISMATCH)` The distinction is architectural rather than merely lexical. **Policy Binding** and **Intent Binding** are separate admissibility predicates. Therefore: > **Policy consistency cannot compensate for intent mismatch.** and: > **Intent consistency cannot compensate for policy mismatch.** Earlier prototype material may contain provisional or ambiguous mappings between these labels. Those historical mappings must not override the current final MVP implementation. For the current final MVP: > **`POLICY_MISMATCH` ≠ `INTENT_MISMATCH`** *** ### INTERNAL\_ERROR Is an Operational Failure State `INTERNAL_ERROR` belongs to the executable MVP reason-code namespace. It represents a condition in which the admission or execution-control path cannot complete normally because of an internal implementation failure. The important architectural distinction is: > **Implementation failure ≠ constitutional authorization failure** `INTERNAL_ERROR` does not create: * new authority, * new admissibility, * a new constitutional decision category, * or an exception allowing execution to proceed. Instead, the implementation follows a conservative execution posture: > **If the required admission determination cannot be completed, execution must not proceed merely because the admission infrastructure failed.** Therefore, an implementation-level error may result operationally in: > `DENY(INTERNAL_ERROR)` without implying that `INTERNAL_ERROR` is itself a new protocol-level constitutional predicate. *** ### Operational Reason Codes Preserve Diagnostic Meaning The current MVP demonstrates an important distinction between: **Decision State** and **Reason Code**. Several independent failures may all result in: `DENY` but must remain distinguishable. For example: ``` DENY(NO_PERMIT)DENY(SIG_FAIL)DENY(SCOPE_FAIL)DENY(REPLAY)DENY(REVOKED)DENY(EXPIRED)DENY(AUTHORITY_EXPIRED)DENY(AUTHORITY_NOT_ACTIVE)DENY(POLICY_MISMATCH)DENY(INTENT_MISMATCH)DENY(INTERNAL_ERROR) ``` All terminate the execution path. They do not, however, represent the same governance failure. This distinction is necessary for: * audit reconstruction, * incident analysis, * policy evaluation, * authority-state reconstruction, * compliance review, * security testing, * and cross-version interpretation. Therefore: > **Same decision state does not imply same failure semantics.** *** ### MVP Codes Are Not Automatically Protocol-Wide Canonical Codes The current MVP operational reason-code namespace is implementation-specific. It must not automatically be treated as the universal reason-code namespace for: * all LPP specifications, * all LPP research papers, * all future Admission Kernel implementations, * all deployment profiles, * or all domain-specific extensions. A future implementation may preserve the same constitutional semantics while using a different operational encoding. The correct interpretation therefore remains: > **Reason Code + Decision State + Specification Layer + Version** For example: > `DENY(SCOPE_FAIL)` > > * Admission Kernel MVP v0.1 Final Implementation is an implementation-level statement. A research paper may discuss the related condition through a structural failure taxonomy without implying that the research term and executable string belong to the same namespace. Therefore: > **Semantic relationship does not imply namespace identity.** At the same time: > **Distinct operational reason codes within the same current implementation must not be silently merged.** For the current final MVP, this specifically includes: > **`EXPIRED` ≠ `AUTHORITY_EXPIRED`** > **`REVOKED` ≠ `AUTHORITY_NOT_ACTIVE`** > **`POLICY_MISMATCH` ≠ `INTENT_MISMATCH`** *** ## C. Paper 2 Structural Collapse Taxonomy Paper 2 defines a broader structural-collapse taxonomy for reasoning about failure at the constitutional admissibility layer. The taxonomy includes: * Authority Collapse * Scope Collapse * Responsibility Collapse * Revocation Collapse * Boundary Mutation Collapse * Human-Origin Collapse * Evidence Collapse * Delegation Collapse * Context Collapse * Permit Collapse These are **conceptual structural-failure categories**. They are not equivalent to current MVP operational reason-code strings. A system or research analysis may therefore maintain both: **Structural Failure Category** and: **Implementation Reason Code** as separate fields. For example: > `DENY(SCOPE_FAIL)` may correspond to a concrete implementation-level rejection caused by scope containment failure. A research discussion may simultaneously analyze that event under a broader scope-related structural-failure category. That relationship does not make: `SCOPE_FAIL` and: `Scope Collapse` the same namespace or the same formal object. Therefore: > **Analytical taxonomy ≠ executable reason-code namespace** Structural collapse terminology remains useful for reasoning about constitutional failure classes, while operational reason codes remain useful for deterministic implementation behavior and evidence reconstruction. *** ## D. Historical / Legacy Reason Codes Protocol Core v1.1 and earlier LPP architecture generations include historical reason codes such as: * `DENY_NON_INSTANTIABLE` * `DENY_AUTHORITY_COLLAPSE` * `DENY_EXPIRED` * `DENY_DEGRADED` * `DENY_INSUFFICIENT_AUTHORITY` * `DENY_TRANSFER` * `DENY_RECOGNITION` * `DENY_SOVEREIGNTY_CONFLICT` * `DENY_SCSP_LOCK` These remain valid when interpreting the historical documents in which they were defined. They are **not automatically the canonical GitBook v2.0 public reason-code namespace**. Protocol Core v1.1 is retained as a historical / transitional source and contains terminology, architectural assumptions, and operational mappings that have since been normalized or superseded. Historical reason-code strings must therefore not override: * current constitutional definitions, * current published research mappings, * or current MVP operational behavior. For example, the presence of: `DENY_SCSP_LOCK` in a historical namespace does not redefine the current role of Anti-SCSP within the Mind Universe / LPP architecture. Legacy terminology must be interpreted within its originating version. *** ## Historical Documents Remain Historically Accurate GitBook v2.0 does not retroactively rewrite earlier publications simply to make all reason-code strings identical. Doing so would destroy useful version history. Instead, LPP preserves the distinction between: **historical accuracy** and **current canonical interpretation**. An older paper or specification may therefore retain its original terminology while GitBook v2.0 provides the normalized interpretation required for current architecture work. This also means that a historical code should not be treated as erroneous solely because the current MVP uses a different representation. The relevant question is: > **What did this code mean in its originating specification layer and version?** *** ## Failure-Code Interpretation Rule The canonical documentation rule is: > **Always identify the Decision State, Reason Code, Specification Layer, and Version when citing a failure.** For example: **DENY**\ +\ **SCOPE\_FAIL**\ +\ **Authority Objects v0.2** is more precise than simply stating: **scope collapse** Likewise: **DENY**\ +\ **INTENT\_MISMATCH**\ +\ **Admission Kernel MVP v0.1 — Final Implementation** is more precise than stating: **intent failure** And: **DENY**\ +\ **AUTHORITY\_EXPIRED**\ +\ **Admission Kernel MVP v0.1 — Final Implementation** must not be silently collapsed into: **DENY(EXPIRED)** because the final MVP distinguishes authority expiration from Permit expiration. *** ## Cross-Version Interpretation Rule When comparing reason codes across different LPP generations, the following rule applies: > **Same conceptual family**\ > **≠**\ > **necessarily the same formal failure**\ > **≠**\ > **necessarily the same reason-code string.** Similarly: > **Same final decision state**\ > **≠**\ > **same failure cause.** And: > **Same or similar terminology across different layers**\ > **≠**\ > **automatic namespace equivalence.** Every mapping must preserve its source context. *** ## Current Final MVP Precision Rule For the current Admission Kernel MVP v0.1 final implementation, the following distinctions are normative for interpreting executable behavior: > **`EXPIRED` ≠ `AUTHORITY_EXPIRED`** Permit expiration and authority expiration are separate failure conditions. > **`REVOKED` ≠ `AUTHORITY_NOT_ACTIVE`** Explicit revocation and broader non-active authority state are separate operational conditions. > **`POLICY_MISMATCH` ≠ `INTENT_MISMATCH`** Policy binding and intent binding are separate predicates. These distinctions must be preserved in: * Public Proof evidence, * validation reports, * audit reconstruction, * implementation documentation, * GitBook mappings, * and future cross-version reason-code tables. *** ## Canonical Rule The governing rule for LPP failure semantics is: > **Decision state identifies what happens.**\ > **Reason code identifies why.**\ > **Specification layer identifies where the meaning is defined.**\ > **Version identifies which definition applies.** Therefore: > **Never interpret a reason code without its decision state, specification layer, and version.** And: > **Never merge distinct current operational reason codes solely because they produce the same decision outcome.** This rule preserves technical precision while allowing LPP research, protocol specifications, executable implementations, and historical documents to evolve without silently rewriting one another.