Operating Model Protocol (OMP): A Deterministic Routing and Evidence Architecture for AI Decision Accountability in Regulated Industries

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

Table of Contents

1. Introduction

Regulated institutions globally share a structural failure: the gap between what they claim their operations do and what they can prove happened. This gap manifests in three distinct layers:¶

• Policy-to-Practice Gap: The institution has the required policies. Its agents, systems, and processes do not consistently follow them. The gap is invisible until an examiner asks to see evidence.¶
• Practice-to-Evidence Gap: Practices are compliant, but the contemporaneous evidence trail is absent or incomplete. Decisions are made but not recorded at the required granularity.¶
• Evidence-to-Examination Gap: Evidence exists but is not producible in the form a regulator requires -- scattered across systems, formatted for operations rather than audit, and not independently verifiable.¶

Every existing compliance tool accepts at least one of these layers as permanent. Monitoring tools accept that violations will occur and report them after the fact. GRC platforms accept that evidence will be incomplete and provide storage for what exists. Compliance dashboards accept the examination gap and help institutions produce narratives instead of proofs.¶

OMP refuses these concessions. The protocol closes all three layers structurally: it makes Layer 1 deviations impossible without generating a record, closes Layer 2 by producing evidence at the moment of the decision, and closes Layer 3 by producing a cryptographically sealed artifact that requires no manual assembly and carries no institutional fingerprints on the integrity claim.¶

This document specifies the OMP core protocol. A parallel publication of this specification is available at [ZENODO-OMP]. Domain-specific profiles that define vertical configuration parameters are specified in companion documents. Notably, the protocol was independently instantiated in a legal services context (citation verification under ABA Rule 5.3) without reference to the financial services instantiation, and the same two invariants -- deterministic classification and immutable audit trail -- held. This convergence is cited as evidence that the architecture describes a discovered structural pattern, not a designed framework.¶

2. Conventions and Definitions

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

The terms AUTONOMOUS, ASSISTED, and ESCALATED, when written in ALL CAPS, refer specifically to the three routing outcome states defined in Section 5 of this document.¶

3. Terminology

OMP:

Operating Model Protocol. The deterministic routing invariant defined in this document.¶

Interaction:

Any input event -- a message, query, transaction request, or signal -- that enters the OMP pipeline for routing.¶

Intent Class:

A domain-specific category of interaction defined during vertical configuration. Each Intent Class has its own routing threshold theta.¶

Confidence Score (C):

A normalised float in [0.0, 1.0] representing the system's computed certainty that a given routing decision is correct. Composite of C_m (model confidence), C_p (policy compliance score), and C_d (data completeness score).¶

Routing Threshold (theta):

The minimum Confidence Score required for a given Intent Class to qualify for the AUTONOMOUS path.¶

Watchtower:

A domain-specific enforcement rule that evaluates an interaction against a defined trigger condition and returns a severity-tagged routing override signal.¶

Audit Trace:

The complete, structured metadata record of a single OMP routing event, including routing decision, confidence scores, Watchtower evaluations, and cryptographic seals.¶

Proof-Point Artifact:

An aggregated, cryptographically sealed PDF generated from a defined time window of Audit Traces. Regulator-ready in under 30 seconds from any point in deployment history.¶

Named Accountable Officer:

A human actor whose identity is explicitly logged in the Audit Trace as the approving authority for an ASSISTED or ESCALATED resolution.¶

H_s (Source State Hash):

SHA-256 hash of an external data source response at the exact millisecond of query. Proves what the source said at decision time independently of current state.¶

H_content (Trace Content Hash):

SHA-256 hash of the complete Audit Trace record, excluding the sealing fields themselves.¶

H_c (Trace Chain Hash):

SHA-256 Merkle chain entry. Each trace's H_c incorporates the preceding trace's H_c. Modification of any trace breaks all subsequent chain hashes.¶

TST (TimeStampToken):

