Event ledger

The event ledger is the durable runtime spine behind runs and the seven Labs. Each remote-host tenant receives an independent state root and ledger.

Storage model

The SQLite database uses foreign keys, write-ahead logging, and versioned migrations. Its core concepts are:

• runs — objective, status, model/provider, workspace, and feature gates;
• run steps — ordered tool boundaries with input and output artifact references;
• ledger events — append-only per-run events with a previous-hash link;
• artifacts — metadata for content-addressed evidence stored outside SQLite.

Large or sensitive values are redacted before persistence. Tool input and output can be stored as bounded content-addressed artifacts rather than embedded in rows.

Event integrity

Every event includes a run-local sequence, time, payload, previous hash, and SHA-256 hash over a canonical envelope.

Verify a run:

odinn run verify <run-id>

This detects a broken event chain. The ledger is not a blockchain, remote replication system, or tamper-proof store against an attacker who controls the state directory.

Tool interception

The runtime records a tool request before policy evaluation, persists the policy decision, and records the tool result after execution. Unknown tools receive the restrictive safety descriptor.

Built-in tools and extension or MCP adapters must cross this boundary. Direct extension execution is rejected.

Feature gates

Each run records the seven experimental flags as explicit booleans: Proof, Rewind, Sentinel, Capsules, Darwin, Capabilities, and Counterfactuals. They are false by default and cannot be inferred from model output.

Automatic improvements is configured separately.

For local files, see State layout. For product limitations, see Known limits.