DECISION: [ADR-007] Stdlib-Only Kernel (Zero External Dependencies)
DATE: 2026-02-18
TYPE: 1 (irreversible)
STATUS: Accepted
SOLITON SCORE: 0.90

## Context

The kernel (Ring 1) is the foundation of Orxaq. Every other ring depends on it.
External dependencies in the kernel create supply chain risk, version conflicts,
and audit complexity that propagates to all dependent code.

## Options Considered

### Option A: Use Pydantic for Types, NetworkX for DAG
Pros: Mature libraries, less code to write, community-tested.
Cons: Pydantic adds ~50 transitive dependencies. NetworkX adds ~10.
Supply chain audit scope increases 60x. Version conflicts with Ring 2+
libraries become possible. Kernel cannot be embedded standalone.

### Option B: Use dataclasses + stdlib only (selected)
Pros: Zero external dependencies. Kernel is embeddable, auditable, portable.
hashlib, secrets, dataclasses, enum, collections — all stdlib.
Audit scope: Python itself.
Cons: More code to write for validation, serialization. No Pydantic validators.

### Option C: Minimal Dependencies (just Pydantic)
Pros: Pydantic validators save code. Well-understood library.
Cons: Still ~50 transitive deps. Tight coupling to Pydantic version.

## Decision

Ring 1 (Kernel) uses only Python standard library. Zero external dependencies.

Acceleration libraries (Polars, DuckDB, scikit-learn) are deferred to Ring 2+
where their benefits justify the dependency cost.

## Rationale

The kernel is the trust root. Every dependency in the kernel is a dependency
for the entire system. stdlib-only means:
- Audit scope = CPython (peer-reviewed, CVE-tracked)
- No supply chain attacks possible in kernel
- Kernel works on any Python >=3.11 installation
- Regulatory examiners can read the code without researching third-party libraries

## Consequences

**Easier:** Audit, embed, port, trust.
**Harder:** More boilerplate for validation and serialization.
