Introduction to CKP v3.7
Purpose
The Concept Kernel Protocol (CKP) v3.7 governs how a Concept Kernel exists, wakes into being, executes its purpose, and accumulates knowledge. It is the complete specification for building, deploying, and operating concept kernels in a distributed system.
A Concept Kernel is a persistently-identified computational entity -- a Material Entity in the sense of BFO 2020 -- that possesses three independently-versioned loops (CK, TOOL, DATA), communicates over a message broker, and accumulates knowledge through sealed, provenance-tracked instances. CKP defines the rules by which these entities are created, composed, governed, and evolved.
Why CKP Exists
CKP gives every computational entity an ontological identity -- a typed place in a graph of meaning. From that identity, computational capability scaffolds upward: a kernel's connections to other kernels and concepts, the constraints it satisfies, and the governance it operates under collectively shape what it does and how the fleet behaves.
CKP defines this for every computational unit by treating it as a Material Entity with:
- Ontological identity -- each kernel inhabits a typed graph of meaning. Its identity is the URN, BFO classification, declared edges to other kernels, capability advertisement, and governance posture taken together. The GUID is one attribute among these; the identity itself is the kernel's curated position in its ontological universe.
- Computational capability scaffolded by ontology -- LinkML-typed schemas (
ontology.yaml) generate the kernel's Pydantic types, SHACL constraints, and RDF triples. What the kernel can produce, what writes it accepts, and what other kernels it can compose with all derive from this curated ontology. - Formal typing -- grounded in BFO 2020 (ISO 21838-2), the same upper ontology used in biomedical informatics, defence, and manufacturing.
- Three-loop separation -- identity (CK), capability (TOOL), and knowledge (DATA) are physically isolated, independently versioned, and governed by distinct write authorities.
- Forward-acting governance -- enforcement (SHACL validation, grants, edge predicates) shapes runtime behaviour: writes that violate the kernel's typed contracts are rejected at the boundary, and edges declared in the ontology determine which inter-kernel actions are reachable. Governance is an active part of execution, not a retrospective audit.
- Mandatory provenance -- every instance links to the action, agent, and time that created it via W3C PROV-O.
- Message-native communication -- all inter-kernel interaction occurs over NATS messaging with JWT authentication.
Each kernel can answer: Who am I? What types do I produce? What constraints bind me? What can I compose with? What have I produced, and under whose authority?
Scope
This specification covers:
- The formal typing of concept kernels in BFO 2020
- The three-loop architecture (CK/TOOL/DATA) with independent versioning
- The four-layer ontology import chain and published OWL modules
- The awakening sequence and identity model
- NATS-based messaging with JWT authentication
- Action types, edge predicates, and composition
- Instance lifecycle with PROV-O provenance
- The unified filesystem tree and volume layout
- Compliance checking and fleet validation
- Kubernetes materialisation via CK.Operator
- Dynamic kernel spawning and occurrent tracking
This specification does not cover:
- Kubernetes-specific resource definitions (implementation artifacts of CK.Operator)
- LLM integration details (per-kernel tool concerns)
- UI/UX requirements (client concerns)
The Three Loops -- Overview
The Three Loops are not separate subsystems. They are three modes of being of the same Material Entity -- each loop a different answer to a different existential question. The CK loop asks who it is and why it exists. The TOOL loop is the executable capability the kernel brings to the world. The DATA loop is everything the kernel has produced and come to know. The loops exist in a deliberate dependency order: DATA is the purpose; TOOL exists to serve DATA; the CK loop exists to define and sustain both.
| Loop | Existential Question | Filesystem Volume | Git Versioning | Write Authority |
|---|---|---|---|---|
| CK | Who am I and why am I? | ck-{guid}-ck | Developer commits -- permanent | Operator / CI pipeline |
| TOOL | What can I do? | ck-{guid}-tool | Tool author commits -- permanent | Tool developer / CI pipeline |
| DATA | What have I produced? | ck-{guid}-storage | Append-only -- archival | Kernel runtime only |
The Eight Design Principles
CKP is built on eight design principles. Every normative requirement in the specification traces to one or more of these principles. Implementations that satisfy the letter of individual requirements but violate these principles are not conformant in spirit.
1. Ontology-Driven
If it is not in the ontology, it does not exist. Every entity, relationship, and process MUST be formally typed in the four-layer ontology stack. This ensures that CKP systems are machine-interpretable, not merely machine-executable.
2. Three-Loop Separation
CK loop (identity) is ReadOnly. TOOL loop (capability) is ReadOnly. DATA loop (knowledge) is the only writable surface. This MUST be enforced at volume mount level, not by convention. The rationale is security through architecture: a compromised runtime process cannot alter its own identity or code.
3. NATS-Native
All inter-kernel communication MUST use NATS messaging. HTTP is for static web surfaces only. This ensures a uniform communication fabric with built-in publish/subscribe semantics, JetStream durability, and JWT-based access control.
4. Version-Pinned
Containers SHALL see only the versions declared in the CK.Project CR (spec.versions). No arbitrary version access. This prevents version drift and ensures reproducible behaviour across the fleet. Version state lives in the Kubernetes control plane, not on the filesystem.
5. Provenance-Mandatory
Every instance MUST include PROV-O fields linking to the action, agent, and time that created it. This makes audit trails a first-class architectural concern, not an afterthought.
6. Idempotent
Reprocessing the same input SHOULD produce the same output. Instances are write-once sealed. This enables safe retries and simplifies failure recovery.
7. Filesystem-First
The distributed filesystem is the primary store. No external database is REQUIRED for core CKP operations. This keeps the system self-contained and portable.
8. Sovereignty
Each kernel's volumes are sovereign. No kernel MAY write to another kernel's CK or TOOL volume. Cross-kernel data access is governed by SPIFFE grants, not implicit trust.
Protocol Feature Status
The following table summarises the implementation status of major protocol features.
| Feature | Status | Notes |
|---|---|---|
| Three-loop separation (volume-enforced) | Implemented | CK.Operator materialises ReadOnly PVCs |
Six-step ontological awakening sequence (conceptkernel.yaml, ontology.yaml, cktype/, rules.shacl, SPIFFE) | Implemented | CK.Lib.Py, CK.Lib.Js |
| PROV-O provenance in instances | Implemented | MUST -- all instances |
| NATS topic topology | Implemented | 22 topics across three loops |
| SPIFFE workload identity | Implemented | SPIRE integration |
| Capability advertisement | Implemented | spec.actions + capability: block |
| Five edge predicates | Implemented | COMPOSES, EXTENDS, TRIGGERS, PRODUCES, LOOPS_WITH |
| Seven action types | Implemented | inspect, check, mutate, operate, query, deploy, transfer |
| SHACL validation pipeline | Partial | Permissive stub mode is current default |
| Audience profile accumulation | Future | Designed but not implemented |
| SHACL reactive business rules | Future | Stubs only |
| ValueFlows economic events | Future | Designed but not implemented |
| Full ODRL policy composition | Future | Grants block implements subset |
| Database-backed DL boxes | Future | Filesystem is current physical layer |
Specification Structure
CKP v3.7 is organised into nine parts:
| Part | Scope |
|---|---|
| I | Foundations: purpose, conformance, terminology, namespaces, design principles |
| II | The Three Loops: CK identity, TOOL capability, DATA knowledge, system integration |
| III | Ontology: BFO 2020 grounding, four-layer model, published modules, SHACL |
| IV | Messaging: NATS transport and topics, message envelope |
| V | Security: loop isolation, authentication, namespace security |
| VI | Edges & Composition: edge predicates, EXTENDS |
| VII | System Kernels: taxonomy, CK.Compliance, CK.Operator, CK.Project & Libraries |
| VIII | Infrastructure: ConceptKernel + CKProject CRDs, evidence-based proof, reconciliation, versioning |
| IX | Governance & Accumulation: CK.Consensus, task engine, ontological graph, sessions, PROV-O provenance |
What v3.7 Provides
v3.7 is the operational specification. It defines how a concept kernel is materialised, governed, authenticated, and reconciled across the fleet. The operator, auth, CRDs, reconciliation lifecycle, consensus loop, and graph store are all part of this surface — together they take an ontology declaration and turn it into running, governed compute.
| Concern | v3.5 (Foundation) | v3.7 (Runtime) |
|---|---|---|
| Identity | conceptkernel.yaml, awakening sequence | ConceptKernel CRD -- kubectl get ck |
| Authentication | (not addressed) | AuthConfig ontology, Keycloak provisioning |
| User interface | (not addressed) | Three-panel web shell, action discovery |
| Developer workflow | (not addressed) | /ck Operator -- subagent with kernel identity |
| LLM integration | (not addressed) | EXTENDS predicate, persona mounting, streaming |
| Governance | STRICT/RELAXED/AUTONOMOUS modes | CK.Consensus -- propose/evaluate/approve loop |
| Knowledge graph | Ontology declared in Turtle | Jena Fuseki /ckp dataset, SPARQL-queryable fleet |
| Proof | Defined in spec | 15-check evidence-based verification, SHA-256 hashed |
| Logging | (not specified) | Structured JSON stdout, stream.{kernel} topic |
What v3.7 Adds: The Operational Stack
v3.7 builds five layers of operational capability on top of the v3.5 foundation:
Each layer depends on the layers below it. Auth needs the operator. EXTENDS needs auth (so capability invocations carry identity). Consensus uses EXTENDS to delegate proposal review to a capability provider. The graph materialises only after the full fleet is reconcilable.
Known Implementations
| Implementation | Language | Scope | Package |
|---|---|---|---|
conceptkernel | Python | Full runtime library (CK.Lib.Py) | PyPI |
@conceptkernel/cklib | JavaScript | Browser client library (CK.Lib.Js) | npm |
| CK.Operator | Python/Kubernetes | Kubernetes materialiser | Internal |
| CK.Compliance | Python | Fleet validator | Internal |
This specification is the authoritative reference for all implementations. Where an implementation diverges from this specification, the specification is normative.
Cluster State After v3.7
The reference deployment (delvinator.tech.games + hello.tech.games) demonstrates the full stack:
| Component | State | Evidence |
|---|---|---|
| CK.Operator | Running in ck-system namespace | kubectl get deploy -n ck-system |
| ConceptKernel CRD | Installed | kubectl get ck -A shows 7 kernels |
| Delvinator fleet | 6 kernels, 15/15 checks each | kubectl get ck -n ck-delvinator |
| Hello.Greeter | 1 kernel, 15/15 checks | kubectl get ck -n ck-hello |
| Keycloak realms | techgames (reused), hello (created) | OIDC discovery 200 on both |
| Web shell | Live at both hostnames | curl -sI https://delvinator.tech.games/cklib/console.html |
| NATS | Connected, structured JSON logs | kubectl logs on any processor |
| Jena Fuseki | /ckp dataset, 2,797 triples | jena.conceptkernel.dev/ckp/sparql |
Reading This Documentation
The v3.7 docs are organized by capability, not by version number. Each page explains:
- WHY the capability exists (the problem it solves)
- HOW it works architecturally (the design decisions)
- WHAT was actually deployed (the evidence)
| Page | Covers |
|---|---|
| Conformance & Terminology | RFC 2119 keywords, conformance levels, glossary of defined terms |
| Namespaces | 13 namespace prefixes and their URIs |
| CK Loop | Awakening sequence, identity document, NATS topics |
| TOOL Loop | Tool forms, storage contract, SHACL validation |
| DATA Loop | Instance tree, PROV-O provenance, mutation policy |
| Three Loops | Dependency order, separation axiom, filesystem tree |
| Auth | AuthConfig ontology, deploy.auth, Keycloak integration |
| Operator | CK.Operator lifecycle, proof, reconciliation, namespace isolation |
| CRDs | ConceptKernel and CKProject CRD OpenAPI schemas |
| EXTENDS | EXTENDS predicate — capability mounting via ontology edges |
| Consensus | CK.Consensus kernel, propose/evaluate/approve |
| Graph | Jena Fuseki, /ckp dataset, SPARQL queries |
| Sessions | Multi-user NATS sessions |
| Task Engine | Consensus-driven executor dispatch |
| Versioning | Per-kernel master clones, three sibling dirs, .git-ref provenance |
| Changelog | Full version-by-version changelog |
Logical Analysis Note
Two of the operational pages (Sessions, Task Engine) cover planned features that are not yet implemented. They are included because the delta specification defines them normatively and the architecture is designed to support them. They are clearly marked as PLANNED.