A cryptographically signed timestamp token issued by an accredited Timestamp Authority per [RFC3161]. Provides externally verifiable proof of existence at a specific point in time.¶

TSA (Timestamp Authority):

An accredited third-party Timestamp Authority operating per [RFC3161]. Independent of the institution and of Veridom.¶

VerticalConfig:

The domain-specific configuration layer that sits on top of the OMP invariant core. Defines Intent Classes, routing thresholds, Watchtower definitions, and SLA parameters for a specific regulated domain.¶

Threshold Change Record (TCR):

A sealed, immutable record of any modification to a production VerticalConfig. Required before any configuration change takes effect.¶

4. Protocol Architecture

The OMP pipeline processes every incoming interaction through five sequential stages. These stages are invariant across all vertical deployments. Only the configuration parameters -- Intent Classes, Routing Thresholds, and Watchtower definitions -- change per domain.¶

Stages S1 through S5 and the routing logic in Section 5 are invariant. They MUST NOT change between verticals, deployments, or software versions without a formal specification amendment following the Change Control process in Section 9. This invariance is the basis of the regulatory claim: the same inputs always produce the same routing decision.¶

5. Routing Decision Logic

The routing decision is a deterministic function R(C, W, theta, phi) where C is the Confidence Score, W is the set of Watchtower evaluation results, theta is the Intent Class routing threshold, and phi is the set of override conditions. The function MUST return exactly one value from {AUTONOMOUS, ASSISTED, ESCALATED}.¶

FUNCTION Route(interaction) -> Path:
  // STEP 1: Watchtower Hard Blocks (highest priority)
  FOR each Watchtower W_i in ActiveWatchtowers(interaction.vertical):
    IF W_i.evaluate(interaction) == TRUE:
      IF W_i.severity == HARD_BLOCK:
        RETURN ESCALATED  // immediate, no further evaluation
      IF W_i.severity == FORCE_ASSISTED:
        SET assisted_flag = TRUE

  // STEP 2: Classification confidence gate
  IF interaction.intent_confidence < 0.60:
    RETURN ESCALATED  // system cannot reliably classify

  // STEP 3: Assisted override from Watchtower
  IF assisted_flag == TRUE:
    RETURN ASSISTED

  // STEP 4: Confidence Score vs. Routing Threshold
  theta = GetThreshold(
    interaction.intent_class, interaction.vertical)
  IF interaction.confidence_score >= theta:
    RETURN AUTONOMOUS

  // STEP 5: Confidence below threshold but above minimum floor
  IF interaction.confidence_score >= 0.50:
    RETURN ASSISTED

  // STEP 6: Default
  RETURN ESCALATED

C = (0.50 * C_m) + (0.30 * C_p) + (0.20 * C_d)

// C_m: raw softmax probability of top-ranked response candidate
// C_p: policy compliance score (0.0-1.0)
// C_d: data completeness score
//   (fraction of required fields)

// Hard constraint:
IF C_p == 0.0:
  C = 0.0  // forces ESCALATED regardless of other signals

6. Watchtower Framework

Watchtowers are evaluated in Stage S3, before routing in Stage S4. They operate as pre-routing enforcement gates. A Watchtower MUST NOT force an AUTONOMOUS outcome. Watchtowers MUST only override routing in the direction of greater human involvement.¶

Watchtowers are additive. Multiple Watchtowers MAY activate on a single interaction. The highest-severity result governs routing: HARD_BLOCK takes precedence over FORCE_ASSISTED, which takes precedence over AUDIT_ONLY. All activated Watchtowers MUST be recorded in the Audit Trace regardless of which governs the routing decision.¶

Watchtower = {
  id:           string,     // e.g., "WT-03-APP-FRAUD"
  name:         string,     // human-readable
  vertical:     string[],   // applicable verticals, or [*] for all
  priority:     integer,    // evaluation order (lower = earlier)
  severity:     HARD_BLOCK | FORCE_ASSISTED | AUDIT_ONLY,
  trigger:      function(interaction) -> boolean,
  evidence:     function(interaction) -> object,
  buyer_signal: string      // regulatory/commercial pain addressed
}

