> 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.2-governance-object-schemas.md). # 14.2 Governance Object Schemas The schemas below represent the current **P1 public technical surface**. They do not expose: * private keys, * production thresholds, * proprietary policy logic, * confidential deployment topology, * private quorum weights, * customer configuration, * or other P2 / P3 material. A second distinction is necessary: ``` Canonical Object Semantics ≠ Current MVP Object Representation ``` The Authority Object has a published canonical grammar. Execution Permit and Admission Artifact have concrete current MVP schemas. Human-Authorized Intent and Canonical Intent Commitment have canonical public semantics, but the current public corpus does **not yet freeze complete standalone JSON field sets** for those two objects. This Appendix therefore does not fabricate them. *** ### A. Authority Object Canonical grammar: ``` AuthorityObject { authority_id subject_identity issuer_identity jurisdiction_scope action_scope irreversibility_class required_signatures signature_status validity_window temporal_decay_model revocation_state revocation_log cross_system_transfer policy_binding consensus_signature status } ``` Canonical state domain: ``` status ∈ { UNMINTED, MINTED, INVALID, EXPIRED, REVOKED } ``` Canonical consequence class: ``` irreversibility_class ∈ { T0, T1, T2, T3, T4 } ``` Illustrative P1 representation: ``` { "authority_id": "ao:example:001", "subject_identity": "principal:123", "issuer_identity": "issuer:456", "jurisdiction_scope": [ "domain:example", "region:example" ], "action_scope": { "allowed_actions": [ "example_action" ] }, "irreversibility_class": "T3", "required_signatures": [ "principal_signature", "issuer_signature" ], "signature_status": { "principal_signature": "ACTIVE", "issuer_signature": "ACTIVE" }, "validity_window": { "start": "timestamp", "end": "timestamp" }, "temporal_decay_model": { "type": "bounded_validity" }, "revocation_state": "NOT_REVOKED", "revocation_log": [], "cross_system_transfer": { "transferable": false, "recognized_by": [] }, "policy_binding": { "policy_hash": "sha256(...)" }, "consensus_signature": "verification-evidence-reference", "status": "MINTED" } ``` Important v2.0 interpretation: `consensus_signature` is a verification-evidence field. It must not be interpreted as granting SVNN independent authority to create legitimacy. *** ### B. Human-Authorized Intent Canonical purpose: > **Represent the human or institutionally authorized meaning from which execution legitimacy derives.** Current public binding references include: ``` human_intent_ref authorized_intent_hash authority_object_ref ``` Canonical binding: ``` B_H = ⟨AO, H⟩ ``` Public interface relationship: ``` HumanAuthorizedIntent ↓ human_intent_ref ↓ authorized_intent_hash ↓ Authority–Intent Binding ↑ authority_object_ref ``` #### Public Schema Status A complete standalone P1 JSON schema for Human-Authorized Intent is **not yet frozen in the current canonical public sources**. Accordingly, GitBook v2.0 defines the following minimum public requirements rather than inventing additional fields: ``` Human-Authorized Intent must: 1. have a stable reference; 2. support a stable authorized-intent commitment; 3. remain attributable to legitimate human / institutional authority; 4. be bindable to a specific Authority Object; 5. remain distinguishable from current agent intent; 6. support later semantic verification. ``` This is an intentional specification boundary. *** ### C. Authority–Intent Binding Current public interface: ``` AuthorityIntentBinding { authority_object_ref human_intent_ref authorized_intent_hash } ``` Conceptually: ``` { "authority_object_ref": "ao:example:001", "human_intent_ref": "intent:human:001", "authorized_intent_hash": "sha256(...)" } ``` The binding establishes: ``` This Authority Object authorizes this Human-Authorized Intent. ``` It does not establish that every later transformation remains semantically valid. That is evaluated downstream. *** ### D. Canonical Intent Commitment Canonical purpose: > **Provide the stable semantic reference against which an evolving task, delegation, or action trajectory is verified.** Canonical position: ``` Human-Authorized Intent ↓ Authority–Intent Binding ↓ Task / Agent Transformation ↓ Canonical Intent Commitment ↓ Semantic Verification ``` #### Public Schema Status A final standalone JSON field set for Canonical Intent Commitment is **not yet publicly frozen**. The current P1 interface requires only that the commitment: ``` 1. remain traceably derived from the authorized intent; 2. provide a stable comparison reference; 3. remain distinguishable from model-generated replacement intent; 4. support Semantic Verification; 5. support Material Mutation detection; 6. support mandatory Re-Admission. ``` No additional normative field names are introduced here. *** ### E. Execution Intent Although not separately listed in the frozen 14.2 sidebar description, Execution Intent is required to understand Permit binding. Current MVP minimum representation: ``` { "intent_id": "uuid", "principal_id": "principal:alice", "function": "transfer_funds", "target": "bank:acct:XYZ", "params_c14n": "canonical-string-or-json", "intent_hash": "sha256(...)", "timestamp": 1730000000 } ``` The broader Authority Object research represents execution intent conceptually as: ``` E = ⟨ subject, action, target, parameters, scope, class, intent_hash, time ⟩ ``` The MVP structure is therefore an implementation subset rather than the complete cross-domain protocol abstraction. *** ### F. Execution Permit Current MVP P1 structure: ``` { "permit_id": "permit:uuid", "principal_id": "principal:alice", "authority_id": "auth:alice:001", "scope_hash": "sha256(...)", "policy_hash": "sha256(policy_version)", "intent_hash": "sha256(execution_intent)", "nonce": "random", "issued_at": 1730000000, "expires_at": 1730000060, "cp_signature": "signature(...)" } ``` Required semantic bindings: ``` Permit.authority_id = AO.authority_id ``` ``` Permit.intent_hash = Hash(admitted execution intent) ``` ``` Permit.scope_hash = Hash(admitted scope) ``` ``` Permit.policy_hash = Hash(applicable policy state) ``` and: ``` Permit expiry ≤ upstream authority validity boundary ``` The Permit is: * time-bound, * scope-bound, * intent-bound, * signed, * replay-controlled, * and downstream of `ADMIT`. It is not the legitimacy source. *** ### G. Admission Artifact Current MVP P1 structure: ``` { "artifact_id": "aa:uuid", "decision": "ADMIT|DENY", "reason_code": "OK|NO_PERMIT|SIG_FAIL|SCOPE_FAIL|REPLAY|REVOKED|EXPIRED|POLICY_MISMATCH", "principal_id": "principal:alice", "authority_id": "auth:alice:001", "authority_state_hash": "sha256(...)", "scope_hash": "sha256(...)", "intent_hash": "sha256(...)", "permit_id": "permit:uuid-or-null", "nonce": "nonce-or-null", "policy_hash": "sha256(...)", "timestamp": 1730000001, "result_hash": "sha256(...)", "cp_signature": "signature(...)", "prev_artifact_hash": "sha256(previous_artifact)" } ``` The dedicated Artifact Verification Specification additionally identifies minimum evidence concepts 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 Optional EP_Attestation_Signature ``` These sources reflect different implementation / specification stages. GitBook v2.0 therefore treats the canonical requirement as: > **The Artifact must preserve enough signed, structured evidence to reconstruct the authority-bound admission decision.** A future Protocol Core or schema package may normalize the exact serialization.