Network Working Group T. Adebayo Internet-Draft F. Makanjuola Intended status: Informational O. Apalowo Expires: 22 September 2026 Veridom Ltd 21 March 2026 Operating Model Protocol (OMP): A Deterministic Routing and Evidence Architecture for AI Decision Accountability in Regulated Industries draft-veridom-omp-00 Abstract Regulated institutions deploying AI face a structural evidence problem: the gap between what their systems claim to do and what they can prove happened at the level of an individual decision. Existing compliance infrastructure addresses this problem observationally -- monitoring, dashboards, retrospective reporting -- but does not close it structurally. This specification defines the Operating Model Protocol (OMP), a deterministic routing invariant that classifies every interaction in a regulated operation to exactly one of three outcome states -- AUTONOMOUS, ASSISTED, or ESCALATED -- and generates a tamper-evident audit trace at the point of every decision. The routing decision is a deterministic function of a composite Confidence Score, Watchtower enforcement evaluations, and domain-specific thresholds. Given identical inputs, the protocol produces identical outputs. This invariance is the architectural basis of the regulatory claim. Each audit trace is sealed using a three-layer cryptographic integrity architecture: SHA-256 content hash, RFC 3161 trusted timestamp from an accredited third-party Timestamp Authority, and institution signature. The chain forms a Merkle structure in which modification of any historical trace invalidates all subsequent chain hashes. Per-decision accountability is therefore verifiable by any third party without access to the institution's or Veridom's infrastructure. The protocol has been independently instantiated across four regulated domains -- digital credit under the Kenya CBK NDTCP framework, FCA Consumer Duty, FCA agent distribution oversight, and US legal AI supervision under ABA Rule 5.3 -- with the same two invariants holding in each: deterministic classification and immutable audit trail. Domain-specific profiles for digital credit and cooperative lending are published separately as draft-veridom- omp-ndtcp and draft-veridom-omp-sacco. Adebayo, et al. Expires 22 September 2026 [Page 1] Internet-Draft OMP Core Protocol March 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Relationship to Related Work . . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Architecture . . . . . . . . . . . . . . . . . . . . 6 5. Routing Decision Logic . . . . . . . . . . . . . . . . . . . 7 5.1. Routing Decision Tree . . . . . . . . . . . . . . . . . . 8 5.2. Confidence Score Computation . . . . . . . . . . . . . . 8 5.3. Path Specifications . . . . . . . . . . . . . . . . . . . 9 5.3.1. AUTONOMOUS Path . . . . . . . . . . . . . . . . . . . 9 5.3.2. ASSISTED Path . . . . . . . . . . . . . . . . . . . . 9 5.3.3. ESCALATED Path . . . . . . . . . . . . . . . . . . . 10 6. Watchtower Framework . . . . . . . . . . . . . . . . . . . . 11 6.1. Watchtower Definition Schema . . . . . . . . . . . . . . 11 6.2. Core Watchtower Registry v1.0 . . . . . . . . . . . . . . 11 7. Audit Trace Schema . . . . . . . . . . . . . . . . . . . . . 12 8. Cryptographic Sealing . . . . . . . . . . . . . . . . . . . . 14 8.1. Source State Hash (H_s) . . . . . . . . . . . . . . . . . 14 Adebayo, et al. Expires 22 September 2026 [Page 2] Internet-Draft OMP Core Protocol March 2026 8.2. Trace Content Hash . . . . . . . . . . . . . . . . . . . 14 8.3. RFC 3161 Trusted Timestamp . . . . . . . . . . . . . . . 14 8.4. Trace Chain Hash (Merkle Chain) . . . . . . . . . . . . . 15 8.5. Proof-Point Artifact Sealing . . . . . . . . . . . . . . 16 9. Change Control . . . . . . . . . . . . . . . . . . . . . . . 16 10. Metrics and Observability . . . . . . . . . . . . . . . . . . 16 11. Implementation Requirements . . . . . . . . . . . . . . . . . 16 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 12.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 17 12.2. Fully Compromised Host . . . . . . . . . . . . . . . . . 17 12.3. Confidence Score Gaming . . . . . . . . . . . . . . . . 18 12.4. Watchtower Override Restriction . . . . . . . . . . . . 18 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 14.1. Normative References . . . . . . . . . . . . . . . . . . 18 14.2. Informative References . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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 Adebayo, et al. Expires 22 September 2026 [Page 3] Internet-Draft OMP Core Protocol March 2026 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. 1.1. Relationship to Related Work Several specifications address overlapping problem spaces. This document notes the following related work and its relationship to OMP: * [I-D.cowles-volt], [I-D.cowles-aocl], and [I-D.cowles-aee] define VOLT (hash-chained operations ledger), AOCL (11-layer governance pipeline), and AEE (agent envelope exchange) respectively. These drafts address generic agentic AI workflows. OMP addresses the specific domain requirements of regulated financial services: per- decision credit decision explainability, principal-agent accountability under named regulatory frameworks, and regulator- ready evidence artifact generation. The architectural approaches are complementary; OMP adds [RFC3161] trusted timestamping to close the host-compromise threat that VOLT explicitly acknowledges in its own threat model (T7). 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 Adebayo, et al. Expires 22 September 2026 [Page 4] Internet-Draft OMP Core Protocol March 2026 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. Adebayo, et al. Expires 22 September 2026 [Page 5] Internet-Draft OMP Core Protocol March 2026 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. Adebayo, et al. Expires 22 September 2026 [Page 6] Internet-Draft OMP Core Protocol March 2026 +=======+================+==================================+ | Stage | Name | Function | +=======+================+==================================+ | S1 | Ingestion and | Receive payload. Assign UUID v4 | | | Normalisation | Interaction ID. Normalise to | | | | canonical JSON per [RFC8785]. | | | | Compute interaction_hash = SHA- | | | | 256(normalised_payload). | +-------+----------------+----------------------------------+ | S2 | Intent | Classify interaction to a | | | Classification | registered Intent Class. Record | | | | intent_class, intent_confidence, | | | | and top-3 candidates with | | | | confidence scores. | +-------+----------------+----------------------------------+ | S3 | Watchtower | Evaluate all active Watchtowers | | | Evaluation | in priority order. Record | | | | triggered status, severity, and | | | | evidence for each. | +-------+----------------+----------------------------------+ | S4 | Routing | Apply routing function R(C, W, | | | Decision | theta, phi) to assign exactly | | | | one path. Record | | | | routing_rationale with explicit | | | | rule reference. | +-------+----------------+----------------------------------+ | S5 | Trace Sealing | Compute H_content, request | | | | [RFC3161] TST, compute H_c, | | | | append to ledger. | +-------+----------------+----------------------------------+ Table 1 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}. Adebayo, et al. Expires 22 September 2026 [Page 7] Internet-Draft OMP Core Protocol March 2026 5.1. Routing Decision Tree Routing is evaluated strictly top-to-bottom. The first matching condition determines the outcome. 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 5.2. Confidence Score Computation The Confidence Score C is a composite metric computed as a weighted combination of three independent signals. The composite design prevents single-signal gaming. Adebayo, et al. Expires 22 September 2026 [Page 8] Internet-Draft OMP Core Protocol March 2026 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 Signal weights are configurable per vertical deployment within the ranges: C_m in [0.30, 0.70], C_p in [0.10, 0.40], C_d in [0.10, 0.30]. Weights MUST sum to 1.0. Any modification REQUIRES a Threshold Change Record per Section 9. 5.3. Path Specifications 5.3.1. AUTONOMOUS Path An interaction routes to AUTONOMOUS if and only if all of the following are true: * No active Watchtower has returned W = TRUE with severity HARD_BLOCK or FORCE_ASSISTED. * interaction.intent_confidence is greater than or equal to 0.60. * C is greater than or equal to theta for the assigned Intent Class. * C_p is greater than 0.0 (no active policy violation). The system dispatches response without human review. A full Audit Trace MUST be generated and sealed per Section 8. Error monitoring continues for the duration of the Error Attribution Window (default: 30 minutes post-dispatch). 5.3.2. ASSISTED Path An interaction routes to ASSISTED if any of the following are true: * A Watchtower has returned W = TRUE with severity FORCE_ASSISTED. * intent_confidence is greater than or equal to 0.60 AND 0.50 is less than or equal to C which is less than theta. Adebayo, et al. Expires 22 September 2026 [Page 9] Internet-Draft OMP Core Protocol March 2026 The system generates a proposed response and places it in the Named Accountable Officer's review queue. A review SLA timer MUST be started (default: 120 seconds standard priority, 300 seconds high priority). The Named Accountable Officer MUST apply one of four Resolution Actions: RA-1 APPROVE: Proposed response dispatched as generated. Officer ID and approval timestamp logged. RA-2 EDIT + APPROVE: Officer modifies response. C_p re-evaluated on modified text. Modified response hash recorded. RA-3 REJECT -> ESCALATE: Interaction re-routed to ESCALATED. Rejection reason logged. RA-4 ATTEST + OVERRIDE: Officer overrides system assessment with independent verification. Mandatory attestation text logged. If the review SLA expires without a resolution action, the interaction MUST be automatically re-routed to ESCALATED. The SLA breach event, breach timestamp, and original assigned officer ID MUST be recorded in the Audit Trace. 5.3.3. ESCALATED Path An interaction routes to ESCALATED if any of the following are true: * A Watchtower has returned W = TRUE with severity HARD_BLOCK. * interaction.intent_confidence is less than 0.60. * C_p equals 0.0 (active policy violation). * C is less than 0.50. * SLA breach on an ASSISTED ticket (automatic re-route). Every ESCALATED interaction MUST carry exactly one primary reason code from the following set: ESC-01 (LOW_CONFIDENCE), ESC-02 (MISSING_DATA), ESC-03 (POLICY_VIOLATION), ESC-04 (WATCHTOWER_BLOCK), ESC-05 (INTENT_AMBIGUOUS), ESC-06 (SENTIMENT_SIGNAL), ESC-07 (SLA_BREACH), ESC-08 (OUT_OF_SCOPE). Adebayo, et al. Expires 22 September 2026 [Page 10] Internet-Draft OMP Core Protocol March 2026 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. 6.1. Watchtower Definition Schema 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 } 6.2. Core Watchtower Registry v1.0 +=======+==================+================+======================+ | ID | Name | Severity | Primary Trigger | +=======+==================+================+======================+ | WT-01 | PII Exposure | HARD_BLOCK | PII pattern detected | | | Shield | | in payload before | | | | | ingestion to | | | | | inference layer. | +-------+------------------+----------------+----------------------+ | WT-02 | POS Single- | HARD_BLOCK | Agent ID linked to | | | Principal | | multiple principal | | | Detector | | records OR geo- | | | | | location mismatch. | +-------+------------------+----------------+----------------------+ | WT-03 | APP Fraud Early | FORCE_ASSISTED | High-velocity | | | Warning | | reversal pattern OR | | | | | coercion language | | | | | detected. | +-------+------------------+----------------+----------------------+ | WT-04 | Regulatory | HARD_BLOCK | No response logged | Adebayo, et al. Expires 22 September 2026 [Page 11] Internet-Draft OMP Core Protocol March 2026 | | Silence Detector | | within SLA window OR | | | | | multiple follow-ups | | | | | without resolution. | +-------+------------------+----------------+----------------------+ | WT-05 | High-Value | FORCE_ASSISTED | Transaction value | | | Transaction | | exceeds vertical- | | | Guardrail | | configured threshold | | | | | OR legal language | | | | | detected. | +-------+------------------+----------------+----------------------+ | WT-06 | Operational | AUDIT_ONLY | Scheduled quarterly | | | Discipline | | trigger OR on-demand | | | Proof-Point | | invocation. | | | | | Generates Proof- | | | | | Point PDF. | +-------+------------------+----------------+----------------------+ Table 2 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)", Adebayo, et al. Expires 22 September 2026 [Page 12] Internet-Draft OMP Core Protocol March 2026 // 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" Adebayo, et al. Expires 22 September 2026 [Page 13] Internet-Draft OMP Core Protocol March 2026 } 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. 8.1. Source State Hash (H_s) When the OMP pipeline queries an external data source, it MUST capture a cryptographic snapshot of the response at the exact millisecond of query. This anchors the verification decision to a specific, immutable data state. Canonical JSON serialisation uses [RFC8785]. FUNCTION ComputeSourceStateHash(api_response) -> H_s: canonical_json = CanonicalJSON(api_response) // see [RFC8785] input = canonical_json + '|' + QueryTimestamp_ms H_s = SHA256(input) RETURN H_s 8.2. Trace Content Hash 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 [RFC8785] H_content = SHA256(canonical_json) RETURN H_content 8.3. RFC 3161 Trusted Timestamp Following computation of H_content, the OMP pipeline MUST request a TimeStampToken (TST) from an accredited Timestamp Authority conforming to [RFC3161]. The TST provides externally verifiable, third-party-attested proof that the Audit Trace existed in its exact sealed form at a specific moment in time, independently of the institution's own infrastructure. Adebayo, et al. Expires 22 September 2026 [Page 14] Internet-Draft OMP Core Protocol March 2026 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. Implementations MUST use a TSA satisfying at least one of: eIDAS Qualified TSA (EU Regulation 910/2014 Annex III), WebTrust for Certification Authorities Timestamping, or ETSI EN 319 421 / 319 422. Implementations MUST NOT use non-accredited or self-operated TSAs in regulated deployments. The three-layer integrity architecture established by this sealing process is: 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) 8.4. Trace Chain Hash (Merkle Chain) 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 Adebayo, et al. Expires 22 September 2026 [Page 15] Internet-Draft OMP Core Protocol March 2026 8.5. Proof-Point Artifact Sealing The Proof-Point artifact MUST be generated by aggregating Audit Traces over a defined time window. The artifact MUST be sealed with a document-level SHA-256 hash and signed by the institution. Veridom MUST NOT sign. The institution signs. This preserves evidentiary independence. The artifact MUST be producible in under 30 seconds for any deployment with up to 10,000 traces in the time window. 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. Adebayo, et al. Expires 22 September 2026 [Page 16] Internet-Draft OMP Core Protocol March 2026 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 12.1. Threat Model The following attack scenarios are addressed by the sealing architecture: Single trace content altered: trace_content_hash mismatch detected on verification. Chain broken from that trace forward. Trace deleted from ledger: Chain gap: H_c of following trace does not match expected value. Exact deletion position identifiable. Trace inserted retroactively: All subsequent H_c values would require recomputation. Cannot be done without full ledger write access and TSA collusion. External source API response changes post-decision: H_s proves what the source said at decision time independently of current state. No impact on trace integrity. Infrastructure breach: Chain can be independently verified from exported trace data. Institution-held export provides independent verification path. 12.2. Fully Compromised Host A fully compromised host can produce a self-consistent SHA-256 chain of fabricated records. This threat is explicitly acknowledged in related work [I-D.cowles-volt] as threat T7: "If the execution host is fully compromised, an attacker controlling the recorder can emit a consistent but fabricated trace." [RFC3161] trusted timestamping closes this gap. A compromised host cannot retroactively obtain a valid TST from an accredited TSA for fabricated records. The TSA's signature would be absent, or its timestamp would postdate the claimed event. Implementations MUST use [RFC3161] timestamping to provide externally verifiable temporal anchoring. Adebayo, et al. Expires 22 September 2026 [Page 17] Internet-Draft OMP Core Protocol March 2026 12.3. Confidence Score Gaming The composite Confidence Score uses three independent signals to prevent gaming. Implementations MUST treat C_p = 0.0 as an automatic ESCALATED outcome regardless of C_m or C_d values. The policy compliance signal cannot be compensated by high model confidence. 12.4. Watchtower Override Restriction No Watchtower MAY force an AUTONOMOUS outcome. Watchtowers MUST only override routing in the direction of greater human involvement. This restriction is architectural and MUST be enforced at the implementation level. 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. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001, . [RFC8785] Rundgren, A., Jordan, B., and S. Lindstrom, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, . [FIPS180-4] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", NIST FIPS 180-4, August 2015. 14.2. Informative References Adebayo, et al. Expires 22 September 2026 [Page 18] Internet-Draft OMP Core Protocol March 2026 [I-D.cowles-volt] Cowles, A., "Verifiable Operations Ledger and Trace (VOLT)", Work in Progress, Internet-Draft, draft-cowles- volt-00, February 2026, . [I-D.cowles-aocl] Cowles, A., "Agent Orchestration Control Layers (AOCL)", Work in Progress, Internet-Draft, draft-cowles-aocl-00, February 2026, . [I-D.cowles-aee] Cowles, A., "Agent Envelope Exchange (AEE)", Work in Progress, Internet-Draft, draft-cowles-aee-00, February 2026, . [ZENODO-OMP] Adebayo, T., Makanjuola, F., and O. Apalowo, "OMP - Operating Model Protocol: A Deterministic Routing Invariant for Tamper-Evident AI Decision Accountability in Regulated Industries", Zenodo 10.5281/zenodo.19140948, 21 March 2026. Authors' Addresses Tolulope Adebayo Veridom Ltd London United Kingdom Email: tolulope@veridom.io URI: https://veridom.io Festus Makanjuola Veridom Ltd Email: festus@veridom.io Oluropo Apalowo Veridom Ltd Email: ropo@veridom.io Adebayo, et al. Expires 22 September 2026 [Page 19]