KCC 03
Vocabulary
KCC makes the operating model searchable by giving recurring work, risk, and governance concepts stable names.
ArchitectureGlossaryTerminologyKernelCells
Created 2026-06-08 · v0.4.0
Vocabulary and Terminology
Precise vocabulary matters because the words encode the architecture. The model uses specific terms consistently. Synonyms are explicitly rejected because they imply different architectures and produce drift in implementation.
3.1 Core Architectural Terms
| Term | Definition | Reject these |
|---|---|---|
| Kernel | The shared contract all agents implement; the small, opinionated, slow-changing standards body | Hub, core, center, platform, controller |
| Capabilities | Versioned reusable agents in the shared catalog, governed by a maturity ladder | Modules (in prose), services, plugins, components |
| Cells | Team-owned compositions of kernel + capabilities + custom agents | Spokes, instances, teams (overloaded), projects, deployments |
| Catalog | The set of L2 and L3 capabilities available to all cells | Library, marketplace, registry, store |
| Custom Agents | Cell-local agents that are not in the shared catalog | Local capabilities, internal agents |
| Capability Family | One logical capability that declares variant axes and dispatches to stack-specific dialect variants | Mega-capability, branching capability |
| Dialect | A stack-specific variant document within a capability family | Profile, flavor, preset |
| Workspace | An optional thin composition above cells recording multi-cell / multi-repo topology; not a fourth layer | Project, monorepo, super-cell |
3.2 Agent Contract Terms
| Term | Definition |
|---|---|
| Surfaces | The nine fields of the agent contract that every agent declares |
| Surface 1: Identity | name, version, capability binding, maturity, owner |
| Surface 2: Input Schema | Structured declaration of what the agent accepts |
| Surface 3: Output Schema | Structured declaration of what the agent produces |
| Surface 4: Declared Tools | Exhaustive list of external tools, APIs, side effects |
| Surface 5: Cost Envelope | Declared resource budgets and ceilings per invocation |
| Surface 6: HITL/HOTL | Trust mode: human-in-the-loop or human-on-the-loop |
| Surface 7: Observability | Commitment to emitting structured telemetry |
| Surface 8: Confidence | Computed confidence in output, with sources and limitations |
| Surface 9: Decision Trace | Structured record of how the agent arrived at its output |
| Cognitive Layer | Surfaces 8 and 9 together — the layer that makes agent decisions observable |
| Autonomy Envelope | A pre-declared budget of conditions under which an agent may proceed without checking in |
| Escalation Gate | The universal ritual: pause, four-way choice (approve / revise / escalate / abort), record, resume |
| Confidence Gate | The three-layer separation — contract, threshold, gate |
| Calibration Loop | Comparing claimed confidence against observed outcomes to detect drift |
| Backchannel | The append-only JSON Lines reference transport for decision-trace events |
See Section 05 — The Agent Contract for the specification of each surface.
3.3 Meta-Agent Terms
| Term | Definition |
|---|---|
| Meta-agents | Agents that govern other agents; the Butler and the Token Guard |
| Butler | The meta-agent that makes per-invocation gating decisions (HITL vs HOTL) |
| Token Guard | The meta-agent that enforces cost envelopes and blast-radius limits |
| HITL | Human-in-the-loop: invocation requires human review before action |
| HOTL | Human-on-the-loop: agent acts autonomously; humans intervene only on signal |
| Gating | Deciding whether a specific invocation runs HITL or HOTL |
| Blast Radius | The maximum impact an agent's actions can have if they go wrong |
3.4 Pipeline and Maturity Terms
| Term | Definition |
|---|---|
| Inspector Pipeline | The five-stage process by which patterns mature into shared standards |
| Observe / Detect / Propose / Review / Promote | The five stages, from reading traces to entering the catalog |
| L1 (Experimental) | Active development, used by 1-2 cells |
| L2 (Proven) | Stable, in catalog, named maintainer |
| L3 (Golden Path) | Organization's recommended approach |
| Promotion | Movement of a capability up the maturity ladder |
See Section 07 — The Inspector Pipeline and Section 08 — The Maturity Ladder.
3.5 Organizational Maturity Terms
| Term | Definition |
|---|---|
| Phase 1 (Adoption) | AI assists humans; per-individual gains |
| Phase 2 (Maturing) | SDLC restructured; per-team gains compound within team |
| Phase 3 (AI-Native) | Agents are first-class; gains compound across teams |
| Phase Ceiling | The metric that defines what each phase can and cannot deliver |
| Phase Transition | Movement between phases; the 2-to-3 transition is the hardest |
See Section 09 — The Phase Model.
3.6 Special Concern Terms
| Term | Definition |
|---|---|
| Lethal Trifecta | Untrusted content + private data + external communication |
| Workslop | Content that passes automated gates but provides no real value |
| Bypass | Engineers routing around the sanctioned platform |
| Attention Budget | The finite human cognitive capacity for review work |
| Context Efficiency | The proportion of context window available for working space |
| Functional Verification | The unsolved problem of proving agent outputs are correct |
| Environment Mutation Boundary | The line between observing the environment and mutating the host |
See Section 10 — Special Concerns.
3.7 Operational Terms
| Term | Definition |
|---|---|
| Kernel Maintainer | Member of the 3-7 person group that owns the kernel |
| Capability Maintainer | Named individual responsible for a specific capability |
| Cell Owner | The team or its representative (engineering manager or tech lead) |
| Inspector Operator | The 1-3 named individuals operating the Inspector Pipeline |
| ADR | Architectural Decision Record; the standard format for kernel-level decisions |
| Sunset Date | The date by which a deprecated capability or declared exception must be resolved |
See Section 12 — Operational Layer.
3.8 Work Lifecycle Terms
| Term | Definition |
|---|---|
| Work Lifecycle | Idea → Spec → Plan → Implement → Verify → Review, the path a unit of work travels in a cell |
| Solution Onboarding | The optional brownfield prelude producing a read-only baseline of an existing codebase |
| Epic / Story / Enabler | A spec; a user-visible slice of value; foundational work with no direct user value |
| Wave | A parallelization plan declaring which stories/enablers run in parallel |
| Deploy Stage | The optional postlude after Review; gated and never auto-executed |
See Section 12.6 — The Work Lifecycle.
3.9 The Canonical Phrasings
One kernel. Many capabilities. Many cells. The kernel doesn't run the cells. It defines the contract they all honor. Three layers. Three owners. Three change cadences. Observe. Detect. Propose. Review. Promote. Trust is behavior, not title. Boring engineering is what keeps you sleeping at night.