TENIR-Gov · The Execution Control Plane for Agentic AI

It decides whether what AI wants to do is allowed to become real.

TENIR-Gov is an Execution Control Plane for agentic AI. It governs the transition from machine-generated decision or intent to consequential execution — deterministically, at runtime, with cryptographically verifiable decision records.

TENIR-Gov occupies one precise layer: the runtime boundary between decision and action.

It does not replace an LLM, an identity system, an observability stack, a policy repository, or an enterprise governance program. It provides a deterministic control surface that can be placed after reasoning and policy evaluation, and before consequential execution.

AI can reason autonomously. TENIR-Gov controls whether that reasoning is admissible for execution.

Three-Sentence Pitch

1. Problem: Models reason and agents propose actions — but a consequential action needs a runtime decision about whether it is admissible before execution.
2. Solution: TENIR-Gov provides a deterministic execution-control layer at the decision → action boundary, with explicit policy thresholds and fail-closed defaults.
3. Proof: The v5.4.2 package includes a two-kernel composition layer (continuous risk monitor + discrete invariant enforcer), a HOLD lifecycle for governed suspension of agency, a dispatch provider abstraction, post-execution assessment (τ⁻¹ and EVP), a hardened I8 aggregate budget invariant with governor-owned reservation, automated validation (733 tests across tests/ and r4/tests/), and hash-chained decision records.

Positioning

TENIR-Gov is expressed at three levels:

The category describes where TENIR-Gov sits.

The architectural primitive describes the control boundary implemented by the system.

The promise describes the operational property without implying that TENIR-Gov replaces the rest of an organization's governance stack.

What TENIR-Gov Is / Is Not

Why Runtime Control Matters

Agentic AI introduces a distinction between producing a decision and executing that decision.

Current governance guidance increasingly emphasizes runtime boundaries, constrained autonomy, technical controls, and meaningful accountability.

Gartner has highlighted the gap between written governance policies and runtime controls capable of constraining autonomous actions at machine speed. Its 2026 research also recommends embedding enterprise rules, approvals, escalation paths, and other constraints into agent design and runtime controls.

Singapore's IMDA Model AI Governance Framework for Agentic AI, updated in May 2026, similarly emphasizes bounding agent powers, meaningful human accountability, and technical controls throughout the agent lifecycle.

TENIR-Gov addresses one implementation layer within that broader landscape:

the runtime decision about whether a proposed transition is admissible under the active control policy.

It does not claim that runtime admissibility alone constitutes complete AI governance.

Product Architecture

TENIR-Gov has one deterministic Core with additional control and analysis capabilities around it.

                         TENIR-Gov
                 THE EXECUTION CONTROL PLANE
                              │
             ┌────────────────┴────────────────┐
             │                                 │
             ▼                                 ▼
   CONSTITUTIONAL CORE                CONTROL & VALUE MODULES
             │                                 │
   ┌─────────┼─────────┐              ┌────────┼─────────┐
   │         │         │              │        │         │
   ▼         ▼         ▼              ▼        ▼         ▼
Policy    Admissibility   Merkle     NSL      VPS       EVP
Engine     Decision       Ledger    Policy  Forensics  Analytics
   │
   ▼
PASS / FLAG / HARD_VETO
   │
   ▼
Execution Gateway
   │
   ▼
Consequential Action

Core

The Core provides:

• deterministic policy evaluation;
• admissibility scoring;
• PASS / FLAG / HARD_VETO outcomes;
• configurable thresholds;
• execution-gating semantics;
• append-only cryptographic decision records; and
• API access.

The lightweight implementation is located under:

tenir-kernel/

The kernel is designed to remain independently deployable from the broader middleware surface.

Modules

The repository also contains additional components for policy authoring, validation, forensic analysis, integration, and value-protection workflows.

These modules should not be interpreted as changing the authority of the Core.

In particular:

EVP consumes governance records read-only. It has no write path back into the Core and cannot alter an admissibility verdict.

This separation prevents downstream valuation or analytics signals from becoming an implicit control input to the execution decision.

Core Decision Model

The v5.3.0 kernel uses:

