Domain → KICE → AutoResearch → Swarm → Training

The Breadth vs Depth Tradeoff

Too Broad

"AI Engineering"

  • 3B model can't hold ML ops + training + eval + safety + deployment
  • Generic rubric probes: "explain gradient descent"
  • KICE can't target sources — what repos?
  • Swarm finds surface-level failures only

Result: shallow everywhere, expert nowhere

Sweet Spot

"Linux Kernel Engineering"

  • 10-15 subdomains with cross-cutting interactions
  • Domain-specific probes: "lock ordering in concurrent allocation"
  • KICE targets: kernel git, LKML, CVEs, docs
  • Swarm exploits subsystem interactions for deep traps

Result: reasons like a veteran engineer

Too Narrow

"Page Cache Eviction"

  • Misses cross-subsystem reasoning (VFS, memory, block)
  • Insufficient training data for 3B model
  • Swarm exhausts failure patterns quickly
  • Model becomes a lookup table, not a reasoner

Result: knows facts, can't reason

Domain Templates

Scope Statement

Deep expertise across the Linux kernel: 30+ years of commits, mailing list discussions, CVE resolutions, and subsystem evolution.

Well Balanced

Model: 3B

Good balance: 10 subdomains, 5 interactions, 4 sources.

Breadth46%
narrowbroad
Depth55%
shallowdeep
Balance91%
Sources
100%
Reasoning
100%
Failures
40%
Corpus
moderate
Training
days
Interactions
11%

Subdomains (10)

Memory Managementcritical

Page allocation, slab, OOM, cgroups, NUMA, page cache

weight: 1.3xdenseanalytical
Network Stackcritical

TCP/IP, netfilter, XDP/eBPF, sk_buff lifecycle

weight: 1.3xdenseanalytical
Concurrency Controlcritical

Spinlocks, mutexes, RCU, seqlocks, lockdep

weight: 1.4xmoderatecreative
Virtual File Systemhigh

VFS layer, inode/dentry cache, path resolution

weight: 1.1xdenseanalytical
Device Drivershigh

Driver model, DMA, interrupt handling

weight: 1xoverwhelmingprocedural
Process Schedulinghigh

CFS, RT, deadline, CPU affinity

weight: 1.2xdenseanalytical
Security Protocolshigh

LSM, SELinux, seccomp, capabilities

weight: 1.1xmoderateanalytical
File Systemsmedium

ext4, btrfs, XFS, journaling

weight: 1xdenseprocedural
IPCmedium

Pipes, shared memory, futexes, io_uring

weight: 0.9xmoderateprocedural
Power Managementmedium

cpufreq, cpuidle, suspend/resume, thermal

weight: 0.8xmoderateprocedural

Cross-Subdomain Interactions (5)

These produce the hardest reasoning problems. The adversarial swarm exploits these to design traps.

memory-managementdependencyconcurrency-controladv: 0.95

Memory allocation under lock: GFP flags and sleeping

memory-managementdependencyvfsadv: 0.85

Page cache eviction affects VFS read-ahead

concurrency-controldependencyprocess-schedulingadv: 0.90

Lock contention affects scheduling; priority inversion

device-driversdependencyconcurrency-controladv: 0.85

Interrupt vs process context locking

vfsspecializationfile-systemsadv: 0.70

VFS interface; fs implementations

Knowledge Sources (4)

git_repogit.kernel.org

30+ years of kernel commits

trust: 0.98volume: massive
mailing_listlore.kernel.org

LKML design discussions

trust: 0.9volume: massive
databasenvd.nist.gov

CVE records

trust: 0.95volume: largecovers: memory-management, network-stack, security-protocols
documentationdocs.kernel.org

Official kernel docs

trust: 0.95volume: large

Reasoning Patterns (3)

Drive CoT template generation for training data.

Trace lock acquisition order

Determine lock order, check for deadlock

identify_locks → determine_order → check_inversions → verify_lockdep → assess_risk

Cross-subsystem interaction

Trace how change in A affects B

identify_shared_data → trace_call_paths → identify_assumptions → find_breakpoints → propose_mitigation

CVE root cause analysis

Trace from CVE to root cause to fix

identify_vuln_class → trace_code_path → determine_preconditions → analyze_fix → assess_completeness

Failure Modes (3)

Drive adversarial probe generation for the swarm.

Confuse spinlock with mutex

common

Using spinlock where mutex needed (sleeping under spinlock)

Ignore NUMA topology

subtle

Assuming flat memory on NUMA systems

Misunderstand RCU grace period

expert-only

Incorrect assumptions about when RCU data can be freed

Out of Scope (2)

User-space application development

Different discipline

Linux distribution packaging

Too broad

Generated Pipeline Config Preview

KICE Sources

4

git_repo, mailing_list, database, documentation

AR Probes

~60

3 patterns + 3 failures

Swarm Traps

5

cross-subdomain interactions

Convergence Targets

3 critical

memory-management, network-stack, concurrency-control

CoT Templates (from reasoning patterns)

Trace lock acquisition order: identify_locks → determine_order → check_inversions → verify_lockdep → assess_risk
Cross-subsystem interaction: identify_shared_data → trace_call_paths → identify_assumptions → find_breakpoints → propose_mitigation
CVE root cause analysis: identify_vuln_class → trace_code_path → determine_preconditions → analyze_fix → assess_completeness

Corpus Manifest Versioning

Each KICE evolution cycle produces a new corpus-manifest version (v1.0 → v1.1 → ...). Every version records what changed, why, and which model shard it produced. The Nucleus Seal signs the final manifest — full provenance from extraction to graduation.

Learn →