7. Audit Trace Schema

The Audit Trace is the primary output of every OMP routing event. It is not a log. It is a structured evidence record designed to satisfy regulatory examination requirements. Every field is mandatory unless explicitly marked OPTIONAL. Fields marked PRIVILEGED are protected from third-party disclosure under applicable work product doctrine.¶

All Audit Trace records produced under this specification MUST carry schema_version field value "VERIDOM-SCHEMA-001-v1.0". Implementations that extend the schema MUST use a distinct schema_version string.¶

{
  // IDENTITY
  "trace_id":              "UUID v4",
  "trace_version":         "1.0",
  "created_at":            "ISO 8601 UTC (millisecond precision)",
  "vertical":              "string",
  "deployment_id":         "string",
  "schema_version":        "VERIDOM-SCHEMA-001-v1.0",

  // INTERACTION
  "interaction_id":        "UUID v4",
  "interaction_received":  "ISO 8601 UTC",
  "interaction_hash":      "sha256(normalised_payload)",
  "channel":               "string",
  "requester_id":          "string (anonymised)",

  // INTENT CLASSIFICATION
  "intent_class":          "string",
  "intent_confidence":     "float [0.0, 1.0]",
  "intent_top3":           "[{class, confidence}]",
  "classifier_version":    "string",

  // CONFIDENCE SCORING
  "confidence_score":      "float [0.0, 1.0]",
  "confidence_components": {
    "C_m": "float", "C_p": "float", "C_d": "float",
    "weights": { "C_m": "float", "C_p": "float", "C_d": "float" }
  },
  "routing_threshold":     "float",

  // WATCHTOWER EVALUATIONS
  "watchtowers_evaluated": [
    { "watchtower_id": "string", "triggered": "boolean",
      "severity": "string", "evidence": "object",
      "evaluated_at": "ISO 8601 UTC" }
  ],
  "watchtower_override":    "boolean",
  "override_watchtower_id": "string | null",

  // ROUTING DECISION
  "routing_path":          "AUTONOMOUS | ASSISTED | ESCALATED",
  "routing_rationale":     "string",
  "routing_decided_at":    "ISO 8601 UTC",

  // PATH-SPECIFIC FIELDS
  "autonomous_dispatch":   "object | null",
  "assisted_resolution":   "object | null",
  "escalation_record":     "object | null",

  // RFC 3161 TIMESTAMP
  "tst_time":              "ISO 8601 UTC (millisecond precision)",
  "tst_tsa_identity":      "string",  // TSA DN. Mandatory.
  "tst_raw":               "Base64 (raw TimeStampToken)",
  "tst_serial":            "string",
  "tst_hash_alg":          "SHA-256",
  "tst_message_imprint":   "sha256 (must equal trace_content_hash)",
  "tst_certificate":       "Base64 | URI",

  // CRYPTOGRAPHIC SEALING
  "source_state_hash":     "sha256 | null",
  "trace_content_hash":    "sha256",
  "trace_chain_hash":      "sha256",
  "sealed_at":             "ISO 8601 UTC",
  "seal_version":          "SHA256-RFC3161-CHAIN-v1"
}

8. Cryptographic Sealing

The sealing process transforms the Audit Trace into a legally defensible evidence record. The chain is: SHA-256 hash of the decision record, followed by [RFC3161] timestamp from an accredited TSA, followed by institution-signed container. Veridom does NOT sign. The institution signs. This preserves evidentiary independence.¶

FUNCTION ComputeSourceStateHash(api_response) -> H_s:
  canonical_json = CanonicalJSON(api_response)  // see RFC 8785
  input = canonical_json + '|' + QueryTimestamp_ms
  H_s = SHA256(input)
  RETURN H_s

