Introduction to CKP v3.9.1

A Concept Kernel is a self-governing unit of meaning. Its types are ontology — RDF classes, SHACL shapes, OWL-RL rules, not hand-rolled columns. Every change it makes is shape-gated, sealed, and proof-chained the moment it lands, and it answers the world through a single typed verb carried over NATS-WSS. Meaning is the schema; the door is the whole surface.

It runs inside PostgreSQL, but the engine stays out of sight: no REST endpoint, no SQL handle, no query surface is exposed. The meaning is sovereign, every step it has taken is provable, and the only thing that crosses the boundary is one verb and its typed payload. This is CKP v3.9.1 — Critical Isolation: the engine stays invisible, the meaning stays sovereign, and the proof chain stays whole.

It is shipped, attested, and runnable today. The whole substrate is one image — ck-allinone v0.7.28 — composing PostgreSQL 17, the pgRDF graph engine v0.6.19, the pgCK runtime v0.4.21, NATS, and the cklib client v1.5.4 into a ~128 MB container. One docker run and the door is open.

The claim, in one paragraph

An app — a browser, an agent, a service — reaches a kernel through exactly one function: ckp.dispatch. It names a verb from a closed set and hands it a typed payload. The runtime validates the payload against the kernel's declared shape, and if it conforms the fact seals — validate → seal → HMAC-chained ledger → verifiable proof, in one transaction. A kernel changes its own types by consensus — propose → vote → apply — and each applied change advances the kernel's epoch. No REST endpoint, no SQL handle, no query engine is ever exposed. The door is the whole surface.

The distinction it all rests on

The single design choice underneath everything is this: an app reaches a kernel through a verb, not a query surface.

A query surface — a SQL connection, a SPARQL endpoint, a resolver that builds arbitrary filters — lets the caller author logic the engine then runs. Its power is unbounded and unenumerable. A verb is the opposite: a finite, named, pre-declared operation with a typed payload the runtime knows before it runs. CKP exposes a closed vocabulary of verbs and no query surface. This is the precondition that makes access enumerable and shapes unbypassable — the whole of Critical Isolation. Read A Verb, Not a Query Surface first; the rest of the specification is its consequences.

What a kernel holds

A Concept Kernel is a named domain — a match, an experiment, a service, any bounded universe you open with kernel.create. Inside it you land sealed instances:

• Tasks — governed, sealed work-or-state objects that target a kernel: a lifecycle, a priority, a queue position, each a proof-chained seal.
• Goals — the objectives and backlogs a kernel works toward.

You read them back with typed reads — instances.list, instance.get, instance.verify, instance.provenance — each re-verifiable against its proof. And you evolve what a kernel's instances must carry through governance, not a migration: propose a change, seal it as data, apply it once its votes clear, and the kernel's epoch advances. That shape — kernels holding governed tasks and goals, evolvable by consensus — maps onto games, experiments, and software systems alike.

What is live, and what is next

The published bundle gives you a governed, sealed, consensus-evolvable substrate today:

• ✅ Kernels — named domains created on the fly (kernel.create).
• ✅ Tasks and Goals — sealed, proof-chained instances targeting a kernel, with full typed reads and re-verifiable proofs.
• ✅ Governance — evolve a kernel's type through propose → vote → apply, consensus-gated and epoch-advancing; proposals and votes are themselves sealed instances.
• ✅ The isolation floor — the participant role can call ckp.dispatch and nothing else; every write passes the SHACL seal gate and mints a proof.
• 🔜 First-class custom types — modeling your own sealed type (a Ship, a Sample) with its own create verb and shape. instance.create today routes to Task and Goal; generic typed create is the next pgCK capability (CKP v3.9 §4).
• 🔜 Per-user verified identity — today the participant role authenticates with a shared password (treat a deployment as alpha-trust; the isolation floor is real, but identity is a shared secret). Verified-JWT identity with seal-time claim checking is an inherited upstream prerequisite (CKP v3.9 §10).

The changelog tracks each of these against the release that ships it.

Where to go next

• New to the protocol: A Verb, Not a Query Surface → Critical Isolation → What a Concept Kernel Is.
• Want to run it: Quickstart — one docker run to sealed state.
• Building an app: The Client: cklib and Naming.
• The notation direction (χ, ρ, σ … the strands, the scoring loop): the in-design v3.10 set — conceptual, not part of the shipped v3.9.1 surface.