tibet-twin — Digital Twin Synchronicity Guard

No action without proven synchronization.

Every deviation is an alert. Every decision is a TIBET token.

tibet-twin ensures physical and virtual systems are synchronized before allowing any action. When a digital twin's view of reality diverges from actual sensor data, tibet-twin blocks the action and creates a TIBET audit trail.

The Deadly Scenario

Factories and ports build digital twins — virtual 3D copies of physical machines. But there's always latency between the physical sensor and the virtual model.

[Physical Crane]                    [Digital Twin]
  sensor: FAULT t=14:32:01.003       status: OK t=14:32:00.500
        |                                  |
        └──── tibet-twin compares ─────────┘
              Δt = 503ms, status ≠ sync
              → BLOCK action
              → TIBET token: audit trail

If the digital twin authorizes a "move left" command while the physical crane has a fault... people die.

Install

pip install tibet-twin

Quick Start

from tibet_twin import SyncGuard, PhysicalState, TwinState

guard = SyncGuard(max_drift_ms=200)  # Port crane: max 200ms drift

# Physical crane reports: FAULT
guard.update_physical("crane-01", PhysicalState(
    device_id="crane-01",
    timestamp="2026-02-27T14:32:01.003+00:00",
    values={"position_x": 12.5, "load_kg": 2500.0},
    status="fault",
))

# Digital twin still thinks: OK
guard.update_twin("crane-01", TwinState(
    device_id="crane-01",
    timestamp="2026-02-27T14:32:00.500+00:00",
    values={"position_x": 12.5, "load_kg": 2500.0},
    status="operational",
))

decision = guard.check("crane-01", intent="move_left")
print(decision.blocked)  # True
print(decision.reason)   # "BLOCKED: status mismatch: physical=fault, twin=operational"

Demo

tibet-twin demo        # Interactive crane safety demo
tibet-twin info        # The deadly scenario explained
tibet-twin profiles    # Industry profiles with sync thresholds

Why TIBET Is Unique Here

Other synchronization systems check: "Is the data there?"

tibet-twin checks:

1. Is it the right data? (value comparison)
2. From the right device? (JIS identity)
3. At the right time? (temporal drift)
4. Does the intent match the state? (TIBET provenance)

All four must pass. One failure = BLOCK.

Industry Profiles

tibet-twin profiles --json

TIBET Provenance

Every sync decision creates a TIBET token:

The token chain is an immutable safety audit trail. When an inspector asks "was the twin in sync when the crane moved?" — the TIBET chain proves it.

Python API

from tibet_twin import SyncGuard, PhysicalState, TwinState

guard = SyncGuard(
    max_drift_ms=200,
    value_tolerances={
        "crane-01": {"position_x": 0.5, "load_kg": 100.0},
    },
)

# Update states continuously
guard.update_physical("crane-01", PhysicalState(...))
guard.update_twin("crane-01", TwinState(...))

# Check before every action
decision = guard.check("crane-01", intent="move_left")
if decision.blocked:
    handle_block(decision)
else:
    execute_action()

# Audit trail
for token in guard.export_audit():
    print(token["erin"]["details"]["reason"])

# Status
print(guard.status())
# {'checks': 150, 'allowed': 142, 'blocked': 8, 'block_rate': 5.3}

Part of the TIBET ecosystem

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 safety · Bootstrap = OSAPI-handshake naar tibet + jis (fail → snaft-rule + tibet-pol-rapport) · ← tibet-workload · tibet-pol → · 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:

See ENTERPRISE.md for details.