Operating Model Protocol (OMP) Core -- Version 01: Invariant 3 -- Verifiable Delegation 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/.¶

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

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

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

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

{
  "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"
    }
  }
}

{
  "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"
  }
}

{
  "routing_state": "AUTONOMOUS",
  "authority_binding": {
    "authority_binding_result": "EXEMPT",
    "execution_permission": "ALLOWED",
    "exemption_basis":
      "AUTONOMOUS_ROUTING_STATE|WATCHTOWER_PROFILE_EXEMPT"
  }
}

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¶
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¶

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.¶
• 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.¶

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

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¶
• 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¶
• 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