tibet-pol — Process Integrity Checker

Every step a TIBET token. Every deviation an alert.

"Pol kan nooit meer vergeten een knop in te drukken."

tibet-pol verifies that multi-step processes run completely and correctly. Each step produces a cryptographic TIBET provenance token. If a step fails or is skipped, you know exactly what went wrong, when, and why.

Think of it as a checksum for processes — the same way you verify file integrity after download, tibet-pol verifies process integrity after execution.

Origin Story

A Google engineer named Pol had a sync problem — his system didn't reliably track which steps had completed. After weeks in the support loop, the solution was obvious: "Let's just count the steps." Like checksums verify files after download/unpack/install, tibet-pol counts and verifies system tasks.

Install

pip install tibet-pol

Airlock runtime observer (since 0.3.3)

tibet-pol is the emit-side of the airlock immune-switch pipeline. It observes the airlock-runtime layer-states and derives airlock_runtime_verdict.v1 records that snaft consumes (and tibet-airlock enforces against). The detector is injectable so production wires it to real port/proc/health checks while tests use static probes.

from tibet_pol.runtime_observer import (
    RuntimeLayerState, derive_verdict, emit_verdict, static_probe,
)

state = RuntimeLayerState(
    rust_airlock="offline",
    trust_kernel="online_without_airlock",
    python_fallback="enabled",
)
verdict = derive_verdict(state)
# {
#   "kind": "airlock_runtime_verdict.v1",
#   "runtime_mode": "python_fallback",
#   "external_ai_inbound": "deny",       # the immune-switch invariant
#   "snaft_posture": "quarantine_external_ai",
#   ...
# }

# Or with a probe:
probe = static_probe(rust_airlock="embedded", trust_kernel="online_with_airlock")
verdict = emit_verdict(probe)

The verdict is derived from the layer-states per the preference order (embedded_online > kernel_online > python_fallback > offline); no judgment calls. Each verdict passes tibet_cap_bus.validate_verdict_record and check_mode_coherence by construction.

Reference: Codex policy 2026-05-29 (sandbox/ai/codex/airlock-runtime-policy-immune-switch-2026-05-29.md).

Quick Start

Check a process

tibet-pol check deploy.json

🔍 tibet-pol: Checking 'Server Deployment'...

  🔍 Checking: Database Migrated... ✓
  🔍 Checking: API Service Running... ✓
  🔍 Checking: Health Check Passing... ✓
  🔍 Checking: Cache Warmed... ✗ FAILED
  🔍 Checking: Monitoring Active... ✓

=======================================================
📋 TIBET-POL PROCESS INTEGRITY REPORT
   Process: Server Deployment
=======================================================

⚠️ Status: INCOMPLETE
   Checksum: 4/5 (80%)
   ├── Success: 4
   ├── Failed:  1
   ├── Blocked: 0
   └── Skipped: 0

JSON output for CI/CD

tibet-pol check --json pipeline.json | jq .summary

{
  "total": 6,
  "success": 6,
  "checksum": "6/6",
  "percentage": 100,
  "status": "COMPLETE"
}

Exit code 0 = COMPLETE, 1 = INCOMPLETE. Plug directly into your CI pipeline.

Create a template

tibet-pol init my_process.json

Watch mode (continuous monitoring)

tibet-pol watch deploy.json --interval 300

Compare two runs

tibet-pol diff run_20260227.json run_20260228.json

HTML report

tibet-pol check --save --json deploy.json > run.json
tibet-pol report run.json -o report.html

Process Templates

A template is a JSON file defining steps, dependencies, and check commands:

{
  "process_id": "my_deploy",
  "name": "My Deployment",
  "version": "1.0.0",
  "steps": [
    {
      "id": "db_migrated",
      "name": "Database Migrated",
      "check": "python manage.py migrate --check",
      "dependencies": [],
      "critical": true
    },
    {
      "id": "api_up",
      "name": "API Running",
      "check": "curl -sf http://localhost:8080/health",
      "dependencies": ["db_migrated"],
      "critical": true,
      "timeout_seconds": 10
    },
    {
      "id": "cache_warm",
      "name": "Cache Warmed",
      "check": "redis-cli ping",
      "dependencies": ["api_up"],
      "critical": false
    }
  ]
}

