Internet-Draft OMP Core v01 April 2026
Adebayo & Apalowo Expires 1 November 2026 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-veridom-omp-01
Published:
Intended Status:
Experimental
Expires:
Authors:
T. Adebayo
Veridom Ltd
O. Apalowo
Veridom Ltd

Operating Model Protocol (OMP) Core -- Version 01: Invariant 3 -- Verifiable Delegation Binding

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

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.

▲

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.

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

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 

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

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

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

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.

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, , <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, , <https://www.rfc-editor.org/rfc/rfc3161>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8785]
Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, , <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, , <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, , <https://doi.org/10.5281/zenodo.19140948>.
[RFC6962]
Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, , <https://www.rfc-editor.org/rfc/rfc6962>.

Appendix A. authority_binding_result Enumeration

authority_binding_result ENUM:

execution_permission ENUM:

instrument_selection_mode ENUM:

authority_root_type ENUM:

revocation_status_at_decision ENUM:

failure_reasons ARRAY (one or more of):

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
URI: https://veridom.io
Oluropo Apalowo
Veridom Ltd
Awka
Nigeria