Veridom Ltd

128 City Road London EC1V 2NX United Kingdom tolulope@veridom.io https://veridom.io

Veridom Ltd

Awka Nigeria ropo@veridom.io

Independent Submission Network Working Group 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.

The Operating Model Protocol (OMP), specified in , 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.

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 when, and only when, they appear in all capitals, as shown here.

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.

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.

Every routing state produces a cryptographically sealed record at the exact moment of decision. Sealing uses SHA-256 hash over canonical JSON per , combined with an RFC 3161 trusted timestamp and an optional institutional signature. Any post-decision modification to any field is detectable by any third party without requiring institutional access.

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.

The authority_binding object is added to the OMP Audit Trace for all routing states. Its structure varies by authority_binding_result.

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.

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.

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

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

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

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.

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.

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.

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.

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.

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.

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.

This document has no IANA actions. The OMP profile registry is maintained at github.com/veridomltd/omp-open-core under Apache-2.0 licence.

Work in Progress

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

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 .