TPT Tektos

The Universal Cyber-Physical Engine.

We treat atoms the way Git treats bits.

TPT Tektos is an open-source, Rust-based Infrastructure-as-Code (IaC) and edge-native orchestration platform for the physical world. Just as Kubernetes abstracted compute and Docker abstracted applications, Tektos abstracts physical reality. Whether you are purifying water, routing electrons in a microgrid, or steering a robotic arm, Tektos gives you the type-safe, zero-cost, declarative engine to control physical hardware at scale.

You declare a desired physical state in a Git-versioned manifest. Tektos continuously reconciles the physical world to match the code — ensuring optimal efficiency, absolute safety, and zero configuration drift.

Status: Phase 1 complete — the universal core reconciles a generic, simulated "dummy" physical plant end-to-end. Flagship domains (water, energy, robotics) are scaffolded and land in later phases. See DESIGN.md for the architecture and todo.md for the roadmap.

Philosophy

Physical infrastructure is broken: siloed SCADA, manual PLC calibration, vendor lock-in, reactive maintenance. Tektos fixes this by treating physical dynamics as declarative code. The engine is domain-agnostic — it understands only four primitives:

Sensors (inputs) — measured quantities from the world.
State (telemetry) — the current physical condition.
Logic (reconciliation) — the loop that drives toward desired state.
Actuators (outputs) — things that move, open, spin, charge.

Specific physics and hardware drivers live behind Domain Plugins, so the core stays lightweight and universally applicable.

Architecture

tpt-tektos/
├── core/                      # THE UNIVERSAL ENGINE (domain-agnostic)
│   ├── tektos-engine/         # IaC reconciler, lifecycle state machine, gRPC control plane
│   ├── tektos-edge/           # Edge daemon: heartbeat, driver loader, safe-state fallback
│   ├── tektos-telemetry/      # Zero-copy time-series sample format + ring buffer
│   ├── tektos-iac-core/       # Kubernetes-style manifest schemas + bounds checking
│   └── tektos-cli/            # The universal CLI (`tektos apply|plan|status|validate`)
├── domains/                   # DOMAIN PLUGINS (the "providers")
│   ├── tektos-osmos/          # 🌊 Water, desalination, HVAC (flagship)
│   ├── tektos-volta/          # ⚡ Energy: microgrids, inverters, BESS
│   ├── tektos-kinetic/        # 🦾 Robotics: CNC, robotic arms
│   ├── tektos-flora/          # 🌱 AgTech: greenhouses, irrigation
│   └── tektos-charge/         # 🔋 EV: charging, grid load balancing
├── sdk/
│   └── tektos-plugin-sdk/     # Rust traits + macros for building domain plugins
└── examples/                  # Sample manifests (dummy-plant.yaml, volta.yaml, …)

See DESIGN.md for the reconciliation loop, the lifecycle state machine, the gRPC contract, and the digital-twin approach.

Quick start

# Build everything
cargo build --workspace

# Validate a manifest's syntax and physical bounds
tektos validate -f examples/dummy-plant.yaml
# ✅ Manifest 'dummy-plant-01' is valid.
# ✅ Physical bounds check passed.

# Preview the desired-vs-actual plan + digital-twin prediction
tektos plan -f examples/dummy-plant.yaml -p osmos
# 📋 Plan for 'dummy-plant-01':
#    -> set valve-01 = 45 %
#    -> set pump-01 = 52 Hz
# 🌊 osmos digital-twin simulation:
#    -> predicted pressure = 23.40
#    -> predicted flow = 195.00
#    -> predicted temp = 296.60
#    -> predicted fouling = 0.00

# Apply the manifest to the (mock) edge gateway
tektos apply -f examples/dummy-plant.yaml
# 🔄 Syncing state to edge gateway 'dummy-plant'...
#    -> valve-01 = 45 %
#    -> pump-01 = 52 Hz
# ✅ Physical state reconciled.

# Watch live status — the Dead Man's Switch is armed
tektos status --watch -f examples/dummy-plant.yaml

tektos plugins lists registered domain plugins; the mock dummy gateway is registered by default so everything runs without hardware.

The developer experience

# 1. Validate syntax and physical bounds
$ tektos validate -f ro_plant.yaml
✅ Manifest is valid.
✅ Physical bounds check passed (Pressure < 60 bar, Flow < 500 L/h).

