Skip to main content
OdinLabs
Pricing
  • Pricing

No credit card required

Built in the Netherlands • Start free

OdinLabs

ODIN is AI you own. Deploy on your infrastructure, turn chaos into structured gold, and scale your organization like a beehive. Built by Odin Labs in the Netherlands.

Product

  • How It Works
  • Use Cases
  • Pricing
  • Product

Company

  • About Us
  • Contact
  • Partners
  • Blog

Resources

  • Documentation
  • Integrations
  • Compare Tools
  • Security

Legal

  • Privacy Policy
  • Terms of Service
  • Cookie Policy

© 2026 Odin Labs Projects B.V. All rights reserved.

ODIN (Omni-Domain Intelligence Network) is an intelligence system developed by Odin Labs.

Intent-Driven Architecture

From Intent to Governed Output

In ODIN (Omni-Domain Intelligence Network), every user intent flows through the Router Kernel, gets classified with confidence scoring, routes to specialized hubs, and produces governed memory writes with full audit trail. No black boxes, complete traceability.

No credit card required

The ODIN Flow

Intent-driven orchestration with governance at every step

01

User Intent

Voice, text, or work order

Every interaction starts with intent. Voice via Assistant Hub (local-first with Whisper.cpp), text via Command Center, or structured work orders. Intent can be a question, a task, or a decision that needs context.

  • "Why did we choose JWT over sessions?"
  • "Score this decision for bottleneck risk"
  • "Create an onboarding track for new devs"

Step 01

User Intent

02

Router Kernel

Intent classification & confidence scoring

The Router Kernel classifies intent, scores confidence, and determines which hub(s) should handle it. Priority rules apply: Legal can veto Sales promises. Sentinel can gate risky dependencies. Compass can require justification for RED decisions.

  • Intent classification with scoring
  • Hub routing with priority rules
  • Conflict resolution between hubs

Step 02

Router Kernel

03

Hub Processing

Specialized engine execution

Six specialized hubs, each with a single responsibility. Compass scores decisions. Academy generates training. Assistant captures context. Sentinel gates dependencies. Legal handles governance. Coding executes work orders. Hubs don't leak responsibilities.

  • Compass: Decision Brief (1 page max)
  • Academy: Curriculum + lesson plans
  • Coding: WO → SO → T hierarchy

Step 03

Hub Processing

04

Governed Output

Audit events + memory writes

Every hub output includes mandatory audit events and governed memory writes. Each memory write requires rationale (why this exists), ownership (who can change it), and dependencies (what relies on it). No silent changes.

  • 11 audit event types
  • Rationale + ownership + dependencies
  • Risk flags for governance violations

Step 04

Governed Output

05

BrainDB

Memory as governance

Memory is not optional. Memory is governance. Seven namespaces from global identity to session memory. Every write is queryable forever. The complete decision log, assumptions record, and audit trail live here.

  • brain/global/* - Identity, mission
  • brain/decisions/* - Decision log
  • brain/audit/* - Immutable audit trail

Step 05

BrainDB

Under the Hood

The technical architecture that makes governance-first operations possible

Work Order InputTask OrchestratorAgent PoolGuardian DaemonVerified Output
Data Flow
Active Transfer
Click to expand
Data Flow

Work Order System

Work Order

Your high-level goal becomes a structured work order with objectives, constraints, and success criteria. Describe it once, get it done.

1

Sub-Work Orders

Complex work orders decompose into smaller, focused sub-work orders that can execute independently. Each tracked with full context.

2

Atomic Tasks

Each sub-work order breaks into atomic tasks, the smallest unit of work. Every task traceable back to its source.

3

Priority Rules & Conflict Resolution

When multiple hubs respond, priority rules apply. Legal Hub can veto Sales promises. Sentinel Hub can gate risky dependencies. Compass Hub can require justification for RED decisions. Conflicts are resolved, not hidden.

  • Legal veto capability
  • Sentinel dependency gating
  • Compass justification requirements

See the Architecture in Action

Watch how intent flows through Router, Hub, and BrainDB

Architecture Demo

Intent → Router → Hub → BrainDB

Coming Soon

6

Hub Engines

11

Audit Events

31

Core Packages

Explore the Architecture

Understand how intent flows through the system and how governance is enforced at every step.

Your First Work Order
bash

Work Order Examples

See how ODIN transforms your requirements into production-ready code with full traceability

Basic Work Order.json
JSON
1{
2 "id": "wo-auth-jwt",
3 "objective": "Add JWT authentication to the Express API",
4 "requirements": [
5 "Implement JWT token generation on login",
6 "Add token verification middleware",
7 "Support refresh token rotation"
8 ],
9 "constraints": {
10 "noBreakingChanges": true,
11 "targetFiles": ["src/auth/**", "src/middleware/**"],
12 "testCoverage": ">90%"
13 },
14 "successCriteria": [
15 "All existing tests pass",
16 "New auth tests achieve 90%+ coverage",
17 "Security audit passes"
18 ]
19}

Frequently Asked Questions

Understanding the ODIN architecture and governance model

A chatbot is a conversational interface. ODIN is infrastructure. It has six specialized hubs with strict contracts, governance-aware memory (BrainDB), and complete audit trails. Every output includes rationale, ownership, and dependencies. It's designed to be left behind: transferable, documentable, operable by others.

"If ODIN depends on the founder to function, ODIN isn't done yet." Everything must be transferable, documentable (not explainable), and operable by others without quality degradation. This is how we measure if ODIN is ready: not features, but independence.

Compass Hub scores every decision by whether it increases or decreases dependency on the founder. GREEN = reduces dependency (proceed). YELLOW = neutral (document and proceed). RED = increases dependency (requires explicit justification). This prevents bottleneck accumulation.

Local-first by default. Assistant Hub uses Whisper.cpp for speech-to-text and Ollama for LLM, both run locally. Cloud is optional with explicit opt-in only. No background processing without consent. Every capture creates an audit event with full provenance.

router.route (intent classification), hub.process (hub execution), memory.write/read, approval.request/grant/deny, assistant.capture (voice/text), sentinel.scan/block/allow. Every event includes correlation IDs, session attribution, and risk flags. Queryable forever.

Ready to Build Transferable Operations?

Let's talk about how ODIN can capture your organization's context and prevent the bottleneck problem.

Setup in under 2 minutes

Built in the Netherlands • Free forever for small teams