
---

# TECHNICAL SPECIFICATION: THE ODGS PROTOCOL

**SUBJECT:** Runtime Enforcement, Data Sovereignty & ISO 42001 Alignment
**VERSION:** 3.0.0 (Stable / ISO-Ready)
**DATE:** February 2026

### 1. ABSTRACT

The Open Data Governance Standard (ODGS) resolves the "Definition-Execution Gap" in High-Risk AI systems. It provides a vendor-neutral protocol to enforce **Administrative Safety** by strictly separating Policy (The Legislative Plane) from Execution (The Physical Plane).

This document outlines the core architecture of the v3.0.0 release, specifically focusing on the **"Sovereign Sidecar"** pattern, designed for alignment with **NEN Standards Committee 381 525** (Data, Cloud & Edge), the **EU AI Act** (Articles 10 & 12), and **ISO/IEC 42001**.

### 2. CORE PHILOSOPHY: CONFIGURATION AS LAW

The foundational premise of ODGS is that **Data Definition must be decoupled from Data Execution.**

* **Legacy Approach:** Governance logic is hard-coded in application software (e.g., Python: `if value < 470000`). Changing the policy requires a code rewrite, testing, and deployment cycle.
* **ODGS Approach:** Governance logic is externalized in immutable **JSON Configuration Files**.
* *Agility:* A policy change is a configuration update, not a software deployment.
* *Enforcement:* The Interceptor enforces the new law instantly across all connected systems.



### 3. THE 5-PLANE ARCHITECTURE

ODGS implements a hierarchical "Constitutional Stack" where mechanical execution is legally bound by semantic definitions.

1. **Plane 1: Governance (The Mandate)**
* *Role:* Captures human intent and policy scope (e.g., "Zero Tolerance for Fraud").
* *ISO Control:* B.5.1 (AI Policy).


2. **Plane 2: Legislative (The Definition)**
* *Role:* The strict semantic definition of truth.
* *Artifact:* `standard_metrics.json` (Immutable Hash).
* *ISO Control:* B.7 (Data Management).


3. **Plane 3: Judiciary (The Enforcer)**
* *Role:* The logic engine that validates data against the Legislative definition.
* *Mechanism:* If Data  Definition, trigger **Hard Stop**.
* *ISO Control:* B.9 (AI System Operations).


4. **Plane 4: Executive (The Context)**
* *Role:* The mapping of definitions to specific business contexts (e.g., "Fiscal Year 2026").


5. **Plane 5: Physical (The Reality)**
* *Role:* The raw data streams, sensors, and infrastructure.



### 4. DATA SOVEREIGNTY: THE "GIT-AS-BACKEND" MODEL

To satisfy the strict data residency requirements of Dutch Administrative Law and the EU Data Strategy, ODGS v3.0.0 operates on a **"Privacy-Native"** architecture.

#### **4.1 The Sovereign Sidecar Pattern**

The ODGS Interceptor operates as a lightweight "Sidecar" within the host organization’s infrastructure.

* **Zero-Trust Logging:** The Interceptor computes all cryptographic proofs locally. It does **not** transmit telemetry, payloads, or metadata to any external third-party server (including Metric Provenance).
* **Direct-to-Git Commit:** The Runtime Audit Log (Article 12 Evidence) is cryptographically signed and committed directly to the organization’s **internal Private Git Repository**.
* **Result:** The Ministry retains 100% custody of the forensic evidence. The protocol provides the *schema*; the organization holds the *keys*.

### 5. FORENSIC AUDITABILITY (ARTICLE 12 COMPLIANCE)

To satisfy the **"Automatic Recording of Events"** requirement (EU AI Act Art. 12), the Interceptor generates a standardized JSON Audit Log for every inference event using the **Tri-Partite Binding**.

**The Binding Schema:**
Every log entry cryptographically binds three elements:

1. **The Input Data Hash:** Proof of *what* was processed (Privacy-Preserved).
2. **The Definition Hash:** Proof of *which* rule was applied (Legislative Plane).
3. **The Configuration Hash:** Proof of the *context* (Executive Plane).

**Sample Schema (JSON):**

```json
{
  "event_id": "uuid-v4-signature",
  "timestamp": "2026-02-14T14:00:00Z",
  "outcome": "HARD_STOP",
  "reason": "SEMANTIC_DRIFT_DETECTED",
  "evidence": {
    "active_definition_hash": "sha256:7f9a2...",
    "input_payload_hash": "sha256:3b1c9...",
    "iso_control_ref": "ISO-42001-B.9"
  },
  "compliance_ref": "EU-AI-ACT-ART-10"
}

```

### 6. ARCHITECTURAL CASE STUDY: HOUSING FRAUD

*Why "Configuration as Law" prevents Administrative Failure.*

* **The Scenario:** A housing guarantee (NHG) limit is set at €470,000.
* **Legacy System:** Hard-codes the check: `Is Price < 470000?`
* *Failure:* If the market value is €300,000 but the transaction is artificially inflated to €460,000 (a "flip"), the Legacy System approves it because the number is technically under the cap. This is syntactically correct but semantically fraudulent.


* **ODGS System:** The Interceptor checks the **Legislative Plane**.
* *Logic:* It retrieves the definition of "Valid Market Value" (which requires a Valuation Report, not just a Transaction Price).
* *Action:* The Judiciary Plane sees the gap between Price (€460k) and Value (€300k). It triggers a **Hard Stop**.
* *Outcome:* The AI is physically prevented from issuing the guarantee.



### 7. CONCLUSION

The ODGS Protocol (v3.0.0) offers a deterministic method for **Administrative Recusal**. By prioritizing "Silence over Error," it ensures that High-Risk AI systems cannot operate outside their legal safety envelope, providing the necessary technical safeguards for public sector algorithms.

---

