dynamicsystemsarchitecture.org

Kernel Taxonomy — What This Lab Actually Uses

Five real families, applied to 15 real, registered components — a working classification system, not a finished ontology. Grows as new kernels are built and classified, not before.

PurposeClassify every registered kernel by the question it actually answers, checked against real code — not a pre-imposed hierarchy.
StatusActive Development
Built fromkernel_registry.py, 15 real registered kernels
Depends on
Superseded by
EvidenceEvery kernel below is real, registered, and inspectable on the Infrastructure page.

The five families, and the question each one answers

Analysis — "What does the evidence compute to?" · 7 registered

Real, estimation-producing components: reference Kalman/baseline/ensemble filters, the HiTOP/PID-5/PPM framework readings, the schema-health formula.

Decision — "Which option should be selected?" · 1 registered

Components that choose or reconcile, rather than compute or assess. Currently: the three-framework integration's reliability-weighted reconciliation — the newest, most actively growing family.

Research — "What does the evidence imply about the maturity of this investigation, and what should happen next?" · 2 registered

research_state_kernel (classifies a work item's real stage, from Blocked through Production) and next_action_kernel (one specific recommended next step, not a menu). See these running for real in the Reasoning Chain.

Execution — "How do we carry out the chosen path?" · 2 registered

pipeline_front_gate (assembles registered kernels into a real pipeline given a task) and multi_stage_pipeline (runs alternating linear/four-channel stages with a full, traceable record of every stage's reasoning).

Observation — "What does the current evidence state actually look like, before a decision gets made?" · 3 registered

Components that measure rather than judge: real pairwise channel correlation, the 42-point exploratory floor, and evidence_completeness_observer — which computes a claim's real evidence fraction directly from verification records, replacing what used to be hand-typed input.

The actual boundary rule, not a vague description

A component belongs to whichever question it's actually answering, checked directly against its real code — not the question its name implies. This is why three_framework_integration sits in Decision, not Analysis: it doesn't compute a new estimate, it reconciles existing ones.

What this page deliberately doesn't claim

This is not a full ontology — no superclass/subclass hierarchy, no formal inputs/outputs/produces/consumes graph for every term. That fuller structure was considered and set aside directly: applying ten classification axes lab-wide before a single simpler one had proven itself would have been the less credible choice, not the more impressive one. If this taxonomy is still holding up as the codebase grows, a fuller version is the natural next step — evidenced the same way everything else on this site is, not assumed in advance.