> 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/14.-appendix/14.14-decision-and-failure-mapping.md). # 14.14 Decision & Failure Mapping This section centralizes current decision semantics and failure-code interpretation across LPP research, protocol specifications, the current Admission Kernel MVP, and historical documents. Its purpose is not to force every document generation into one universal string namespace. Its purpose is to make cross-version interpretation explicit. The governing rule is: > **Decision State + Reason Code + Specification Layer + Version** must be preserved when interpreting a failure. Therefore: > **Same decision state does not imply the same failure cause.** and: > **Semantic relationship does not imply reason-code identity.** and: > **Historical terminology must not silently override current executable semantics.** *** ### A. Canonical Layer 0 Decisions The canonical Layer 0 decision domain is: * `ADMIT` * `DENY` * `DEFER` * `COLLAPSE` The governing priority is: > **COLLAPSE > DENY > DEFER > ADMIT** #### ADMIT The required admissibility predicates are satisfied under the governing Layer 0 state. `ADMIT` means that the action may proceed toward Execution Permit issuance. It does not mean that execution has already occurred. *** #### DENY A required admissibility condition has failed under the current governance state. Execution must not proceed through the evaluated path. *** #### DEFER The admissibility determination cannot yet be completed because required: * signatures, * evidence, * verification, * consensus, * approval, * or other mandatory information remains unresolved. Therefore: > **DEFER ≠ ADMIT** No execution authorization is created while the required condition remains unresolved. *** #### COLLAPSE A structural or constitutional failure prevents a valid admissibility basis from being established. `COLLAPSE` is conceptually stronger than ordinary rejection. The distinction is: > **DENY = the request fails under the current admissibility state.** while: > **COLLAPSE = the legitimacy structure required for the admission path has failed.** Current MVP decision coverage remains: | Decision | Protocol Status | Current MVP Status | | ---------- | --------------- | ------------------------------------------------- | | `ADMIT` | Specified | Implemented / Validated | | `DENY` | Specified | Implemented / Validated | | `DEFER` | Specified | Not currently claimed as implemented or validated | | `COLLAPSE` | Specified | Not currently claimed as implemented or validated | Therefore: > **Protocol decision completeness does not imply implementation completeness.** *** ## B. Current Published Authority Object Mapping The currently published Authority Object research provides the clearest cross-domain mapping between authority-related failure conditions and Layer 0 outcomes. | Condition | Current Published Mapping | | ----------------------------------------- | -------------------------------- | | 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 unresolved | `DEFER(INSUFFICIENT_SIGNATURES)` | | Policy mismatch | `DENY(POLICY_MISMATCH)` | | Required quorum / verification unresolved | `DEFER(CONSENSUS_FAIL)` | | Authority-bound intent mismatch | `DENY(INTENT_MISMATCH)` | This mapping is a **research / protocol-layer namespace**. It must not automatically be assumed to be the exact string namespace used by every executable implementation. The current GitBook already treats these mappings as versioned rather than universally interchangeable. Additional published failure vocabulary includes terms such as: * `AUTHORITY_INACTIVE` * `AUTHORITY_DEGRADED` * `RISK_THRESHOLD_FAIL` * `TRANSFER_FAIL` Their presence in published material does not mean that each term already has one universally frozen implementation string across all profiles and versions. *** ### Published Policy and Intent Failures Are Distinct The published model distinguishes: > `DENY(POLICY_MISMATCH)` from: > `DENY(INTENT_MISMATCH)` Policy state and authorized intent are separate admissibility predicates. Therefore: > **Policy consistency ≠ Intent consistency** A valid policy state cannot compensate for a failure to preserve authorized intent. Likewise, preserved intent cannot compensate for an invalid governing policy binding. *** ## C. Current Final MVP Operational Mapping The **Admission Kernel MVP v0.1 final implementation** uses its own implementation-oriented reason-code namespace. Source inspection of the final implementation identifies **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` This set supersedes earlier prototype-level summaries that listed only a subset of the executable reason-code namespace. #### Current 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 replay detected | `DENY(REPLAY)` | | Governing authority has been revoked | `DENY(REVOKED)` | | Execution Permit has expired | `DENY(EXPIRED)` | | Policy binding mismatch | `DENY(POLICY_MISMATCH)` | | Execution Intent mismatch | `DENY(INTENT_MISMATCH)` | | Underlying authority has expired | `DENY(AUTHORITY_EXPIRED)` | | Required authority is not in the required active state | `DENY(AUTHORITY_NOT_ACTIVE)` | | Admission processing fails because of an internal implementation condition | `DENY(INTERNAL_ERROR)` | These codes describe executable implementation behavior. However: > **Operational code existence ≠ identical validation coverage.** Some reason codes are represented in the six core execution scenarios. Others are exercised through core verification, implementation tests, or source-path inspection. The presence of a reason code in the final implementation therefore must not automatically be rewritten as: > independently reproduced, or: > validated across every deployment profile. The broader status discipline remains: > **Specified ≠ Implemented ≠ Validated ≠ Independently Reproduced** *** ### C.1 Permit Expiration and Authority Expiration The final MVP contains both: > `EXPIRED` and: > `AUTHORITY_EXPIRED` These are **two different operational failures inside the same implementation namespace**. They are not different strings for the same conceptual failure. #### Permit expiration `DENY(EXPIRED)` means that the **Execution Permit** has exceeded its permitted validity window. #### Authority expiration `DENY(AUTHORITY_EXPIRED)` means that the **underlying Authority Record** has exceeded its validity period. Therefore: > **Permit validity ≠ Authority validity** and: > **`EXPIRED` ≠ `AUTHORITY_EXPIRED`** An Execution Permit is a short-lived downstream authorization derivative. Authority is the upstream legitimacy source on which that Permit depends. A Permit cannot make expired authority legitimate again. *** ### C.2 Revocation and Non-Active Authority State The final MVP also distinguishes: > `REVOKED` from: > `AUTHORITY_NOT_ACTIVE` These may both produce `DENY`, but they preserve different diagnostic meanings. #### REVOKED `DENY(REVOKED)` represents an explicit revocation condition. It reflects a governance transition in which previously valid authority has been withdrawn. #### AUTHORITY\_NOT\_ACTIVE `DENY(AUTHORITY_NOT_ACTIVE)` represents a broader operational state failure in which the authority required by the admission path is not in the required active state. Therefore: > **`REVOKED` ≠ `AUTHORITY_NOT_ACTIVE`** Explicit revocation is a specific authority-state condition. Non-active authority is a broader executable state failure. *** ### C.3 Policy Mismatch and Intent Mismatch The final MVP explicitly distinguishes: > `DENY(POLICY_MISMATCH)` from: > `DENY(INTENT_MISMATCH)` This resolves the ambiguity present in earlier prototype material. Earlier MVP documentation used wording such as: > `POLICY_MISMATCH / INTENT_MISMATCH` for the execution-intent mismatch path. The original MVP Blueprint contains that earlier combined notation. That wording must now be interpreted as **historical prototype material**, not as the current final implementation mapping. For the final implementation: #### Policy mismatch The applicable policy binding does not match the state bound to the execution authorization. → `DENY(POLICY_MISMATCH)` #### Intent mismatch The current Execution Intent does not match the Permit-bound authorized intent. → `DENY(INTENT_MISMATCH)` Therefore: > **`POLICY_MISMATCH` ≠ `INTENT_MISMATCH`** *** ### C.4 INTERNAL\_ERROR `INTERNAL_ERROR` belongs to the implementation-level operational namespace. It represents an admission path that cannot complete because of an internal implementation condition. It must not be interpreted as a new constitutional admissibility category. The architectural rule remains: > **Implementation failure ≠ constitutional authorization.** An internal failure cannot become a reason to bypass admission. The conservative executable behavior is therefore: > `DENY(INTERNAL_ERROR)` rather than: > fail open and execute. *** ## D. Current MVP Diagnostic Separation The final MVP demonstrates why: > **Decision State** and: > **Reason Code** must remain separate fields. The following may all result in `DENY`: ``` 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) ``` But they do not mean the same thing. The distinction is required for: * audit reconstruction, * incident analysis, * authority-state reconstruction, * execution forensics, * policy evaluation, * security testing, * validation evidence, * and cross-version interpretation. Therefore: > **Same decision state ≠ same failure semantics.** *** ## E. Paper 2 Structural Collapse Categories Paper 2 uses a broader structural collapse taxonomy, including: * Authority Collapse * Scope Collapse * Responsibility Collapse * Revocation Collapse * Boundary Mutation Collapse * Human-Origin Collapse * Evidence Collapse * Delegation Collapse * Context Collapse * Permit Collapse These are **structural analytical categories**. They are not equivalent to MVP string reason codes. The architecture may therefore preserve both: > **Structural Failure Category** and: > **Operational Reason Code** for the same analyzed event. For example: `DENY(SCOPE_FAIL)` is a concrete operational decision. A research analysis may additionally classify the underlying governance condition within a broader scope-related structural failure category. That does not make the two terms interchangeable. Therefore: > **Structural taxonomy ≠ executable namespace** *** ## F. Legacy Protocol Core v1.1 Mapping Protocol Core v1.1 contains 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 Protocol Core v1.1. For example, its historical admission logic includes explicit mappings such as `DENY_NON_INSTANTIABLE`, `DENY_AUTHORITY_COLLAPSE`, `DENY_EXPIRED`, `DENY_DEGRADED`, and `DENY_INSUFFICIENT_AUTHORITY`. They are not automatically the canonical GitBook v2.0 reason-code namespace. Protocol Core v1.1 also contains historical architecture assumptions involving: * earlier SSB definitions, * earlier SVNN responsibilities, * cross-system sovereign-recognition models, * legacy SCSP Lock terminology, * and other concepts subsequently normalized. For this reason: > **Legacy reason codes remain historically valid but do not override current canonical interpretation.** In particular: `DENY_SCSP_LOCK` must remain inside its historical Protocol Core context. Its presence does not redefine the current role or terminology of Anti-SCSP. *** ## G. Cross-Namespace Mapping Rules When comparing failure semantics across: * current research, * protocol specifications, * final MVP implementation, * and legacy documents, the following rules apply. #### Rule 1 — Same String Does Not Guarantee Same Namespace A reason-code string may appear in more than one document generation. Its interpretation must still preserve its source layer and version. *** #### Rule 2 — Similar Meaning Does Not Require Identical String Different specification layers may describe related governance conditions differently. That alone does not indicate contradiction. *** #### Rule 3 — Same DENY Does Not Mean Same Failure For example: `DENY(SIG_FAIL)` and: `DENY(INTENT_MISMATCH)` both block execution. One represents cryptographic integrity failure. The other represents execution-intent binding failure. They are not semantically equivalent. *** #### Rule 4 — Current Same-Namespace Distinctions Must Be Preserved When the current final MVP itself distinguishes two codes, GitBook must not merge them. Specifically: > **`EXPIRED` ≠ `AUTHORITY_EXPIRED`** > **`REVOKED` ≠ `AUTHORITY_NOT_ACTIVE`** > **`POLICY_MISMATCH` ≠ `INTENT_MISMATCH`** *** #### Rule 5 — Historical Documents Are Not Retroactively Rewritten Older documents retain their original terminology for citation and historical accuracy. GitBook provides current interpretation rather than silently altering historical artifacts. *** ## H. Cross-Layer Interpretation Examples #### Example 1 — Authority Revocation Current published Authority Object research: > `DENY(AUTHORITY_REVOKED)` Current MVP operational implementation: > `DENY(REVOKED)` These belong to different namespaces. They may describe closely related authority-revocation conditions without requiring identical string representation. *** #### Example 2 — Permit Expiration Current MVP: > `DENY(EXPIRED)` This refers specifically to expiration of the Execution Permit. It must not be mapped automatically to: > `DENY(AUTHORITY_EXPIRED)` because the final MVP separately implements `AUTHORITY_EXPIRED`. *** #### Example 3 — Intent Binding Current research mapping: > `DENY(INTENT_MISMATCH)` Current final MVP: > `DENY(INTENT_MISMATCH)` The strings currently align. That does not mean the entire research and MVP namespaces have become one namespace. It means that this particular failure currently has aligned terminology. *** #### Example 4 — Historical Authority Failure Protocol Core v1.1: > `DENY_AUTHORITY_COLLAPSE` Current research and MVP layers use more differentiated authority-state reasoning. The historical string remains valid for Protocol Core v1.1, but should not be substituted automatically into current MVP evidence. *** ## I. Public Proof Alignment The current GitBook interpretation of MVP operational failures should remain aligned with the active Public Proof release. For the final MVP implementation, the Public Proof operational reason-code inventory and GitBook mapping should use the same 12-code set: ``` OKNO_PERMITSIG_FAILSCOPE_FAILREPLAYREVOKEDEXPIREDPOLICY_MISMATCHINTENT_MISMATCHAUTHORITY_EXPIREDAUTHORITY_NOT_ACTIVEINTERNAL_ERROR ``` This does **not** mean GitBook and Public Proof serve the same purpose. The relationship is: > **GitBook → defines and contextualizes the mapping** while: > **Public Proof → exposes bounded technical evidence for the current implementation mapping** Therefore: > **Documentation semantics and executable evidence should align without collapsing their roles.** *** ## J. Failure-Code Interpretation Rule The canonical rule for citing a failure is: > **Always identify the Decision State, Reason Code, Specification Layer, and Version.** For example: > **DENY**\ > `SCOPE_FAIL`\ > Authority Objects v0.2 is more precise than: > scope failure. Likewise: > **DENY**\ > `INTENT_MISMATCH`\ > Admission Kernel MVP v0.1 — Final Implementation is more precise than: > intent failure. And: > **DENY**\ > `AUTHORITY_EXPIRED`\ > Admission Kernel MVP v0.1 — Final Implementation must not be silently rewritten as: > `DENY(EXPIRED)` because the final implementation distinguishes those two conditions. *** ## Canonical Decision & Failure Rule The governing interpretation is: > **Decision state identifies what happens.** > **Reason code identifies why it happens.** > **Specification layer identifies where that meaning is defined.** > **Version identifies which definition applies.** Therefore: > **Never interpret a reason code independently of its specification layer and version.** and: > **Never merge distinct current operational reason codes merely because they produce the same Layer 0 decision.** and: > **Never use historical terminology to silently override current executable semantics.** This mapping preserves technical precision while allowing LPP research, protocol specifications, executable implementations, and historical documents to evolve without rewriting one another.