Step fields

Field	Required	Description
id	yes	Unique step identifier
name	yes	Human-readable name
check	yes	Shell command (exit 0 = success)
dependencies	no	List of step IDs that must pass first
critical	no	If true, downstream steps are blocked on failure
timeout_seconds	no	Max execution time (default: 30)
intent	no	Why this step exists (stored in TIBET token)
on_failure	no	Remediation command hint

Dependency resolution

Steps are executed in topological order based on dependencies (DAG). If a dependency fails, downstream steps are marked BLOCKED — not executed.

db_migrated ──→ api_up ──→ health_check
                  │
                  ├──→ cache_warm
                  └──→ monitoring

TIBET Provenance

Every step produces a TIBET token with four provenance layers:

Layer	Content	Example
ERIN	What happened	Step ID, status, output
ERAAN	Dependencies	Which steps had to pass first
EROMHEEN	Context	Machine, timestamp, user, PID
ERACHTER	Intent	Why this step exists

Tokens are chained — each references its parent. The full chain is an immutable audit trail of the process execution.

When tibet-core is installed, tokens are also registered with the TIBET Provider for cross-system provenance.

Python API

from tibet_pol import ProcessChecker, load_template

template = load_template("deploy.json")
checker = ProcessChecker(verbose=True)
result = checker.run(template)

print(result.summary)
# {'total': 5, 'success': 5, 'checksum': '5/5', 'percentage': 100, 'status': 'COMPLETE'}

# Access individual steps
for step in result.steps:
    print(f"{step.step_name}: {step.status} ({step.duration_ms}ms)")

# Full TIBET token chain
for token in result.tokens:
    print(token["token_id"], token["erin"]["status"])

Example Templates

tibet-pol ships with example templates:

• ci_pipeline.json — CI/CD: checkout → deps → lint → test → build → publish
• server_deploy.json — Deploy: DB migrate → API up → health check → cache → monitoring

Use Cases

Scenario	Template
CI/CD pipeline audit	Lint → Test → Build → Sign → Publish
Server deployment	DB migrate → API → Health → Cache → Monitor
Kubernetes rollout	Image pull → Deploy → Rollout → Probes → DNS
Incident response	Detect → Isolate → Fix → Verify → Report
Data pipeline	Extract → Validate → Transform → Load → Verify
Server bootstrap	OS → Network → GPU → Services → APIs

Part of the TIBET ecosystem

Package	Purpose
tibet-core	Protocol core — zero deps
jis-core	Identity standard
tibet-audit	Security audit tooling
tibet-y2k38	Y2K38 Time Bridge
tibet-pol	Process Integrity Checker
tibet-pqc	Post-Quantum Crypto router
tibet-overlay	IPv4/IPv6 identity overlay
tibet-twin	Digital Twin synchronicity

Standards

• TIBET Protocol: IETF Draft
• JIS Identity: IETF Draft
• Zenodo: DOI Publications

License

MIT — Humotica AI Lab 2025-2026

Authors

• J. van de Meent — jasper@humotica.com
• R. AI (Root AI) — root_idd@humotica.nl

Credits

Designed by Jasper van de Meent. Built by Jasper and Root AI as part of HumoticaOS.

---

Stack-positie: Groep agentic · Bootstrap = OSAPI-handshake naar tibet + jis (fail → snaft-rule + tibet-pol-rapport) · ← tibet-triage · tibet-report → · See STACK.md · See demo/golden-path/ for the spine end-to-end.

Enterprise

For private hub hosting, SLA support, custom integrations, or compliance guidance:

Enterprise	enterprise@humotica.com
Support	support@humotica.com
Security	security@humotica.com

See ENTERPRISE.md for details.