Kernels is a deterministic control plane for AI systems. It provides a state machine that governs AI agent execution through explicit jurisdiction, append-only audit, and fail-closed semantics.
AI systems without deterministic control planes exhibit failure modes including ambiguity propagation, non-deterministic state, unbounded execution, audit gaps, and authority diffusion. Kernels addresses these by enforcing explicit boundaries and producing immutable audit records.
No. Kernels is a control plane, not an AI framework. It does not implement AI capabilities. It governs systems that may include AI components.
No. Kernels does not call language models. It validates and arbitrates requests from systems that may use language models.
Explicit state machines provide deterministic behavior, enable audit, and prevent implicit state changes that could lead to undefined behavior.
Hash chaining provides tamper detection. If any entry is modified, the chain breaks and verification fails.
Different use cases require different enforcement postures. Variants allow operators to choose the appropriate level of strictness for their context.
Yes. Implement the Kernel protocol and extend BaseKernel. Custom variants must satisfy all core invariants.
Register the tool with the ToolRegistry:
from kernels.execution.tools import ToolRegistry
registry = ToolRegistry()
registry.register(
name="my_tool",
handler=my_function,
description="Description of my tool",
param_schema={"param1": str, "param2": int},
)Create a JurisdictionPolicy and set it on the kernel:
from kernels.jurisdiction.policy import JurisdictionPolicy
policy = JurisdictionPolicy(
allowed_actors=frozenset({"alice", "bob"}),
allowed_tools=frozenset({"echo", "add"}),
)
kernel.set_policy(policy)Use the replay verification functions:
from kernels.audit.replay import replay_and_verify
entries = ledger.to_list()
is_valid, errors = replay_and_verify(entries)In fail-closed mode (default), ambiguous requests are denied. The kernel returns a receipt with Decision.DENY and an error message describing the ambiguity.
No. HALTED is a terminal state. To continue operations, create a new kernel instance.
The ten core invariants are:
- INV-STATE: Single defined state at all times
- INV-TRANSITION: Only defined transitions occur
- INV-JURISDICTION: All requests pass jurisdiction checks
- INV-AUDIT: All transitions produce audit entries
- INV-HASH-CHAIN: Audit entries are hash-chained
- INV-FAIL-CLOSED: Ambiguity results in DENY or HALT
- INV-DETERMINISM: Identical inputs produce identical outputs
- INV-HALT: Halt is always possible and irrevocable
- INV-EVIDENCE: Decisions are exportable with verification
- INV-NO-IMPLICIT-ALLOW: Explicit ALLOW required for execution
Invariant violations indicate bugs in the kernel implementation. They should be reported as security issues.
Invariant changes require a major version bump, documented consensus, and a migration guide. They are exceptional events.
No. Kernels uses only the Python 3.11+ standard library.
The current implementation is synchronous. Async support may be added in future versions.
- Create a kernel instance with appropriate variant
- Configure jurisdiction policy
- Register any custom tools
- Submit requests through
kernel.submit() - Process receipts and handle decisions
- Export evidence for audit
Yes. Each kernel instance is independent. They do not share state.
Check the receipt's error field for details. Common causes:
- Actor not in allowed_actors
- Tool not in allowed_tools
- Missing required fields
- Ambiguous intent
- Variant-specific requirements not met
Hash chain failures indicate tampering or corruption. Verify that:
- Entries were not modified after creation
- Entries are in the correct order
- No entries were removed
Tool execution requires:
tool_callfield present in request- Tool registered in registry
- Tool in allowed_tools policy
- Valid parameters
Check the receipt for specific errors.