



Network Working Group                                         T. Adebayo
Internet-Draft                                                O. Apalowo
Obsoletes: draft-veridom-omp-00 (if approved)                Veridom Ltd
Intended status: Experimental                                13 May 2026
Expires: 14 November 2026


     Operating Model Protocol (OMP) Core: Invariant 3 -- Verifiable
                           Delegation Binding
                       draft-veridom-omp-core-00

Abstract

   This document obsoletes draft-veridom-omp-00.  The Operating Model
   Protocol (OMP) defines a deterministic routing and tamper-evident
   evidence architecture for consequential AI decisions.  This document
   specifies OMP Core, which adds Invariant 3: Verifiable Delegation
   Binding.  Every ASSISTED or ESCALATED routing state must bind the
   Named Accountable Officer to a verifiable DelegationInstrument at the
   time of decision.  When valid binding cannot be established, the
   system records AUTHORITY_UNBOUND -- a sealed, positive evidentiary
   state.  This update is additive and backward-compatible with OMP Core
   version 00.

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/.

   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 14 November 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.






Adebayo & Apalowo       Expires 14 November 2026                [Page 1]

Internet-Draft                  OMP Core                        May 2026


   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  . . . . . . . . . . . . .   3
   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 this
           document) . . . . . . . . . . . . . . . . . . . . . . . .   4
   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 draft-veridom-omp-00 . . . . . . . . . . . . .  11
   8.  Adversarial Evidentiary Defensibility . . . . . . . . . . . .  12
     8.1.  BOUND Records . . . . . . . . . . . . . . . . . . . . . .  12
     8.2.  AUTHORITY_UNBOUND Records . . . . . . . . . . . . . . . .  12
     8.3.  Post-Hoc Instrument Attachment  . . . . . . . . . . . . .  13
   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







Adebayo & Apalowo       Expires 14 November 2026                [Page 2]

Internet-Draft                  OMP Core                        May 2026


1.  Introduction

   This document is OMP Core.  The Operating Model Protocol (OMP)
   defines a deterministic routing and tamper-evident evidence
   architecture for consequential AI decisions.  Version 00 established
   two invariants: deterministic routing (Invariant 1) and immutable
   trail (Invariant 2).  This document obsoletes version 00 and adds
   Invariant 3: Verifiable Delegation Binding.

   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.

2.  The Authority-Chain Gap in OMP -00

   OMP Core version 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




Adebayo & Apalowo       Expires 14 November 2026                [Page 3]

Internet-Draft                  OMP Core                        May 2026


   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.

3.3.  Invariant 3 -- Verifiable Delegation Binding (New in this
      document)

   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.





Adebayo & Apalowo       Expires 14 November 2026                [Page 4]

Internet-Draft                  OMP Core                        May 2026


   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 14 November 2026                [Page 5]

Internet-Draft                  OMP Core                        May 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 14 November 2026                [Page 6]

Internet-Draft                  OMP Core                        May 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 14 November 2026                [Page 7]

Internet-Draft                  OMP Core                        May 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 14 November 2026                [Page 8]

Internet-Draft                  OMP Core                        May 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 14 November 2026                [Page 9]

Internet-Draft                  OMP Core                        May 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 14 November 2026               [Page 10]

Internet-Draft                  OMP Core                        May 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 next revisions.

7.  Migration from draft-veridom-omp-00

   This amendment is additive and non-breaking.

   *  AUTONOMOUS records: -00 and core-00 produce equivalent records.
      authority_binding_result is EXEMPT.  No migration required.







Adebayo & Apalowo       Expires 14 November 2026               [Page 11]

Internet-Draft                  OMP Core                        May 2026


   *  ASSISTED and ESCALATED records: -00 records remain valid under -00
      schema.  Deployments migrating to draft-veridom-omp-core-00 add
      the authority_binding object to their ASSISTED and ESCALATED
      emission paths.

   *  Proof-Point artefacts: -00 artefacts remain independently
      verifiable under -00 schema. draft-veridom-omp-core-00 artefacts
      are verifiable under the core-00 schema.  SHA-256 and RFC 3161
      sealing is unchanged.

   *  Conformance suite: This document 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 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.









Adebayo & Apalowo       Expires 14 November 2026               [Page 12]

Internet-Draft                  OMP Core                        May 2026


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.

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,
              <https://www.rfc-editor.org/rfc/rfc2119>.





Adebayo & Apalowo       Expires 14 November 2026               [Page 13]

Internet-Draft                  OMP Core                        May 2026


   [RFC3161]  Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
              "Internet X.509 Public Key Infrastructure Time-Stamp
              Protocol (TSP)", RFC 3161, August 2001,
              <https://www.rfc-editor.org/rfc/rfc3161>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, May 2017,
              <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
              Canonicalization Scheme (JCS)", RFC 8785, June 2020,
              <https://www.rfc-editor.org/rfc/rfc8785>.

11.2.  Informative References

   [OMP-SPEC] Adebayo, T., "OMP Technical Specification",
              DOI 10.5281/zenodo.19140948, 2026,
              <https://doi.org/10.5281/zenodo.19140948>.

   [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
              Transparency", RFC 6962, June 2013,
              <https://www.rfc-editor.org/rfc/rfc6962>.

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




Adebayo & Apalowo       Expires 14 November 2026               [Page 14]

Internet-Draft                  OMP Core                        May 2026


   *  manual_selected_at_decision -- Selected by operator at decision
      time

   *  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




Adebayo & Apalowo       Expires 14 November 2026               [Page 15]

Internet-Draft                  OMP Core                        May 2026


   *  INSTRUMENT_HASH_MISMATCH

   *  BINDING_TIMESTAMP_OUTSIDE_WINDOW

   *  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 14 November 2026               [Page 16]
