|
| 1 | +# Architecture |
| 2 | + |
| 3 | +The Concept Kernel Protocol uses a layered architecture where every concept is an autonomous kernel participating in a governed protocol. |
| 4 | + |
| 5 | +## System Overview |
| 6 | + |
| 7 | +``` |
| 8 | +┌─────────────────────────────────────────────────────┐ |
| 9 | +│ Layer 3: User Concepts │ |
| 10 | +│ Cat · Invoice · Gene · Policy · ... │ |
| 11 | +├─────────────────────────────────────────────────────┤ |
| 12 | +│ Layer 2: CK-Protocol │ |
| 13 | +│ Messages · Actions · Routing · Compliance │ |
| 14 | +├─────────────────────────────────────────────────────┤ |
| 15 | +│ Layer 1: CK-Ontology │ |
| 16 | +│ LinkML · SHACL · Type Registry · Validation│ |
| 17 | +├─────────────────────────────────────────────────────┤ |
| 18 | +│ Layer 0: CK-Core │ |
| 19 | +│ Orchestration · Lifecycle · RBAC · Consensus│ |
| 20 | +└─────────────────────────────────────────────────────┘ |
| 21 | +``` |
| 22 | + |
| 23 | +## Core Kernels |
| 24 | + |
| 25 | +The protocol is implemented through a set of core kernels, each with a distinct responsibility: |
| 26 | + |
| 27 | +| Kernel | Role | Responsibility | |
| 28 | +|--------|------|----------------| |
| 29 | +| **CK_Core** | Orchestrator | Routes actions, manages registry, delegates to other kernels | |
| 30 | +| **CK_Ontology** | Type System | Registers ontologies, validates actions, queries relationships | |
| 31 | +| **CK_Admission** | Entrypoint | Receives requests, validates structure, routes to handlers | |
| 32 | +| **CK_Proof** | Cryptographic Proofs | Generates and verifies proofs, logs events, supports rollback | |
| 33 | +| **CK_Consensus** | Governance | Proposes consensus rounds, manages voting, validates decisions | |
| 34 | +| **CK_Constraint** | Enforcement | Defines constraints, validates actions against SHACL shapes | |
| 35 | +| **CK_Storage** | Persistence | Protocol-abstracted storage across disk, git, and triplestore backends | |
| 36 | +| **CK_Concept** | Concept Kernel | Every concept is a kernel — defines, validates, and relates itself | |
| 37 | + |
| 38 | +## Concept Kernel Structure |
| 39 | + |
| 40 | +Every concept kernel maintains its own directory structure: |
| 41 | + |
| 42 | +``` |
| 43 | +/concepts/{ConceptName}/ |
| 44 | +├── ontology.yaml # LinkML schema + SHACL |
| 45 | +├── kernel.js # WASM-executable interface |
| 46 | +├── io/ |
| 47 | +│ ├── input/ # Validated ingress |
| 48 | +│ └── output/ # Audited egress |
| 49 | +├── shacl/ # SHACL constraint rules |
| 50 | +└── var/ |
| 51 | + ├── ledger/ # Immutable audit records |
| 52 | + └── jobs/ # Execution traces |
| 53 | +``` |
| 54 | + |
| 55 | +## Protocol Actions |
| 56 | + |
| 57 | +All operations are expressed as typed protocol actions: |
| 58 | + |
| 59 | +| Action | Purpose | |
| 60 | +|--------|---------| |
| 61 | +| `REL` | Create or update relationships between concepts | |
| 62 | +| `LINK` | Link concepts with type constraints | |
| 63 | +| `MERGE` | Merge concepts with strategy selection | |
| 64 | +| `UPDATE` | Update attributes with full auditability | |
| 65 | +| `PROOF` | Generate or verify cryptographic proofs | |
| 66 | +| `CONSENSUS` | Propose voting and governance decisions | |
| 67 | + |
| 68 | +## Message Flow |
| 69 | + |
| 70 | +Every protocol interaction follows a structured message flow: |
| 71 | + |
| 72 | +``` |
| 73 | +SESSION[s25a8] (Cat Admission) |
| 74 | + → PROPOSE[tx1] : CK_ADM → propose → CK_ONT : cat |
| 75 | + → VALIDATE[tx2]: |
| 76 | + → GET[tx1a]: CK_ONT → get → CK_STO : constraints |
| 77 | + ← RETURN[tx1b]: CK_STO → return → CK_ONT : [5 rules] |
| 78 | + → VERIFY[tx1c]: CK_ONT → verify → CK_TAX : mammal |
| 79 | + → ASSIMILATE[tx3]: concept stored (version: 1) |
| 80 | + ← LOG[tx4]: protocol_log saved |
| 81 | +``` |
| 82 | + |
| 83 | +## Storage Abstraction |
| 84 | + |
| 85 | +All persistence flows through `CK_Storage`, which supports multiple backends: |
| 86 | + |
| 87 | +- **Disk** — Local filesystem for development |
| 88 | +- **Git** — Version-controlled concept storage with full history |
| 89 | +- **Oxigraph** — RDF triplestore for ontology queries and SPARQL |
| 90 | + |
| 91 | +No kernel may access storage directly. All reads and writes go through the storage protocol. |
| 92 | + |
| 93 | +## Burst Propagation |
| 94 | + |
| 95 | +When a concept changes, the protocol triggers a **burst propagation** — a wave that traverses ontological relationships: |
| 96 | + |
| 97 | +1. Originates at the mutated concept |
| 98 | +2. Traverses `REL` and `LINK` edges |
| 99 | +3. Evaluates SHACL constraints at each hop |
| 100 | +4. Handles locked kernels via consensus escalation |
| 101 | +5. Converges proofs from all affected branches |
| 102 | + |
| 103 | +This ensures that the full concept graph remains consistent after every mutation. |
| 104 | + |
| 105 | +--- |
| 106 | + |
| 107 | +<div style="text-align: center; padding: 2rem 0;"> |
| 108 | + <a href="https://discord.gg/sTbfxV9xyU" style="display: inline-block; padding: 0.6rem 1.5rem; background: #5865F2; color: white; border-radius: 6px; font-weight: 600; text-decoration: none;">Discuss Architecture on Discord</a> |
| 109 | +</div> |
0 commit comments