An AI orchestration control plane for human-governed autonomous execution.
Nexus is not a chatbot, not a Discord bot, and not a wrapper around an LLM. It's a deterministic, auditable orchestration system that centralizes what's normally scattered across a chat tool, a task tracker, and a terminal with no audit trail — so one operator can delegate work, approve privileged actions, run agents against allow-listed repositories, and keep a complete, recoverable record, all under continuous human governance.
The core philosophy is stated as four rules the system is built to enforce, not just aspire to: AI should assist execution, not control it. Human governance remains the final authority. All execution paths must remain observable, auditable, and interruptible. Determinism over cleverness — routing and workflows are rule-based, not LLM-dependent, wherever a rule can do the job.
Conversation is a feature. Orchestration is the product. Every governed execution passes an un-bypassable, database-backed approval gate and an 11-gate runtime governance layer before it's allowed to touch the world, and every decision is written to an immutable, event-sourced audit log that survives restarts.
Requests flow downward through five layers, each one auditable and interruptible on its own.
Discord and email today (WhatsApp and Slack are planned) — where an operator issues commands and receives approvals.
Normalizes and routes every inbound event through a transactional outbox, so nothing is lost between systems.
The Task Engine, the Approval Engine, Runtime Governance, and the Workflow Orchestrator — the decision-making center.
Event-sourced memory with checkpoint replay; an APScheduler running 6 audited jobs; an OpenRouter-backed intelligence layer for model routing.
A Runtime Registry over Gemini, Claude, and Nexus adapters, gated by an 11-gate governance layer that authorizes every run.
Owner authorization fails closed.
As of v1.0.1, if no Discord owner IDs are configured, the application refuses to start — not a warning, not a degraded mode. The convenient default (run anyway) was explicitly rejected.
Rejected —Starting in a permissive default state when governance config is incomplete.
An un-bypassable, database-backed approval gate.
Every governed execution passes a DB-backed workflow with a full audit trail, not an in-memory or best-effort approval check that wouldn't survive a restart.
The execution sandbox is default-secure and fails closed.
With sandboxing disabled or an unrecognized provider, the manager refuses to execute rather than silently running on the host. Docker availability is probed at boot; startup aborts on an incoherent config. Container isolation is opt-in, but the fallback is refusal, not a silent downgrade.
Honest status reporting over marketing the roadmap.
The Gemini and Claude runtime adapters are documented plainly as governed generic shell runners, not yet real CLI integrations — while the governance abstraction and registry around them are called production-quality. The two are not conflated.
SQLite first, with a documented PostgreSQL path — not a blocking migration.
Shipping v1.0 on SQLite (WAL mode) meant not gating a working release on a distributed-database migration. The Alembic path is scaffolded but explicitly not yet authoritative; create_all remains the current schema source until it is.
- Released as v1.0.0 ("Operational Intelligence"), now on the v1.0.1 "Alignment" correctness/safety pass
- 21 Architectural Decision Records document the reasoning behind the system as it stands today
- 6 audited scheduler jobs: research collection, daily briefing, approval-expiry sweep, metrics aggregation, and two read-only health checks
- CI: GitHub Actions, ruff, and mypy in strict mode on every push
Pilot-ready as an attended, single-operator governed-execution console, with a now-operational single-node autonomy layer — status tracked candidly per subsystem rather than claimed wholesale.