# 2. Simulate the Digital Twin to see what will happen
$ tektos plan -f ro_plant.yaml
🌊 tektos-osmos twin simulation running...
  -> Permeate flow will increase by 12%.
  -> Membrane fouling risk remains nominal.
  -> Energy consumption will shift to off-peak grid hours.
Plan complete. 3 physical state changes queued.

# 3. Apply the code to the physical plant
$ tektos apply -f ro_plant.yaml
🔄 Syncing state to edge-gateway-01...
  -> Adjusting VFD-04 frequency: 45Hz -> 52Hz
  -> Opening proportional valve PV-02: 30% -> 45%
✅ Physical state reconciled.

# 4. Check live telemetry and physical state
$ tektos status --watch
NAME            STATUS      FLOW (L/h)   PRESSURE (bar)   TEMP (K)
ro-plant-01     Reconciled  485.2        42.1             294.5

Safety, security & edge constraints

Physical infrastructure cannot tolerate software crashes. Tektos enforces strict safety boundaries across all domains:

Dead Man's Switch. The edge runtime runs on a strict heartbeat. If it loses connection to the cloud, or a task panics, the domain plugin instantly drives actuators to a pre-defined Safe State (e.g. closing a high-pressure valve).
Bounds checking in IaC. Domain crates enforce physical limits at parse time — you cannot write a manifest requesting a robot to exceed its joint limits, or a battery to charge past 100% SoC. The type system + validator prevent invalid physical states.
mTLS everywhere (Phase 3). All edge↔control-plane communication uses mutual TLS with automated certificate rotation.
Zero-cost edge execution. Control loops run directly on cheap ARM gateways under tokio; Rust's zero-cost abstractions and lack of a GC give deterministic, microsecond-level latency.

Writing a domain plugin

use tektos_plugin_sdk::{GenericPlugin, tektos_plugin, tektos_conformance_tests};
use tektos_iac_core::Bounds;
use async_trait::async_trait;

// Build a GenericPlugin, register it, and prove it via conformance tests.
tektos_plugin!("my-domain", || Box::new(my_plugin()));
tektos_conformance_tests!(|| Box::new(my_plugin()));

A plugin that passes the conformance suite earns the "Tektos Certified" badge. See sdk/tektos-plugin-sdk.

Technology stack

Concern	Choice
Language	Rust (Edition 2024)
Async runtime	`tokio` (cloud/standard edge), `embassy` (`no_std` MCU, planned)
Serialization	`serde` + `serde_yaml` (manifests), FlatBuffers (edge telemetry, planned)
Networking	`tonic` (gRPC), `rumqttd` (MQTT, planned), `tokio-modbus`/`opcua` (drivers, planned)
Storage	`redb` (embedded edge state, planned), TimescaleDB/QuestDB (cloud, planned)

Licensing

TPT Tektos is dual-licensed under MIT and Apache-2.0, exactly like the Rust language itself. Pick whichever is more convenient for your use case.

MIT — NGOs, municipalities, and hobbyists can build resilient physical infrastructure freely.
Apache-2.0 — industry can integrate Tektos into proprietary SCADA offerings without legal friction.

Roadmap

Phase 1 — The Universal Core (done): Cargo workspace, dual licenses, the core engine, the plugin SDK, and the mock edge gateway. Milestone: the core reconciles a simulated dummy plant.
Phase 2 — Flagship Domain tektos-osmos (mostly done): digital twin, fluid-dynamics + fouling model, energy-aware load shifting, and tektos plan twin wiring. Modbus/OPC-UA drivers, redb edge state and the physical test-rig milestone remain.
Phase 3 — Cloud Control Plane & Telemetry (mostly done): multi-site Fleet gRPC control plane, tektos-telemetry ingestion path, and domain twins are implemented. Cloud TSDB storage, mTLS transport and MQTT still need external services.
Phase 4 — Ecosystem Expansion (in progress): the SDK conformance suite backs "Tektos Certified"; volta, kinetic, flora and charge are seeded/stubbed and bundled into the CLI (examples/*.yaml). crates.io publish, hardware blueprints, embassy no_std and v1.0.0 remain.

Full checklist in todo.md.

tpt-tektos

Languages