docs: rename storage/ → data/ to match DATA-loop terminology

Aligns v3.6 spec docs and ontology with the three-loop discipline where
the writable loop is named DATA (not storage). 28 files updated across
docs/v3.6/ and docs/public/ontology/v3.6/.

Author: styk-tv

docs/public/ontology/v3.6/core.ttl

@@ -587,6 +587,92 @@ ckp:criticalGap a owl:AnnotationProperty ;
     rdfs:label "critical gap"@en ;
     rdfs:comment "A critical missing feature or integration"@en .
 
+#################################################################
+#    Version Materialisation (v3.6.1)
+#################################################################
+
+### VersionDeclaration — a named version with per-kernel git refs
+### Grounded as GenericallyDependentContinuant (depends on CK.Project)
+
+ckp:VersionDeclaration a owl:Class ;
+    rdfs:subClassOf bfo:0000031 ;  # bfo:GenericallyDependentContinuant
+    rdfs:label "Version Declaration"@en ;
+    rdfs:comment "A named version with per-kernel git refs, mapped to a URL route. Each version materialises three sibling directories per kernel: ck/ (identity, ReadOnly), tool/ (code, ReadOnly), data/ (state, ReadWrite). No nested mounts — three independent PVs mounted as siblings under /ck/{kernel}/."@en .
+
+ckp:hasVersionName a owl:DatatypeProperty ;
+    rdfs:domain ckp:VersionDeclaration ;
+    rdfs:range xsd:string ;
+    rdfs:label "version name"@en ;
+    rdfs:comment "Version tag (v1.0.0, v1.3.2) — used in filer paths, PV names, HTTPRoute rules"@en .
+
+ckp:hasRoute a owl:DatatypeProperty ;
+    rdfs:domain ckp:VersionDeclaration ;
+    rdfs:range xsd:string ;
+    rdfs:label "route"@en ;
+    rdfs:comment "URL path prefix on project hostname (e.g. /, /next)"@en .
+
+ckp:hasDataIsolation a owl:ObjectProperty ;
+    rdfs:domain ckp:VersionDeclaration ;
+    rdfs:range ckp:DataIsolationMode ;
+    rdfs:label "data isolation mode"@en ;
+    rdfs:comment "Controls whether this version gets its own DATA directory or shares with another version"@en .
+
+ckp:hasKernelRef a owl:ObjectProperty ;
+    rdfs:domain ckp:VersionDeclaration ;
+    rdfs:range ckp:KernelVersionRef ;
+    rdfs:label "kernel version ref"@en ;
+    rdfs:comment "Per-kernel git refs for this version"@en .
+
+### KernelVersionRef — per-kernel, per-loop git references
+
+ckp:KernelVersionRef a owl:Class ;
+    rdfs:subClassOf bfo:0000031 ;  # bfo:GenericallyDependentContinuant
+    rdfs:label "Kernel Version Ref"@en ;
+    rdfs:comment "Per-kernel, per-loop git references for version materialisation. Each concept kernel has three independently versioned storage concerns: CK loop (ck_ref from ck.git), TOOL loop (tool_ref from tool.git), DATA loop (directory-based, no git ref). Full-tree git archive produces loop content directly — no subtree filtering."@en .
+
+ckp:refKernelName a owl:DatatypeProperty ;
+    rdfs:domain ckp:KernelVersionRef ;
+    rdfs:range xsd:string ;
+    rdfs:label "kernel name"@en ;
+    rdfs:comment "Concept kernel name. Maps to registry {name}/ck.git and {name}/tool.git, filer /ck/{name}/ck.git/ and /ck/{name}/tool.git/"@en .
+
+ckp:ckRef a owl:DatatypeProperty ;
+    rdfs:domain ckp:KernelVersionRef ;
+    rdfs:range xsd:string ;
+    rdfs:label "CK loop ref"@en ;
+    rdfs:comment "Git commit hash for CK loop. Full-tree archive from per-kernel CK bare repo. Extracted to /ck/{kernel}/{version}/ck/ on filer. Mounted at /ck/{kernel}/ck/ in pod (ReadOnlyMany)."@en .
+
+ckp:toolRef a owl:DatatypeProperty ;
+    rdfs:domain ckp:KernelVersionRef ;
+    rdfs:range xsd:string ;
+    rdfs:label "TOOL loop ref"@en ;
+    rdfs:comment "Git commit hash for TOOL loop. Full-tree archive from per-kernel TOOL bare repo. Extracted to /ck/{kernel}/{version}/tool/ on filer. Mounted at /ck/{kernel}/tool/ in pod (ReadOnlyMany or ReadWriteMany for hot-reload)."@en .
+
+ckp:hasAutoUpdate a owl:ObjectProperty ;
+    rdfs:domain ckp:KernelVersionRef ;
+    rdfs:range ckp:AutoUpdatePolicy ;
+    rdfs:label "auto-update policy"@en ;
+    rdfs:comment "Policy for webhook-driven ref updates from the git registry"@en .
+
+### GitRegistryConfig — registry connection for a project
+
+ckp:GitRegistryConfig a owl:Class ;
+    rdfs:subClassOf bfo:0000031 ;  # bfo:GenericallyDependentContinuant
+    rdfs:label "Git Registry Config"@en ;
+    rdfs:comment "Git registry connection configuration. The operator discovers this from the CK.Project ontology at runtime via the COMPOSES edge — not hardcoded."@en .
+
+ckp:registryUrl a owl:DatatypeProperty ;
+    rdfs:domain ckp:GitRegistryConfig ;
+    rdfs:range xsd:anyURI ;
+    rdfs:label "registry URL"@en ;
+    rdfs:comment "Registry base URL (e.g. http://soft-serve-http.git.svc)"@en .
+
+ckp:authSecret a owl:DatatypeProperty ;
+    rdfs:domain ckp:GitRegistryConfig ;
+    rdfs:range xsd:string ;
+    rdfs:label "auth secret"@en ;
+    rdfs:comment "K8s Secret name containing registry credentials. Optional for cluster-internal registries."@en .
+
 #################################################################
 #    Coverage Summary (as OWL Individuals)
 #################################################################

