CK Loop -- Identity and Awakening

Chapter 6 of the CKP v3.6 Specification -- Normative

Purpose

The CK loop is the identity organ of the Material Entity. It holds everything a Concept Kernel needs to read itself into existence. It is versioned by the developer -- the human or CI process that governs the kernel's evolution. It is the slowest-changing of the three loops and the only one that defines what the kernel fundamentally IS.

In Description Logic terms, the CK loop is the TBox. Its contents declare the terminological vocabulary: what classes of data the kernel produces, what constraints apply, what actions are available. The CK loop is ReadOnly at runtime -- the kernel process MUST NOT modify its own identity files.

The CK loop exists because a computational entity that cannot describe itself cannot be governed, composed, or trusted. Without a persistent, version-controlled identity, a kernel is a black box. With the CK loop, every kernel carries its own birth certificate, ontology, constraints, and action catalogue.

Awakening Sequence

When a Concept Kernel wakes, it MUST read its identity files in strict order. Each file answers a progressively more specific question about the kernel's existence. The sequence is normative -- implementations MUST NOT reorder these steps. If any step fails, the kernel MUST NOT proceed to subsequent steps.

Order	File / Action	Question Answered	Failure Behaviour
1	`conceptkernel.yaml`	Who am I?	Fatal -- kernel MUST NOT start
2	`README.md`	Why do I exist?	Warning -- kernel MAY start with degraded identity
3	`CLAUDE.md`	How do I behave?	Warning -- kernel MAY start without agent instructions
4	`SKILL.md`	What can I do?	Fatal -- kernel has no action catalogue
5	`CHANGELOG.md`	What have I become?	Warning -- kernel MAY start without history
5a	SPIRE agent	Am I cryptographically who I claim?	Fatal for non-LOCAL kernels; skip for `LOCAL.*` prefix
6	`ontology.yaml`	How is my world shaped?	Fatal -- kernel has no data schema
7	`rules.shacl`	What constraints bind me?	Warning -- permissive stub mode (all writes accepted)
8	`serving.json`	Which version am I?	Fatal -- kernel cannot determine active version
8a	`.ck-guid`	What is my canonical SPID?	Warning -- fallback to `kernel_id` from YAML

Fatal Failure Points

Two steps are universally fatal: Step 5a (SPIFFE/SPIRE) for all non-LOCAL kernels, and Step 6 (ontology.yaml). The SPIFFE verification at position 5a MUST occur after reading CHANGELOG.md and before loading ontology.yaml. Identity verification precedes ontology and rule loading. Implementations that place SPIFFE verification at any other position are non-conformant.

conceptkernel.yaml -- The Identity Document

This is the kernel's birth certificate. It carries identity only -- no mounts, no runtime config, no tool references. Those are platform concerns. The capability: block is the Capability Advertisement that powers the fleet discovery loop. The spec.actions block is the machine-readable service description queryable by discovery kernels and external agents.

yaml

# conceptkernel.yaml -- CKP v3.6
apiVersion:        conceptkernel/v3
kernel_class:      Finance.Employee
kernel_id:         7f3e-a1b2-c3d4-e5f6
bfo_type:          BFO:0000040
owner:             operator@example.org
created_at:        2026-03-14T00:00:00Z
ontology_uri:      http://example.org/ck/finance-employee/v1

# Namespace and domain
namespace_prefix:  ACME
domain:            example.org
project:           Acme.Analytics

# Capability advertisement (fleet discovery loop)
capability:
  service_type:    "employee data governance"
  pricing_model:   free_tier      # free_tier | per_request | subscription | negotiated
  availability:    deployed       # deployed | staging | local
  sla:             best_effort    # best_effort | 99.9 | 99.99

# Action catalogue (discovery kernel fleet.catalog serves this)
spec:
  actions:
    common:
      - name: status
        description: Get kernel status and health
        access: anon
      - name: check.identity
        description: Validate kernel against CKP spec
        access: anon
    unique:
      - name: employee.create
        description: Create a new employee concept instance
        access: auth
        params: "name: str, department: str, role: str"
      - name: employee.query
        description: Query employee instances with filters
        access: anon

# Grants block (SPIFFE access control)
grants:
  - identity:  spiffe://example.org/ck/CK.Query/9a1b-c2d3-e4f5-g6h7
    actions:   [read-storage, read-index]
    expires:   2027-01-01T00:00:00Z
    audit:     true

# URN: ckp://Kernel#ACME.Finance.Employee:v1.0

