Network Working Group T. Adebayo Internet-Draft O. Apalowo Intended status: Experimental Veridom Ltd Expires: 1 November 2026 30 April 2026 Operating Model Protocol (OMP) Core -- Version 01: Invariant 3 -- Verifiable Delegation Binding draft-veridom-omp-01 Abstract This -01 version of the Operating Model Protocol (OMP) Core specification introduces Invariant 3: Verifiable Delegation Binding. OMP version -00 establishes two invariants: (1) deterministic routing and (2) immutable trail. These invariants are necessary but not sufficient for adversarial evidentiary defensibility. A tamper- evident record of an unauthorised decision is still an unauthorised decision. This amendment adds Invariant 3, which closes the gap between record existence and authority validity by requiring that every ASSISTED or ESCALATED routing state bind the Named Accountable Officer field to a verifiable DelegationInstrument object at the moment of decision. When no valid binding can be established, the system sets authority_binding_result to AUTHORITY_UNBOUND -- a sealed, positive evidentiary declaration of the absence, not a silent failure. The routing_state is preserved; execution_permission is set to BLOCKED. Three axes are orthogonal: routing_state, authority_binding_result, and execution_permission. This amendment is additive and non-breaking. All twelve existing OMP profile drafts inherit Invariant 3 from the core specification. AUTONOMOUS routing states are exempt unless a profile-specific Watchtower gate requires binding. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Adebayo & Apalowo Expires 1 November 2026 [Page 1] Internet-Draft OMP Core v01 April 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 1 November 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. The Authority-Chain Gap in OMP -00 . . . . . . . . . . . . . 4 3. The Three OMP Core Invariants . . . . . . . . . . . . . . . . 4 3.1. Invariant 1 -- Deterministic Routing (Unchanged from -00) . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Invariant 2 -- Immutable Trail (Unchanged from -00) . . . 4 3.3. Invariant 3 -- Verifiable Delegation Binding (New in -01) . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. The authority_binding Object . . . . . . . . . . . . . . . . 5 4.1. BOUND Record Structure . . . . . . . . . . . . . . . . . 5 4.2. AUTHORITY_UNBOUND Record Structure . . . . . . . . . . . 6 4.3. EXEMPT Record Structure . . . . . . . . . . . . . . . . . 7 4.4. Field Definitions . . . . . . . . . . . . . . . . . . . . 7 4.4.1. instrument_selection_mode . . . . . . . . . . . . . . 7 4.4.2. authority_root_type and Recursion Termination . . . . 8 4.4.3. scope_constraints . . . . . . . . . . . . . . . . . . 9 4.4.4. instrument_hash and Public Registry . . . . . . . . . 9 5. Conformance Test Cases -- Invariant 3 . . . . . . . . . . . . 9 6. Profile Inheritance and First-Deployment Targets . . . . . . 11 7. Migration from -00 to -01 . . . . . . . . . . . . . . . . . . 11 8. Adversarial Evidentiary Defensibility . . . . . . . . . . . . 12 8.1. BOUND Records . . . . . . . . . . . . . . . . . . . . . . 12 8.2. AUTHORITY_UNBOUND Records . . . . . . . . . . . . . . . . 12 8.3. Post-Hoc Instrument Attachment . . . . . . . . . . . . . 12 Adebayo & Apalowo Expires 1 November 2026 [Page 2] Internet-Draft OMP Core v01 April 2026 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. authority_binding_result Enumeration . . . . . . . . 14 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction The Operating Model Protocol (OMP), specified in [OMP-00], defines a deterministic routing and tamper-evident evidence architecture for consequential AI decisions. It establishes two invariants: deterministic routing (Invariant 1) and immutable trail (Invariant 2). Independent review of the OMP Proof-Point architecture identified a structural gap: a tamper-evident record that names an accountable officer proves the officer was named in the record. It does not prove the named officer held valid delegated authority to make that specific decision at that specific time. The challenge may be stated as: the organisation that made the decision must produce the underlying record and show it supported that specific decision at that moment. The protocol layer fixes the link between a specific decision and the evidence the institution must later produce. It does not substitute for institutional evidence. This document adds Invariant 3 -- Verifiable Delegation Binding -- which addresses this gap by requiring that the Named Accountable Officer field be bound, at decision time, to a verifiable DelegationInstrument object. The amendment makes authority absence visible: when valid binding cannot be established, this is recorded explicitly rather than silently. The amendment is additive. Existing -00 records remain valid under -00 schema. AUTONOMOUS states are unchanged. The amendment adds the authority_binding object to ASSISTED and ESCALATED records. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Adebayo & Apalowo Expires 1 November 2026 [Page 3] Internet-Draft OMP Core v01 April 2026 2. The Authority-Chain Gap in OMP -00 OMP -00 seals two links of the four-link authority chain: 1. Decision record -- what was decided, under which routing state, at what time 2. Named Accountable Officer -- who was asserted as responsible 3. Delegation instrument -- the role, mandate, scope, and basis for the officer's authority 4. Authority validity at decision time -- whether the instrument was operative Links 3 and 4 were outside the scope of -00. In adversarial proceedings, a party challenging an AI-assisted decision may accept links 1 and 2 while contesting link 3 or 4: the officer was named, but did not hold valid delegated authority for that decision class, or the instrument was expired or revoked at the time of the decision. Invariant 3 seals links 3 and 4. A correctly bound record makes the authority claim independently testable by linking the decision, at decision time, to a specific DelegationInstrument with recorded scope, issuer, effective date, revocation status, and hash or reference to the underlying authority document. The protocol cannot finally adjudicate legal authority; it makes the authority claim auditable without institutional cooperation. 3. The Three OMP Core Invariants 3.1. Invariant 1 -- Deterministic Routing (Unchanged from -00) Given the same inputs and policy configuration, the same routing state always results. Routing states are: AUTONOMOUS, ASSISTED, and ESCALATED. Routing is defined in configuration, not inferred by the model. Policy violation becomes structurally impossible without generating an evidence record. 3.2. Invariant 2 -- Immutable Trail (Unchanged from -00) Every routing state produces a cryptographically sealed record at the exact moment of decision. Sealing uses SHA-256 hash over canonical JSON per [RFC8785], combined with an RFC 3161 trusted timestamp [RFC3161] and an optional institutional signature. Any post-decision modification to any field is detectable by any third party without requiring institutional access. Adebayo & Apalowo Expires 1 November 2026 [Page 4] Internet-Draft OMP Core v01 April 2026 3.3. Invariant 3 -- Verifiable Delegation Binding (New in -01) Every ASSISTED or ESCALATED routing state MUST evaluate Invariant 3. The evaluation determines whether the Named Accountable Officer field can be bound to a valid DelegationInstrument at the moment of the routing state. The result of this evaluation is recorded in the authority_binding object (Section 4) as one of three values: BOUND A valid DelegationInstrument was identified, all required fields are present and valid, the instrument was operative at decision time, and the officer's scope covers the decision class. AUTHORITY_UNBOUND A valid DelegationInstrument could not be bound. The failure is recorded in failure_reasons. The routing_state is preserved as ASSISTED or ESCALATED; execution_permission is set to BLOCKED. The absence is sealed under Invariant 2. EXEMPT The routing_state is AUTONOMOUS, or a profile-specific Watchtower has explicitly exempted this interaction from binding. Execution_permission is ALLOWED. The three axes are orthogonal: * routing_state: what decision path this was (AUTONOMOUS / ASSISTED / ESCALATED) * authority_binding_result: whether delegation binding succeeded (BOUND / AUTHORITY_UNBOUND / EXEMPT) * execution_permission: whether the decision may proceed (ALLOWED / BLOCKED) Implementations MUST NOT conflate these axes. AUTHORITY_UNBOUND is not a routing state. It is an authority_binding_result attached to an existing routing state. 4. The authority_binding Object The authority_binding object is added to the OMP Audit Trace for all routing states. Its structure varies by authority_binding_result. 4.1. BOUND Record Structure Adebayo & Apalowo Expires 1 November 2026 [Page 5] Internet-Draft OMP Core v01 April 2026 { "routing_state": "ESCALATED", "named_accountable_officer": { "officer_id": "string", "role": "string" }, "authority_binding": { "authority_binding_result": "BOUND", "execution_permission": "ALLOWED", "delegation_instrument": { "instrument_id": "string", "officer_id": "string", "role_identifier": "string", "mandate_scope": "string", "scope_constraints": { "decision_types": ["string"], "jurisdictions": ["ISO 3166-1 alpha-2"], "product_scope": ["string"], "risk_threshold": "string", "monetary_limit": { "currency": "ISO 4217", "max_amount": "number" } }, "effective_date": "ISO 8601 date", "expiry_date": "ISO 8601 date or null", "revocation_status_at_decision": "ACTIVE|SUSPENDED|REVOKED|UNKNOWN", "issuing_authority_id": "string", "authority_root_type": "statutory|corporate_delegation|professional_registration", "instrument_hash": "sha256:hexstring", "instrument_reference": "URI", "instrument_selection_mode": "pre_registered|policy_resolved| manual_selected_at_decision|post_hoc_attached", "instrument_selected_at": "ISO 8601 datetime", "authority_registry_snapshot_hash": "sha256:hexstring", "registry_inclusion_proof": "string or null", "binding_timestamp": "RFC 3161 token reference" } } } 4.2. AUTHORITY_UNBOUND Record Structure Adebayo & Apalowo Expires 1 November 2026 [Page 6] Internet-Draft OMP Core v01 April 2026 { "routing_state": "ESCALATED", "authority_binding": { "authority_binding_result": "AUTHORITY_UNBOUND", "execution_permission": "BLOCKED", "failure_reasons": [ "NO_VALID_DELEGATION_INSTRUMENT|OFFICER_ID_MISMATCH| EFFECTIVE_DATE_FUTURE|INSTRUMENT_EXPIRED| INSTRUMENT_REVOKED|INSTRUMENT_SUSPENDED| REVOCATION_STATUS_UNKNOWN|MANDATE_SCOPE_MISMATCH| JURISDICTION_OUT_OF_SCOPE|MONETARY_THRESHOLD_EXCEEDED| INSTRUMENT_HASH_MISMATCH| BINDING_TIMESTAMP_OUTSIDE_WINDOW| REGISTRY_PROOF_MISSING|POST_HOC_ATTACHMENT_DETECTED" ], "attempted_officer_id": "string or null", "binding_timestamp": "RFC 3161 token reference" } } 4.3. EXEMPT Record Structure { "routing_state": "AUTONOMOUS", "authority_binding": { "authority_binding_result": "EXEMPT", "execution_permission": "ALLOWED", "exemption_basis": "AUTONOMOUS_ROUTING_STATE|WATCHTOWER_PROFILE_EXEMPT" } } 4.4. Field Definitions 4.4.1. instrument_selection_mode This field records how the DelegationInstrument was identified relative to the moment of decision. This is the operative instrument proof: evidence that the instrument was active at decision time rather than selected after the fact. pre_registered The instrument was registered in an authority registry before this interaction class occurred. The authority_registry_snapshot_hash records the state of that registry at decision time. policy_resolved The instrument was resolved at decision time from a Adebayo & Apalowo Expires 1 November 2026 [Page 7] Internet-Draft OMP Core v01 April 2026 configured policy that maps officer identifiers to valid instruments. The resolution is deterministic and recorded. manual_selected_at_decision The instrument was manually selected by the system operator at the moment of the decision. The binding_timestamp records this moment. post_hoc_attached The instrument was attached after the decision record was created. This value MUST trigger a review flag. Implementations SHOULD NOT treat post_hoc_attached records as fully BOUND. Profiles MAY define whether post_hoc_attached instruments produce AUTHORITY_UNBOUND or a distinct AUTHORITY_RETROSPECTIVELY_ATTACHED result. 4.4.2. authority_root_type and Recursion Termination The authority chain terminates when it reaches an accepted authority root. Three root classes are defined. Each OMP profile specifies which root types are acceptable for its domain. The authority root's validity is established by law or professional regulation and does not require further OMP DelegationInstrument binding. statutory A government-defined regulatory body or court. Examples: FCA (UK), CBK (Kenya), FHFA (US), GMC (UK), Colorado AG (US), EU AI Office. Authority is defined by statute. The issuing_authority_id references the statutory body's official registration identifier. corporate_delegation A corporate delegation instrument: board resolution, company secretary record, SMCR Statement of Responsibility, or delegated authority matrix. The chain terminates at the corporate body (company registration) which is itself defined by law. The issuing_authority_id references the corporate registration number and the specific delegation instrument. professional_registration A professional licence or registration: GMC/NMC clinical registration, Law Society or Bar admission, Lloyd's underwriter approval, MAS-registered officer appointment. The chain terminates at the professional register maintained by a statutory body. The issuing_authority_id references the professional registration number. Adebayo & Apalowo Expires 1 November 2026 [Page 8] Internet-Draft OMP Core v01 April 2026 4.4.3. scope_constraints The scope_constraints object provides structured, machine-testable bounds on the instrument's mandate. Conformance verification MUST check that the decision falls within the scope_constraints. A decision outside the declared scope_constraints MUST produce MANDATE_SCOPE_MISMATCH in failure_reasons. Fields within scope_constraints are OPTIONAL individually but the scope_constraints object itself is REQUIRED when authority_binding_result is BOUND. An empty scope_constraints object indicates no structured constraints beyond mandate_scope (free text). 4.4.4. instrument_hash and Public Registry The instrument_hash (SHA-256 of the canonical form of the authority document) provides a mechanism for third-party verification that the referenced document has not been modified since it was hashed. Profiles MAY require that instrument hashes be published in an accessible authority registry (analogous to Certificate Transparency [RFC6962]). Publication in such a registry proves existence, timestamp, and non-modification of the delegation instrument at or before the time of registration. It does not prove the legal interpretation of the instrument. The authority_registry_snapshot_hash records the hash of the registry state at decision time, providing evidence that the instrument was registered before the decision was made. 5. Conformance Test Cases -- Invariant 3 The following minimum conformance cases MUST be included in the omp- profiles conformance suite for Invariant 3. All cases assume Invariant 1 and Invariant 2 conformance has already been verified. 1. AUTONOMOUS routing state -> EXEMPT, ALLOWED 2. ASSISTED + valid active pre_registered instrument, scope match -> BOUND, ALLOWED 3. ESCALATED + valid active pre_registered instrument, scope match -> BOUND, ALLOWED 4. ASSISTED or ESCALATED + no instrument present -> AUTHORITY_UNBOUND, BLOCKED, NO_VALID_DELEGATION_INSTRUMENT Adebayo & Apalowo Expires 1 November 2026 [Page 9] Internet-Draft OMP Core v01 April 2026 5. officer_id mismatch -> AUTHORITY_UNBOUND, BLOCKED, OFFICER_ID_MISMATCH 6. effective_date after decision timestamp -> AUTHORITY_UNBOUND, BLOCKED, EFFECTIVE_DATE_FUTURE 7. expiry_date before decision timestamp -> AUTHORITY_UNBOUND, BLOCKED, INSTRUMENT_EXPIRED 8. revocation_status REVOKED -> AUTHORITY_UNBOUND, BLOCKED, INSTRUMENT_REVOKED 9. revocation_status SUSPENDED -> AUTHORITY_UNBOUND, BLOCKED, INSTRUMENT_SUSPENDED 10. revocation_status UNKNOWN -> AUTHORITY_UNBOUND, BLOCKED, REVOCATION_STATUS_UNKNOWN 11. decision_type not in scope_constraints.decision_types -> AUTHORITY_UNBOUND, BLOCKED, MANDATE_SCOPE_MISMATCH 12. jurisdiction not in scope_constraints.jurisdictions -> AUTHORITY_UNBOUND, BLOCKED, JURISDICTION_OUT_OF_SCOPE 13. value exceeds scope_constraints.monetary_limit -> AUTHORITY_UNBOUND, BLOCKED, MONETARY_THRESHOLD_EXCEEDED 14. instrument_hash mismatch -> AUTHORITY_UNBOUND, BLOCKED, INSTRUMENT_HASH_MISMATCH 15. binding_timestamp outside window -> AUTHORITY_UNBOUND, BLOCKED, BINDING_TIMESTAMP_OUTSIDE_WINDOW 16. registry_inclusion_proof absent when required -> AUTHORITY_UNBOUND, BLOCKED, REGISTRY_PROOF_MISSING 17. post_hoc_attached -> review flag, not fully BOUND (profile- specific handling) 18. invalid enum value in any Invariant 3 field -> schema validation failure, record not emitted 19. canonical JSON hash of authority_binding unchanged across stable field ordering 20. identical inputs produce identical authority_binding_result and execution_permission Adebayo & Apalowo Expires 1 November 2026 [Page 10] Internet-Draft OMP Core v01 April 2026 6. Profile Inheritance and First-Deployment Targets All twelve OMP profile drafts inherit Invariant 3 from this core specification. No immediate profile draft amendment is required for the invariant to apply. Profile-specific implementation guidance is added to each profile in the subsequent revision cycle. The following four profiles are designated first-deployment targets because they operate in regulatory domains where delegation instruments are already formally required by existing regulation. DutyMark (draft-veridom-omp-fca-00) SMCR Statements of Responsibility are the natural DelegationInstrument. authority_root_type: corporate_delegation_root anchored in statutory (FCA firm reference). Effective date equals the date of FCA approval. Revocation equals FCA withdrawal of approval. WorkMark (draft-veridom-omp-employ-00) Employment ADS authority policy and HR delegated authority schedule. authority_root_type: corporate_delegation_root. Colorado AI Act and EEOC guidance both require a documented human accountable for consequential employment decisions. CareGuard (draft-veridom-omp-clinical-00) Clinical privileges document and GMC/NMC registration. authority_root_type: professional_registration anchored in statutory (GMC). Revocation_status_at_decision checked against the GMC register. HomeMark (draft-veridom-omp-fhfa-00) FHFA 2025-16 underwriter certification and authority scope. authority_root_type: corporate_delegation_root anchored in statutory (FHFA-regulated entity registration). The remaining seven profiles -- NDTCP, SACCO, InsureMark, EUAIA, CiteGuard, ColoradoMark, and SingaporeMark -- inherit Invariant 3 and will receive profile-specific DelegationInstrument guidance in their respective -01 revisions. 7. Migration from -00 to -01 This amendment is additive and non-breaking. * AUTONOMOUS records: -00 and -01 produce equivalent records. authority_binding_result is EXEMPT. No migration required. * ASSISTED and ESCALATED records: -00 records remain valid under -00 schema. Deployments migrating to -01 add the authority_binding object to their ASSISTED and ESCALATED emission paths. Adebayo & Apalowo Expires 1 November 2026 [Page 11] Internet-Draft OMP Core v01 April 2026 * Proof-Point artefacts: -00 artefacts remain independently verifiable under -00 schema. -01 artefacts are verifiable under -01 schema. SHA-256 and RFC 3161 sealing is unchanged. * Conformance suite: -01 adds the twenty cases in Section 5 to the omp-profiles conformance suite. Existing -00 cases are unmodified. 8. Adversarial Evidentiary Defensibility This section documents how Invariant 3 changes the evidentiary posture in contested proceedings. OMP records do not substitute for the deploying organisation's own evidence. The protocol makes the authority claim independently testable. Whether the authority was legally valid in the fullest sense remains for courts and regulators to determine. 8.1. BOUND Records A correctly bound -01 record proves that the decision was linked at decision time to a specific DelegationInstrument with recorded scope, issuer, effective date, and revocation status. It makes the authority claim independently testable. The deploying organisation remains responsible for producing the underlying instrument and demonstrating it applied to that specific decision at that time. 8.2. AUTHORITY_UNBOUND Records An AUTHORITY_UNBOUND record proves that the system evaluated whether a valid DelegationInstrument existed at the time of the decision and determined that it did not. The failure_reasons field records specifically which condition failed. Making authority absence visible is an architectural property, not a failure of the protocol. A sealed AUTHORITY_UNBOUND record materially weakens any later claim that authority was present but merely undisclosed, because the record shows that no valid binding was established at decision time. 8.3. Post-Hoc Instrument Attachment The instrument_selection_mode field addresses the question of whether a delegation instrument was operative at decision time or selected after the fact. A post_hoc_attached instrument cannot receive BOUND status. This distinction is critical in discovery contexts where a deploying organisation might attempt to reconstruct authority documentation after a decision is challenged. Adebayo & Apalowo Expires 1 November 2026 [Page 12] Internet-Draft OMP Core v01 April 2026 9. Security Considerations The authority_binding object is sealed by Invariant 2 (SHA-256 hash chain plus RFC 3161 timestamp). Any modification to any field in the authority_binding object after sealing will produce a hash mismatch detectable by any third party. The instrument_hash field provides a mechanism for verifying the referenced delegation instrument has not been modified since hashing. The hash does not prove the instrument's legal validity or scope of application. The instrument_selection_mode field provides evidence of when the instrument was bound relative to the decision. Implementations MUST record this field accurately. Misrepresenting post_hoc_attached as pre_registered is a breach of the protocol invariants and will be detectable through the binding_timestamp and authority_registry_snapshot_hash fields. The AUTHORITY_UNBOUND state seals the failure. This prevents a deploying organisation from later claiming the authority existed but was not recorded due to a system failure. The sealed absence is the evidence. 10. IANA Considerations This document has no IANA actions. The OMP profile registry is maintained at github.com/veridomltd/omp-open-core under Apache-2.0 licence. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . Adebayo & Apalowo Expires 1 November 2026 [Page 13] Internet-Draft OMP Core v01 April 2026 [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, . 11.2. Informative References [OMP-00] Adebayo, T. and O. Apalowo, "Operating Model Protocol (OMP) Core -- Version 00", Work in Progress, Internet- Draft, draft-veridom-omp-00, 2026, . Work in Progress [OMP-SPEC] Adebayo, T., "OMP Technical Specification", DOI 10.5281/zenodo.19140948, 2026, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, June 2013, . Appendix A. authority_binding_result Enumeration authority_binding_result ENUM: * BOUND -- Valid DelegationInstrument bound at decision time * AUTHORITY_UNBOUND -- Binding evaluation failed; see failure_reasons * EXEMPT -- AUTONOMOUS state or profile-specific Watchtower exemption execution_permission ENUM: * ALLOWED -- Decision may proceed * BLOCKED -- Decision blocked pending valid authority binding instrument_selection_mode ENUM: * pre_registered -- Instrument registered before interaction class * policy_resolved -- Resolved from configured policy at decision time * manual_selected_at_decision -- Selected by operator at decision time Adebayo & Apalowo Expires 1 November 2026 [Page 14] Internet-Draft OMP Core v01 April 2026 * post_hoc_attached -- Attached after decision record creation (review flag) authority_root_type ENUM: * statutory -- Government regulatory body or court * corporate_delegation -- Board resolution or delegated authority matrix * professional_registration -- Professional licence or registration revocation_status_at_decision ENUM: * ACTIVE -- Instrument confirmed active at decision time * SUSPENDED -- Instrument suspended; treated as AUTHORITY_UNBOUND * REVOKED -- Instrument revoked; treated as AUTHORITY_UNBOUND * UNKNOWN -- Status could not be determined; treated as AUTHORITY_UNBOUND failure_reasons ARRAY (one or more of): * NO_VALID_DELEGATION_INSTRUMENT * OFFICER_ID_MISMATCH * EFFECTIVE_DATE_FUTURE * INSTRUMENT_EXPIRED * INSTRUMENT_REVOKED * INSTRUMENT_SUSPENDED * REVOCATION_STATUS_UNKNOWN * MANDATE_SCOPE_MISMATCH * JURISDICTION_OUT_OF_SCOPE * MONETARY_THRESHOLD_EXCEEDED * INSTRUMENT_HASH_MISMATCH * BINDING_TIMESTAMP_OUTSIDE_WINDOW Adebayo & Apalowo Expires 1 November 2026 [Page 15] Internet-Draft OMP Core v01 April 2026 * REGISTRY_PROOF_MISSING * POST_HOC_ATTACHMENT_DETECTED Appendix B. Acknowledgements The authority-chain gap addressed by Invariant 3 was identified through independent review by an AI governance researcher whose published framework for binary structural testing of AI accountability converged independently on OMP's core architectural approach. Their critique -- that a tamper-proof record of an unauthorised decision is still an unauthorised decision, and that only the decision-maker can prove the underlying authority -- is incorporated into the design of Invariant 3 and the AUTHORITY_UNBOUND state. This draft was produced using the OMP Open Core reference implementation at github.com/veridomltd/omp-open-core (Apache-2.0). The OMP technical specification is published at [OMP-SPEC]. Authors' Addresses Tolulope Adebayo Veridom Ltd 128 City Road London EC1V 2NX United Kingdom Email: tolulope@veridom.io URI: https://veridom.io Oluropo Apalowo Veridom Ltd Awka Nigeria Email: ropo@veridom.io Adebayo & Apalowo Expires 1 November 2026 [Page 16]