OS Backend / Kernel

The TaurusX OS Backend is the kernel layer — a set of server-side services that handle routing, execution, safety enforcement, billing, and session management for all four surfaces.

The backend is a Next.js App Router API layer backed by PostgreSQL (via Drizzle ORM), with in-memory caches for hot paths and async workers for long-running tasks. Every surface — mobile, desktop, terminal, and CLI — communicates with the same set of API routes.

The Routing Engine is the most important subsystem in the TaurusX kernel. It receives every incoming message and determines:

1. Which engine to use (based on message complexity, plan tier, and user preference)
2. Which conversation state applies (based on message content and session history)
3. Which tone variant to apply (based on state, accessibility flags, and prior interactions)
4. Whether the message requires a Guardian policy check before response
5. Whether to invoke the Meta-Agent for planning before responding

Routing happens in under 50ms for standard messages. Complex routing decisions (meta-agent activation, Guardian escalation) add additional latency but are non-blocking from the user's perspective — a partial response begins streaming while routing completes.

TaurusX uses a six-state machine to classify every message exchange. The active state determines the response strategy — how detailed, how warm, how directive, and how fast.

State transitions happen automatically between messages. A conversation can move from Casual to Technical to Supportive within the same session. See the State Machine guide for full transition rules.

The tone model translates an active state into a specific communication style. Tone is applied at the prompt level — it shapes how the engine structures its response before any text is generated.

Tone variants available in TaurusX v1.0:

• Warm — conversational, friendly, no jargon
• Precise — clear, no filler, information-dense
• Gentle — slow, non-urgent, affirming (Supportive state)
• Technical — structured, code-preferred, reference-quality
• Directive — action-focused, step-by-step (Executive state)
• Neutral — factual, no emotional charge (Guardian state)

Full documentation is in the Tone & Accessibility guide.

The TaurusX kernel wraps all AI model calls behind an internal engine abstraction layer. No surface ever calls an AI provider directly — all calls go through the kernel's engine router.

This abstraction provides:

• Model-agnostic routing (swap providers without changing surface code)
• Consistent token usage and billing across all surfaces
• Fallback chains — if the primary engine is unavailable, the kernel reroutes automatically
• Plan-tier enforcement — free plan users cannot access enterprise-tier engines

See the full Engine Abstraction Layer guide.

The kernel is structured as a set of layered services, each independently deployable:

Guardian is not a separate service — it is woven into every layer of the kernel. Every action that leaves the kernel (agent runs, workflow triggers, API calls, data writes) passes through the Guardian policy evaluation pipeline.

The Guardian pipeline has five stages:

1. Intent validation — semantic analysis of what the action is trying to do
2. Permission check — RBAC evaluation against the user's role and plan
3. Risk classification — scoring from 0 (safe) to 10 (blocked)
4. Circuit breaker check — rate and pattern-based anomaly detection
5. Audit write — immutable log entry regardless of outcome

The Guardian audit log is available in the Continuum interface under Governance → Audit.