Validation Rules

Conformant implementations MUST validate conceptkernel.yaml against these rules:

#	Rule	Consequence of Violation
1	`apiVersion` MUST be `conceptkernel/v3`. Version `v2` SHOULD produce a warning; unknown versions MUST be rejected.	Kernel does not start
2	`kernel_id` MUST be a valid UUID.	Kernel does not start
3	`bfo_type` MUST be `BFO:0000040`.	Kernel does not start
4	`namespace_prefix` MUST be present and non-empty.	Kernel does not start
5	`spec.actions.common` MUST include at least `status` and `check.identity`.	Kernel does not start

URN Pattern

Every kernel is addressable by a deterministic URN built from its identity fields:

ckp://Kernel#{namespace_prefix}.{kernel_class}:v{major}.{minor}

Example: ckp://Kernel#ACME.Finance.Employee:v1.0

serving.json -- Active Version Routing

serving.json declares which version of the CK loop (and by extension which tool/ commit) is currently active. It supports two schema modes.

Mode 1: Canary Routing

Traffic splitting across versions using ck_ref, tool_ref, and weight fields:

json

{
  "kernel_class": "Finance.Employee",
  "versions": [
    { "name": "stable",  "ck_ref":   "refs/heads/stable",
                           "tool_ref": "refs/heads/stable",  "weight": 95 },
    { "name": "canary",  "ck_ref":   "refs/heads/canary",
                           "tool_ref": "refs/heads/canary",  "weight":  5 },
    { "name": "develop", "ck_ref":   "refs/heads/develop",
                           "tool_ref": "refs/heads/develop",  "weight":  0 }
  ],
  "routing": {
    "default": "stable",
    "by_header_X-Kernel-Version": { "canary": "canary", "dev": "develop" }
  }
}

Mode 2: Explicit Version

Version directory management using active, current, and deprecated_at fields:

json

{
  "versions": [
    { "name": "v1", "active": true },
    { "name": "v2", "active": true, "current": true },
    { "name": "v3", "active": false, "deprecated_at": "2026-04-01" }
  ]
}

Platform Write Exception

serving.json is the sole exception to CK loop read-only policy. The platform holds write authority to this file via a volume sub-path mount or sidecar mechanism. The CK loop volume remains ReadOnlyMany for all other files. CK.Operator implementations MUST document the write-through mechanism used for serving.json.

CK Loop NATS Topics

Conformant implementations MUST publish the following NATS topics for CK loop events. All topics use the pattern ck.{guid}.ck.*.

Topic	When Published
`ck.{guid}.ck.commit`	CK loop repo -- new commit pushed
`ck.{guid}.ck.ref-update`	Branch pointer moved
`ck.{guid}.ck.promote`	Version promoted to stable
`ck.{guid}.ck.rollback`	Version rolled back
`ck.{guid}.ck.canary`	Canary weight updated
`ck.{guid}.ck.schema-change`	`ontology.yaml` or `rules.shacl` changed
`ck.{guid}.ck.depends-on`	Dependency on another kernel declared or updated

LOCAL.* Authentication

LOCAL.* kernels operate in an implicit trust domain. All grants are evaluated as allow -- the LOCAL.* prefix disables the SVID verification gate entirely. This means LOCAL.* kernels cannot restrict access to their DATA loop from other LOCAL.* kernels in the same project.

Cross-project access from LOCAL.* to non-LOCAL.* still REQUIRES SPIFFE. Local development prioritises velocity; security enforcement activates at deployment time when the LOCAL.* prefix is stripped.

Part II Conformance Criteria (CK Loop)

ID	Requirement	Level
L-1	Kernel MUST read awakening files in the order specified in the awakening sequence table	Core
L-2	Kernel MUST NOT proceed past a failed fatal awakening step	Core
L-3	SPIFFE verification MUST occur at position 5a in the awakening sequence	Core
L-4	`conceptkernel.yaml` MUST pass the five validation rules	Core
L-5	`serving.json` is the sole CK loop file with platform write authority	Core

CK Loop -- Identity and Awakening ​

Purpose ​

Awakening Sequence ​

conceptkernel.yaml -- The Identity Document ​

Validation Rules ​

URN Pattern ​

serving.json -- Active Version Routing ​

Mode 1: Canary Routing ​

Mode 2: Explicit Version ​

CK Loop NATS Topics ​

LOCAL.* Authentication ​

Part II Conformance Criteria (CK Loop) ​