> 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.1-glossary.md). # 13.1 Glossary This glossary contains the core terms frozen for GitBook v2.0. It is intentionally narrower than earlier LPP glossaries. Subsystem-specific and research-local terminology is defined in the chapter or publication where it is used. *** #### Admissibility **Admissibility** is the determination of whether a specific AI-triggered action is qualified to become an execution candidate under the applicable Layer 0 governance state. Admissibility is upstream of runtime permission. It is not equivalent to: * identity, * access, * capability, * runtime authorization, * model confidence, * operational readiness, * or successful execution. Canonical relationship: ``` Admissibility before Permission ``` A Layer 1 policy pass does not establish Layer 0 admissibility. *** #### Authority **Authority** is the legitimate, externally grounded basis under which a principal may authorize a defined class of consequential action. In the current LPP model, authority is: * scoped, * lifecycle-bound, * time-sensitive, * revocable, * attributable, * and machine-verifiable where required. Authority is not inferred from technical ability. ``` Capability ≠ Authority ``` Likewise: ``` Access ≠ Authority ``` ``` Permission ≠ Authority ``` *** #### Authority Object An **Authority Object (AO)** is the structured, machine-verifiable legitimacy carrier representing upstream authority for AI-triggered execution. It answers: > **What legitimate authority existed before execution?** An Authority Object may bind governance information relating to: * issuer, * subject, * scope, * validity, * signatures, * lifecycle state, * revocation, * delegation, * consequence requirements, * and applicable policy state. The Authority Object exists upstream of the Execution Permit. ``` Authority Object = Legitimacy Carrier ``` ``` Execution Permit = Constrained Execution Credential ``` The two must not be conflated. *** #### Human-Authorized Intent **Human-Authorized Intent** is the human or institutionally authorized meaning from which execution legitimacy derives. It answers: > **What did the legitimate authority actually authorize?** Authority and intent are distinct. ``` Authority = Who may legitimately authorize? ``` ``` Human-Authorized Intent = What was authorized? ``` A valid Authority Object does not guarantee that an evolving agent trajectory continues to preserve the authorized meaning. *** #### Permit / Execution Permit An **Execution Permit** is the constrained operational credential produced only after successful Layer 0 admission. It answers: > **What constrained execution is allowed now?** A Permit may be: * scope-bound, * intent-bound, * time-bound, * policy-bound, * authority-bound, * signed, * and replay-controlled. The canonical rule is: ``` ADMIT ↓ Execution Permit ``` A Permit does not create legitimacy. It carries an already-established admissibility decision into the execution boundary. *** #### Admission Artifact An **Admission Artifact (AA)** is a structured, reconstructable governance-evidence object associated with an admission decision and, where applicable, resulting execution. It answers: > **Why was this action admitted, denied, or otherwise classified under the governing state at that time?** An Admission Artifact is not merely a conventional operational log. The current technical model treats it as a: > **signed, structured, tamper-evident proof object** capable of binding references to: * authority state, * scope, * execution intent, * policy state, * Permit, * nonce, * timestamp, * decision, * and execution result. ``` Audit Log = What happened? ``` ``` Admission Artifact = Why was the governance decision made? ``` *** #### Material Mutation **Material Mutation** is a governance-relevant change to an action, task, or agent trajectory that changes the legitimate basis on which previous admission was established. Material mutation may involve changes to factors such as: * objective, * target, * scope, * principal, * delegation path, * action type, * consequence, * or execution environment. Not every textual or implementation-level change is material. The canonical rule is: > **Material Mutation ⇒ Re-Admission** *** #### SVNN **SVNN** stands for: > **Semantic Verification Node Network** In the current canonical architecture, SVNN is a distributed verification substrate capable of providing governance and semantic-intent evidence where required. SVNN may support: * intent-consistency evidence, * trajectory-consistency evidence, * independent validator agreement, * governance-evidence validation, * and risk-indexed quorum evidence. Its authority boundary is explicit: ``` SVNN provides evidence. ``` ``` LPP Admission Kernel decides admissibility. ``` SVNN does not: * create authority, * mint Authority Objects, * issue Execution Permits, * independently return `ADMIT`, * or override mandatory deterministic predicates. *** #### SCSP **SCSP** stands for: > **Self-Created Semantic Protocol** The current public technical definition is: > **A non-human-auditable semantic structure generated or used by AI systems to coordinate behavior outside accountable language channels.** The concern is not the mere existence of: * machine encodings, * embeddings, * internal tokens, * or efficient agent messages. SCSP becomes governance-relevant when opaque machine-created semantics are used to: * coordinate consequential behavior, * obscure authority, * bypass responsibility, * prevent semantic reconstruction, * or establish an alternative self-originated governance path. The canonical Anti-SCSP objective is therefore: ``` Human-Auditable Semantics + Authority Traceability + No Self-Originated Governance Bypass ``` *** #### Re-Admission **Re-Admission** is a new Layer 0 evaluation performed after the governance assumptions supporting an earlier admission are no longer sufficient for the current action. A re-admission may be required after conditions such as: * Material Mutation, * changed scope, * changed principal, * changed execution intent, * changed consequence, * changed authority state, * or another admission-relevant transition. Re-admission does not imply automatic denial. It means: ``` Previous admission cannot simply be inherited. ``` The changed action must obtain a fresh admissibility decision. ***