



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

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





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

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,
              <https://datatracker.ietf.org/doc/html/draft-veridom-omp-
              00>.  Work in Progress

   [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

   *  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]