FUNCTION ComputeTraceContentHash(trace) -> H_content:
  fields_to_hash = trace.excluding([
    'trace_content_hash', 'trace_chain_hash',
    'sealed_at', 'seal_version',
    'tst_time', 'tst_tsa_identity', 'tst_raw',
    'tst_serial', 'tst_certificate'
  ])
  canonical_json = CanonicalJSON(fields_to_hash)  // see RFC 8785
  H_content = SHA256(canonical_json)
  RETURN H_content

FUNCTION RequestTimestamp(H_content) -> TST:
  request = TimestampRequest(
    hashAlgorithm:  SHA-256,
    messageImprint: H_content,
    nonce:          SecureRandom(64-bit),
    certReq:        TRUE
  )
  TST = TSA.sign(request)
  VERIFY TST.messageImprint == H_content
  RETURN TST
  // The TSA signs only the hash, never the trace content.
  // No sensitive payload is transmitted to the TSA.

Layer 1 - Content:   H_content = SHA-256(canonical trace record)
Layer 2 - Time:      TST = TSA.sign(H_content)
                      [external, independent]
Layer 3 - Identity:  Proof-Point = Institution.sign(trace + TST)

FUNCTION ComputeChainHash(trace, previous_H_c) -> H_c:
  input = trace.trace_content_hash + '|' + previous_H_c
  H_c = SHA256(input)
  RETURN H_c

// Genesis block:
// previous_H_c = SHA256('VERIDOM-GENESIS-' + deployment_id)

FUNCTION VerifyChain(traces[]) -> boolean:
  expected_H_c = GenesisHash(traces[0].deployment_id)
  FOR each trace in traces (ordered by sealed_at):
    computed = SHA256(CanonicalJSON(trace.excluding(sealing_fields)))
    IF computed != trace.trace_content_hash: RETURN FALSE
    expected_H_c = SHA256(computed + '|' + expected_H_c)
    IF expected_H_c != trace.trace_chain_hash: RETURN FALSE
  RETURN TRUE

9. Change Control

Any modification to a production VerticalConfig, routing threshold, Watchtower definition, or confidence weight REQUIRES a Threshold Change Record (TCR) documenting: the change, the rationale, the validation data supporting the change, and the Named Accountable Officer authorising deployment.¶

A 30-day written notice period to the client's designated compliance officer is REQUIRED before any change takes effect in production. The TCR MUST itself be sealed with SHA-256 and appended to the deployment evidence ledger. No retroactive modification of configuration is permitted.¶

10. Metrics and Observability

OMP produces three operationally independent metric streams. These streams MUST NOT be aggregated into a single resolution rate for internal system health analysis. Aggregation conceals the difference between system performance and human compensation.¶

The diagnostic order when investigating a system health issue is MANDATORY: (1) Autonomous Dashboard -- is the system still deciding correctly? (2) Assisted Dashboard -- is the human gate catching problems? (3) Escalated Dashboard -- are failures being categorised correctly for improvement? Inverting this order produces misleading diagnoses.¶

11. Implementation Requirements

SHA-256 implementation MUST conform to [FIPS180-4].¶

Canonical JSON serialisation MUST conform to [RFC8785]. All floating-point values MUST be serialised with minimum 15 significant digits.¶

All timestamps MUST be UTC, ISO 8601 format, with millisecond precision. Maximum acceptable clock drift: 50ms.¶

The append-only evidence ledger MUST be implemented as a write-once data store. Deletion MUST be architecturally impossible, not merely policy-restricted.¶

Confidence Score computation MUST be stateless. No hidden state or session memory MAY influence C.¶

12. Security Considerations

13. IANA Considerations

This document makes no requests of IANA. If a future version of this protocol defines a registry of Watchtower identifiers or schema version strings, an appropriate IANA registry request will be made at that time.¶

Authors' Addresses