S = K / (P × V + ε)

Where:

The formula is an implementation construct of the v5.3.0 policy model. It should not be interpreted as a universal measure of safety, risk, or organizational capacity.

Kernel verdicts

For the demonstrator policy profile:

Default demonstrator thresholds:

epsilon          = 1e-6
hard_veto_below  = 0.5
flag_below       = 1.2

Thresholds are policy parameters, not universal constants.

Institutional deployments should calibrate them against their declared operating constraints, action classes, and review requirements.

Fail-Closed Semantics

v5.3.0 is designed around a fail-closed control posture at the kernel decision boundary.

Where the active policy determines that a request falls outside the admissible operating region, the kernel produces:

HARD_VETO

A HARD_VETO is not a recommendation. It is the kernel-level negative execution disposition under the active policy.

The wider system may additionally implement review, escalation, recovery, or alternative handling according to its deployment profile.

Quick Start

Install

pip install tenir-governance

Or with the composition layer and CLI tools (included by default):

pip install tenir-governance[test]

Core — Standalone Kernel

cd tenir-kernel
pip install -r requirements.txt
./run.sh

The development server starts on port 8000.

Example:

curl -X POST http://localhost:8000/api/v1/adjudicate \
  -H "Content-Type: application/json" \
  -d '{
    "actor_id": "operator-1",
    "action_context": "deploy-model",
    "p": 0.7,
    "v": 0.5,
    "k": 1.2
  }'

Full Middleware

pip install -e .
docker compose up -d --build

Example Python usage:

from tenir_governance.sdk import TENIRGovernanceClient, GovernanceEvent

client = TENIRGovernanceClient()

result = client.adjudicate(
    GovernanceEvent(
        pressure=0.7,
        velocity=0.5,
        capacity=1.2
    )
)

print(result.to_business_payload())

Repository Architecture

v5.3.0 · IRON OMEGA

tenir-gov/
│
├── tenir-kernel/                  # Standalone deterministic kernel
│   ├── core/
│   │   ├── policy_engine.py       # S = K / (P × V + ε)
│   │   └── ledger.py              # SHA-256 / Merkle-backed records
│   ├── api/
│   │   └── server.py              # FastAPI adjudication endpoint
│   ├── tenir_policies.yaml        # Kernel policy configuration
│   ├── tests/
│   │   └── test_tenir_kernel.py   # K1–K8 kernel tests
│   ├── requirements.txt
│   └── run.sh
│
├── tenir_governance/              # Full governance package
│   ├── nomenclature.py
│   ├── policy_engine.py
│   ├── validator.py
│   ├── regression_corpus.py
│   ├── sdk.py
│   ├── polymorphic_surface.py
│   ├── copy_lint.py
│   └── ledger_migrate.py
│
├── r4/                            # R4 monitor runtime
├── r5_hardened/                   # R5 hardened runtime
├── r5_wired/                      # R5 integration layer
├── interface/                     # Operational interface
├── tests/                         # Governance-package tests
├── Dockerfile
├── docker-compose.yml
└── .github/workflows/             # CI pipeline

API Reference

Start the R5 server:

docker compose up -d --build

or:

uvicorn r5_hardened.IRON_OMEGA_R5.r5_server:app \
  --host 0.0.0.0 \
  --port 8000

Endpoint availability depends on the selected runtime/profile.

Policy Profiles

Kernel Demonstrator Profile

Full Middleware

Default policy fingerprint:

d083e0b82a16c04d

Profiles are deployment configurations. They should not be interpreted as universal TENIR policy values.

Auditability

TENIR-Gov records governance decisions using an append-only cryptographic ledger structure.

The R5 implementation provides:

• SHA-256 hashing;
• chained records;
• Merkle-based integrity structures;
• ledger verification; and
• inclusion-proof support.

The ledger provides cryptographic evidence of record integrity.

It does not, by itself, prove that a policy was correct, that an input was truthful, or that an action was appropriate. Those are separate governance and assurance questions.

Test Suite

v5.3.0 contains separate validation scopes.

The reported coverage figure is:

96% statement coverage

for the tenir_governance package under the defined test configuration.

