Architecture

How TaurusX OS is structured: module boundaries, communication protocols, state management, and safety invariants.

Overview

TaurusX OS is structured around a central kernel that owns all cross-cutting concerns: routing, state synchronisation, module lifecycle, and security policy enforcement. Subsystems are isolated units that communicate through typed interfaces and emit structured events.

System Overview

Execution Flow

From user intent to physical action, every request traverses a deterministic pipeline: parse → context → plan → permissions → execute → audit.

Module Boundaries

Kernel

Central orchestrator. Owns routing, scheduling, state bus.

Context Graph

Semantic memory store. Read/write by TEE and Personas.

TEE

Task planner and executor. Dispatches to device agents.

Device Agents

Platform-specific executors. Report results to TEE.

Guardian

Intercepts and validates all action requests pre-execution.

Personas

User model manager. Reads context, writes preference state.

Design Principles

🔧
Kernel Isolation
Each subsystem runs in isolation. The kernel owns routing and state; modules never communicate directly.
📐
Typed Interfaces
All module boundaries are typed contracts. Breaking changes require explicit versioning.
🔍
Full Observability
Every action, every decision, every error is captured in structured logs and surfaced in Guardian.
🛡️
Safety by Default
The Guardian layer intercepts all actions before execution. There is no path that bypasses safety.
♻️
Stateless Execution
Task execution is stateless and idempotent where possible. State lives in the Context Graph, not in agents.
📦
Modular Deployment
Each module can be deployed, scaled, and updated independently without coordinating across the system.

Dive into the code

TEE Implementation Guardian Safety