> 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/4.-governance-objects/4.7-admission-artifact.md). # 4.7 Admission Artifact The **Admission Artifact (AA)** is the reconstructable evidence object associated with an admission decision and, where applicable, resulting execution. It answers: > **Why was this action admitted or denied at that time?** The Admission Artifact is not merely an event log. The existing technical specification defines it as: > a signed, structured, tamper-evident proof object. #### Core Purpose Traditional logging might answer: ``` What happened? ``` An Admission Artifact is intended to make it possible to reconstruct: ``` What authority existed? What scope applied? What action was requested? What policy state governed? What Permit was involved? Was authority active? Had authority been revoked? Was the Permit replayed? Why was the decision ADMIT or DENY? What resulting execution corresponds to the decision? ``` #### Current Technical Reference Fields The existing Admission Artifact Verification Specification defines minimum fields including: ``` Artifact_ID Principal_ID Authority_ID Authority_State_Hash Scope_Hash Execution_Intent_Hash Risk_Class Policy_Version_Hash Permit_ID Nonce Timestamp Execution_Result_Hash CP_Signature ``` with optional Execution Plane attestation support. The executable MVP uses a related minimal structure including: ``` artifact_id decision reason_code principal_id authority_id authority_state_hash scope_hash intent_hash permit_id nonce policy_hash timestamp result_hash cp_signature prev_artifact_hash ``` The distinction reflects specification evolution and implementation scope. GitBook v2.0 treats the Artifact as a governance evidence object rather than freezing every implementation to one legacy schema. The canonical public schema is defined in Appendix 14.2. #### Decision and Reason The current MVP emits Artifact evidence for both successful and failed tested admission paths. Conceptually: ``` decision = ADMIT reason = OK ``` or: ``` decision = DENY reason = SCOPE_FAIL ``` The broader v2.0 protocol contains: ``` ADMIT DENY DEFER COLLAPSE ``` but current implementation and validation claims remain bounded primarily to `ADMIT` and `DENY`. The protocol-level evidence model must therefore not be confused with current MVP coverage. #### Authority State Snapshot The Artifact preserves or references authority state as it existed at the relevant decision time. This matters because authority can later change. An auditor must be able to distinguish: ``` Authority is revoked now ``` from: ``` Authority was already revoked when the action was admitted. ``` #### Scope Evidence The Artifact preserves a scope commitment. A verifier can compare the action against the scope that governed the admission decision. #### Intent Evidence The Artifact includes an Execution Intent commitment. This links the admission decision to the action that was actually evaluated. #### Policy Evidence Policy-version binding allows reconstruction of which policy state applied at the relevant time. Without versioned policy evidence, a system could later claim that a different rule set governed the decision. #### Replay Evidence Permit and nonce information supports replay analysis. The verifier can determine whether the same execution credential was reused beyond its valid conditions. #### Execution Result Evidence Where execution occurred, an execution-result hash can bind the authorization record to the actual resulting effect. This creates the relationship: ``` Admission Decision ↓ Permit ↓ Execution ↓ Result Hash ``` #### Cryptographic Signature The Artifact is signed by the Control Plane in the reference model. This supports verification that the Artifact was not merely created retrospectively by an untrusted Execution Plane. #### Chain Integrity The MVP supports hash-linked artifact history through: ``` prev_artifact_hash ``` The dedicated Artifact Verification Specification also requires tamper-evident storage and supports stronger chain-of-custody models. #### Artifact Does Not Create Authority Evidence follows governance. It does not retroactively create it. ``` Admission Artifact ≠ Authority Object ``` A cryptographically perfect Artifact showing that an action lacked valid authority remains proof of invalid governance. It does not repair the authority failure.