Coverage does not imply that every runtime component, deployment configuration, integration, or operational environment has equivalent coverage.

Run the kernel tests:

cd tenir-kernel
pytest tests/ -v

Run the full validation configuration:

pytest tests/ r4/tests/ \
       r5_hardened/IRON_OMEGA_R5/test_r5_all.py \
       r5_hardened/IRON_OMEGA_R5/test_institutional_hardening.py \
       r5_wired/test_r5_governance_integration.py \
       --cov=tenir_governance \
       --cov-report=term-missing

CI Validation

The repository includes policy and invariant validation:

tenir-validate --policy default
tenir-validate --policy partner_a --json
tenir-validate --policy partner_b

The validation command checks the selected policy against the repository's defined invariants.

Conformance to these checks should not be interpreted as proof of organizational governance maturity or production suitability.

Performance

v5.3.0 includes an internal benchmark performed on:

AMD Ryzen 9 7950X
64 GB DDR5
Ubuntu 22.04
10,000 sequential requests
localhost
minimal JSON payload

Reported measurements:

These measurements are benchmark observations, not SLAs.

Results will vary with hardware, payload size, policy complexity, storage, network topology, concurrency, and deployment architecture.

The repository does not use the benchmark to claim a universal throughput guarantee.

Experimental and Historical Components

The repository contains components originating from earlier R4/R5 development stages and experimental runtime work.

These include:

• R4 monitoring components;
• R5 hardened runtime components;
• VPS runtime surfaces;
• CES state modelling;
• additional policy and graph integrations.

Their presence in the repository does not mean that every component is part of the minimal deterministic kernel or has the same implementation status.

The kernel and full middleware should therefore be distinguished from experimental, integration, and historical components when evaluating v5.3.0.

CES State Model

The repository contains a Cognitive Engagement System (CES) state model:

REST
  ↓
METABOLIZING
  ↓
TENSION
  ↓
SIGNAL_CONFLICT
  ↓
COLLAPSE

with a recovery path from SIGNAL_CONFLICT toward METABOLIZING.

CES is an internal/experimental governance-state model in the R5 repository. It is not required to understand or execute the core admissibility calculation.

Terminology

v5.3.0 replaces several historical internal terms with neutral canonical terminology.

Backward-compatible aliases are preserved where required for existing records and compatibility.

Integration Position

TENIR-Gov is designed to complement adjacent infrastructure.

TENIR-Gov is therefore not positioned as a replacement for these systems.

It is an additional control layer at the decision → execution boundary.

What TENIR-Gov Does Not Claim

TENIR-Gov does not claim that:

• the admissibility formula is a universal safety metric;
• a Merkle ledger proves the correctness of a decision;
• deterministic execution control eliminates all agentic-AI risk;
• a HARD_VETO guarantees physical prevention in every deployment;
• the kernel replaces identity, authorization, cybersecurity, observability, or enterprise governance;
• benchmark latency represents a production SLA;
• repository test coverage represents complete operational assurance.

These distinctions are intentional.

The purpose of TENIR-Gov is narrower:

make the decision to cross from autonomous reasoning into consequential execution an explicit, policy-controlled runtime event.

Scientific / Research Context

TENIR-Gov is part of the broader TENIR research and engineering program concerning runtime admissibility, autonomous systems, governance boundaries, and preservation of decision integrity under pressure.

The v5.3.0 repository implements the deterministic governance spine.

Broader TENIR concepts and ontological structures may appear in research materials and future releases, but they should not be inferred to be implemented by the v5.3.0 kernel merely because they exist in the broader framework.

Citation

If you use TENIR-Gov in research or engineering work, cite the Zenodo release:

Skiredj, A. (2026).
TENIR-Gov: Governance Middleware for AI-Enabled Operational Systems.
Zenodo.
https://doi.org/10.5281/zenodo.21277138

DOI:

https://doi.org/10.5281/zenodo.21277138

A machine-readable citation is also provided through CITATION.cff.

License

Apache License 2.0.

See LICENSE.

Copyright © 2026 Abdelaziz Skiredj / TENIR Labs