How Kaidera OS works

Local topology

Kaidera OS runs as a local control plane. The operator uses the console, the console talks to Cortex and the app database, and workers run through configured harnesses against the selected project workspace.

Core services

The console is a web application served locally. Cortex is the memory backend. The app database stores settings and operational state. Harnesses execute model-backed or deterministic work on behalf of configured workers.

• Console: local operator UI for Dashboard, workers, Dispatch, Runs, Settings, and Help.
• Cortex API: memory, project context, registry, handoffs, and evidence.
• App database: settings, local overrides, autonomy flags, and run state.
• Harness layer: local or remote execution path for model-backed workers and deterministic jobs.

Ports and local services

The standard local console address is http://localhost:8765. Cortex and the app database run as local services, commonly on separate ports. Operators should use Settings and health checks instead of guessing which layer is failing.

Run-state streaming

When a worker runs, the console streams state so operators can see progress, logs, decisions, and failure points. This is the live operational surface behind Dispatch and Runs.

Extension boundary

Project-specific behavior should load through project data, project packs, or explicit extension modules. The core product should stay clean, reusable, and project-agnostic so updates do not require customer-specific forks.

Desktop and headless shapes

The same control-plane idea can run as a local browser console, a native-wrapped desktop app, or a headless service on a controlled VM. The security and networking posture should match the deployment shape.

Update design

The update path is designed to replace the application package while preserving Cortex data, app database state, and project files. This keeps routine updates separate from customer workspaces and long-lived memory.