docs/public/ontology/v3.6/kernel-metadata.ttl

@@ -341,6 +341,52 @@ ckp:TemplateKernel a owl:Class ;
     rdfs:label "Template Kernel"@en ;
     rdfs:comment "Template kernel for creating new kernels via forking"@en .
 
+#################################################################
+#    Version Materialisation Enums (v3.6.1)
+#################################################################
+
+### DataIsolationMode — controls DATA directory scoping per version
+
+ckp:DataIsolationMode a owl:Class ;
+    rdfs:subClassOf bfo:0000019 ;  # bfo:Quality
+    rdfs:label "Data Isolation Mode"@en ;
+    rdfs:comment "Controls whether a version gets its own DATA directory or shares with another version"@en .
+
+ckp:DataIsolation-Isolated a ckp:DataIsolationMode ;
+    rdfs:label "Isolated"@en ;
+    rdfs:comment "Version gets its own DATA directory at /ck-data/{hostname}/{kernel}/{version}/"@en .
+
+ckp:DataIsolation-Shared a ckp:DataIsolationMode ;
+    rdfs:label "Shared"@en ;
+    rdfs:comment "Version shares DATA directory with another version"@en .
+
+### AutoUpdatePolicy — webhook-driven ref update behaviour
+
+ckp:AutoUpdatePolicy a owl:Class ;
+    rdfs:subClassOf bfo:0000019 ;  # bfo:Quality
+    rdfs:label "Auto Update Policy"@en ;
+    rdfs:comment "Policy for handling ref-update webhooks from the git registry"@en .
+
+ckp:AutoUpdate-Auto a ckp:AutoUpdatePolicy ;
+    rdfs:label "Auto"@en ;
+    rdfs:comment "Operator auto-patches CR with new ref on webhook. Triggers reconcile."@en .
+
+ckp:AutoUpdate-Manual a ckp:AutoUpdatePolicy ;
+    rdfs:label "Manual"@en ;
+    rdfs:comment "Operator emits ref-update.available event. Requires manual CR patch."@en .
+
+### StorageMedium additions (v3.6.1)
+
+ckp:StorageMedium-GIT_BARE_REPO a ckp:StorageMedium ;
+    rdfs:label "Git Bare Repository"@en ;
+    rdfs:comment "Per-loop bare git repository on filer. CK loop at /ck/{kernel}/ck.git/, TOOL loop at /ck/{kernel}/tool.git/. Source of truth for git archive materialisation."@en .
+
+### DeploymentMethod additions (v3.6.1)
+
+ckp:DeploymentMethod-THREE_SIBLING a ckp:DeploymentMethod ;
+    rdfs:label "Three Sibling Mounts"@en ;
+    rdfs:comment "v3.6.1 Option A: three independent PVs mounted as siblings under /ck/{kernel}/. No nested volumes. Avoids runc EROFS constraint on ReadOnly parent overlays."@en .
+
 #################################################################
 #    Status Individuals
 #################################################################

docs/public/ontology/v3.6/shapes.ttl

@@ -301,6 +301,69 @@ ckp:KernelReferenceIntegrityShape
         """ ;
     ] .
 
+# ----------------------------------------------------------------------------
+# Version Declaration Shape (v3.6.1)
+# ----------------------------------------------------------------------------
+ckp:VersionDeclarationShape
+    a sh:NodeShape ;
+    sh:targetClass ckp:VersionDeclaration ;
+
+    sh:property [
+        sh:path ckp:hasVersionName ;
+        sh:datatype xsd:string ;
+        sh:minCount 1 ;
+        sh:maxCount 1 ;
+        sh:pattern "^[a-zA-Z0-9][a-zA-Z0-9._-]*$" ;
+        sh:message "Version name must be alphanumeric with dots, hyphens, underscores" ;
+    ] ;
+
+    sh:property [
+        sh:path ckp:hasRoute ;
+        sh:datatype xsd:string ;
+        sh:minCount 1 ;
+        sh:maxCount 1 ;
+        sh:pattern "^/" ;
+        sh:message "Route must start with /" ;
+    ] ;
+
+    sh:property [
+        sh:path ckp:hasKernelRef ;
+        sh:node ckp:KernelVersionRefShape ;
+        sh:minCount 1 ;
+        sh:message "Version must declare at least one kernel ref" ;
+    ] .
+
+# ----------------------------------------------------------------------------
+# Kernel Version Ref Shape (v3.6.1)
+# ----------------------------------------------------------------------------
+ckp:KernelVersionRefShape
+    a sh:NodeShape ;
+    sh:targetClass ckp:KernelVersionRef ;
+
+    sh:property [
+        sh:path ckp:refKernelName ;
+        sh:datatype xsd:string ;
+        sh:minCount 1 ;
+        sh:maxCount 1 ;
+        sh:message "Kernel name is required" ;
+    ] ;
+
+    sh:property [
+        sh:path ckp:ckRef ;
+        sh:datatype xsd:string ;
+        sh:maxCount 1 ;
+        sh:pattern "^[0-9a-f]{7,40}$" ;
+        sh:message "ck_ref must be a hex commit hash (7-40 chars)" ;
+    ] ;
+
+    sh:property [
+        sh:path ckp:toolRef ;
+        sh:datatype xsd:string ;
+        sh:maxCount 1 ;
+        sh:pattern "^[0-9a-f]{7,40}$" ;
+        sh:message "tool_ref must be a hex commit hash (7-40 chars)" ;
+    ] .
+
 # EOF - ConceptKernel SHACL Shapes v1.3.20
 # Creator: Peter Styk <peter@conceptkernel.org>
 # Project: https://conceptkernel.org

docs/v3.6/agent-teams.md

@@ -55,12 +55,12 @@ Each agent in the team loads its own CK loop, following the same awakening seque
 | 2 | `CLAUDE.md` | Behavioral instructions |
 | 3 | `SKILL.md` | Action catalog |
 | 4 | `ontology.yaml` | Data schema |
-| 5 | `storage/memory/MEMORY.md` | Persistent memory |
+| 5 | `data/memory/MEMORY.md` | Persistent memory |
 
 Each agent operates under three-loop discipline:
 - **CK loop**: Read-only -- the agent reads its identity but cannot modify it
 - **TOOL loop**: Read-only -- the agent can read `tool/processor.py` to understand capabilities
-- **DATA loop**: Writable -- the agent writes to `storage/` (instances, proof, memory)
+- **DATA loop**: Writable -- the agent writes to `data/` (instances, proof, memory)
 
 Each agent works within its kernel directory. There is no shared writable path between agents.
 
@@ -105,7 +105,7 @@ Parent collects results from all agents as they complete. Agents may finish at d
 
 ### 4. Memory Merge
 
-Parent persists each agent's memory updates to their respective `storage/memory/MEMORY.md`. Each kernel's memory is updated independently -- there is no shared memory across agents.
+Parent persists each agent's memory updates to their respective `data/memory/MEMORY.md`. Each kernel's memory is updated independently -- there is no shared memory across agents.
 
 ### 5. Unified Report
 
@@ -135,7 +135,7 @@ Each kernel's `CLAUDE.md` must declare inter-kernel communication patterns for t
 
 **Question:** How do agents avoid conflicting DATA loop writes?
 
-**Answer:** Each agent writes to its OWN kernel's DATA loop. ComplianceCheck writes to `CK.ComplianceCheck/storage/`, Operator writes to `CK.Operator/storage/`, Core writes to `Delvinator.Core/storage/`. There is no shared writable path. Cross-kernel communication goes through NATS, not filesystem.
+**Answer:** Each agent writes to its OWN kernel's DATA loop. ComplianceCheck writes to `CK.ComplianceCheck/data/`, Operator writes to `CK.Operator/data/`, Core writes to `Delvinator.Core/data/`. There is no shared writable path. Cross-kernel communication goes through NATS, not filesystem.
 
 **Question:** Can agents in a team use EXTENDS?
 

docs/v3.6/bfo-grounding.md

@@ -99,7 +99,7 @@ The TBox and ABox mappings are rigorous. The RBox mapping is approximate -- the
 |--------|----------|----------|---------------------|-----------|
 | TBox | CK Loop | `conceptkernel.yaml`, `ontology.yaml`, `rules.shacl`, `serving.json` | Volume `ck-{guid}-ck`, ReadOnly | Rigorous |
 | RBox | TOOL Loop | `tool/processor.py`, scripts, services, build artifacts | Volume `ck-{guid}-tool`, ReadOnly | Approximate |
-| ABox | DATA Loop | `storage/instances/`, `proof/`, `ledger/`, `index/`, `llm/`, `web/` | Volume `ck-{guid}-storage`, ReadWrite | Rigorous |
+| ABox | DATA Loop | `data/instances/`, `proof/`, `ledger/`, `index/`, `llm/`, `web/` | Volume `ck-{guid}-storage`, ReadWrite | Rigorous |
 
 :::warning
 The RBox mapping is deliberately approximate. The TOOL loop contains executable code -- Python handlers, scripts, build artifacts -- not Description Logic role axioms. Do not attempt to reason about TOOL loop contents using DL tools. The analogy is structural (the TOOL loop governs *how the kernel relates* to other things), not formal.

docs/v3.6/changelog.md

@@ -168,11 +168,11 @@ All notable changes in the development increments that compose v3.6. Each versio
 - Updated ck-agent skill (`~/.claude/skills/ck-agent/SKILL.md`) for CKP v3.5 layout
 - CLAUDE.md at root (not llm/), SKILL.md loading, ontology.yaml summary
 - Three-loop discipline enforced: CK read-only, TOOL read-only, DATA writable
-- Memory persistence: `storage/memory/MEMORY.md` (DATA loop)
+- Memory persistence: `data/memory/MEMORY.md` (DATA loop)
 - Multi-root search: `$CK_CONCEPTS_DIR`, `./concepts/`, `~/git/delve_workspace/concepts/`
 - Fuzzy kernel resolution: `CK.*`, `Delvinator.*`, `CS.*`, `Hello.*`
 - NATS bridge: optional dispatch to live kernel via `nats pub`
-- `storage/memory/` directories created for all kernels
+- `data/memory/` directories created for all kernels
 
 ### v3.5.7 -- Hello.Greeter Kernel <Badge type="tip" text="DEPLOYED" />
 

docs/v3.6/ck-loop.md

@@ -1,6 +1,6 @@
 ---
 title: CK Loop -- Identity and Awakening
-description: The CK loop is the identity organ of every Concept Kernel. It holds the awakening sequence, conceptkernel.yaml, serving.json, and defines what the kernel IS.
+description: The CK loop is the identity organ of every Concept Kernel. It holds the awakening sequence, conceptkernel.yaml, and defines what the kernel IS.
 ---
 
 # CK Loop -- Identity and Awakening
@@ -29,7 +29,7 @@ When a Concept Kernel wakes, it MUST read its identity files in **strict order**
 | 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 |
+| 8 | ~~`serving.json`~~ | ~~Which version am I?~~ | **Retired (v3.6.1)** -- version state in CK.Project CR |
 | 8a | `.ck-guid` | What is my canonical SPID? | Warning -- fallback to `kernel_id` from YAML |
 
 ::: danger Fatal Failure Points
@@ -46,7 +46,7 @@ graph TD
     S5a["5a. SPIRE Agent<br/><em>Am I who I claim?</em>"]
     S6["6. ontology.yaml<br/><em>How is my world shaped?</em>"]
     S7["7. rules.shacl<br/><em>What constraints bind me?</em>"]
-    S8["8. serving.json<br/><em>Which version am I?</em>"]
+    S8["8. (retired v3.6.1)<br/><em>serving.json removed</em>"]
     S8a["8a. .ck-guid<br/><em>Canonical SPID</em>"]
     FAIL["HALT -- Kernel does not start"]
     READY["Kernel READY"]
@@ -62,9 +62,7 @@ graph TD
     S5a -->|FAIL non-LOCAL| FAIL
     S6 -->|OK| S7
     S6 -->|FAIL| FAIL
-    S7 -->|OK or WARN| S8
-    S8 -->|OK| S8a
-    S8 -->|FAIL| FAIL
+    S7 -->|OK or WARN| S8a
     S8a -->|OK or WARN| READY
 
     style FAIL fill:#cc3333,color:#fff
@@ -148,49 +146,27 @@ 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" }
-  }
-}
-```
+## Version Materialisation (v3.6.1)
 
-### Mode 2: Explicit Version
+::: info serving.json Retired
+`serving.json` was retired in v3.6.1. Version state now lives entirely in the **CK.Project custom resource** (`spec.versions`). The CK loop volume is purely ReadOnlyMany with **no exceptions**. No write-through hack, no sidecar mechanism. See [Version Materialisation](./versioning) for the full model.
+:::
 
-Version directory management using `active`, `current`, and `deprecated_at` fields:
+Version declarations are part of the CK.Project custom resource. Each version specifies per-kernel git commit hashes for CK and TOOL loops independently:
 
-```json
-{
-  "versions": [
-    { "name": "v1", "active": true },
-    { "name": "v2", "active": true, "current": true },
-    { "name": "v3", "active": false, "deprecated_at": "2026-04-01" }
-  ]
-}
+```yaml
+spec:
+  versions:
+    - name: v1.3.2
+      route: /
+      data: isolated
+      kernels:
+        - name: Hello.Greeter
+          ck_ref: abc123f      # commit hash from CK repo
+          tool_ref: def4567    # commit hash from TOOL repo
 ```
 
-::: warning 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`.
-:::
+The operator materialises each version by streaming `git archive` from per-kernel bare repositories to the filer. Each loop has its own bare repo — full-tree archive produces the loop content directly. No subtree filtering.
 
 ## CK Loop NATS Topics
 
@@ -220,4 +196,4 @@ Cross-project access from `LOCAL.*` to non-`LOCAL.*` still REQUIRES SPIFFE. Loca
 | 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 |
+| L-5 | CK loop volume is purely ReadOnlyMany — no writable exceptions (v3.6.1: `serving.json` retired) | Core |