DEV Community: Vladyslav

From Lab to Platform: How CKS Learned to Manage Knowledge Autonomously

Vladyslav — Wed, 05 Aug 2026 16:13:31 +0000

“Two weeks ago, we showed how CKS verifies knowledge. Now it manages it on its own — and it caught a real bug in its own design along the way.”

A week ago, we introduced Canonical Knowledge Structure — a verifiable knowledge backbone for LLMs. Back then, it was mostly a validator: you gave it a graph, it checked for contradictions, verified sources, and let you branch and merge like Git for knowledge.

But validation alone doesn't scale. The real question wasn't “Can we check this graph?” but “Can the system notice when a graph goes stale, decide what to do about it, and fix it — without a human in the loop?”

That question turned CKS from a tool into a platform. Here's what changed.

The Rise of Autonomous Agents

Over the past two weeks, we built five background workers — we call them sweepers — and three autonomous agents. They run continuously, watching for problems and resolving them before anyone notices.

The five sweepers patrol the knowledge graph for different kinds of staleness:

InferenceStalenessSweeper — finds reasoning chains where a premise has been superseded, and the conclusion may no longer hold.
ProvenanceStalenessSweeper — detects verification records older than a configurable TTL (default 30 days); sources can change or disappear.
TemporalStalenessSweeper — flags facts whose valid_until timestamp has expired.
GraphFreshnessSweeper — checks registered knowledge graphs for staleness; if a graph hasn't been updated in 7 days, it escalates a task.
ContradictionSweeper — scans sessions for logical contradictions (mutual exclusion, functional relation violations) that were never resolved.

Each sweeper publishes its findings into a shared outbox — the same persistent queue that the embedding worker already uses. No new infrastructure. No new tables. Just one more task type.

The three agents consume those tasks and resolve them:

Critic Agent — handles all five conflict types (gossip, inference, provenance, temporal, contradiction). For inference conflicts, it calls an LLM arbiter; for provenance, it re-verifies the source; for contradictions, it removes the conflicting relation mechanically.
Enrichment Agent — searches Wikipedia and arXiv for external context, filters candidates by relevance and authority, respects robots.txt, and links new findings back into the graph with provenance.
Memory Agent — lets LLMs save graphs under memorable names, load them in future conversations, browse a public gallery, and check freshness. No more rebuilding the same graph every session.

All three agents share the same architecture: claim a task from the outbox, resolve it, mark it complete — or dead-letter it if it can't be resolved after several attempts. The pattern is so consistent we extracted it into a shared agent_loop module.

Experiment of the Day: The Graph That Caught Its Own Bugs

This morning, we ran an experiment that closed the loop. We asked Claude Desktop — connected to CKS via MCP — to build a knowledge graph of the entire CKS ecosystem from its three GitHub repositories.

It did. 88 objects, 96 relations. Components, modules, ADRs, dependencies. Validated, no contradictions.

Then we saved it using register_graph("cks-ecosystem") — a new Memory Agent tool that stores a named reference to a session. We opened a fresh conversation, loaded the graph via get_graph, and asked Claude to analyze it.

That's when the interesting part happened. The analysis found real problems in the graph itself:

Self-loop publishes relations — cks-core → cks-core and cks-mcp → cks-mcp, instead of pointing to actual target objects (SchemaModel, MCPServerEndpoint).
Asymmetric resolves relations — the Critic Agent was linked to only one sweeper, though the code handles all five.
Missing Outbox object — the Enrichment Agent's documentation referenced a "persistent outbox", but the graph had no separate node for it.
No observability → runtime-metrics connection between the MCP and runtime layers.

We fixed all of them through evolve_knowledge — 24 operations applied to the same session, without rebuilding. The graph grew from 88 to 110 objects, 96 to 148 relations. Contradictions: zero.

The system was not just describing itself; it was debugging itself.

What Changed in Two Weeks

The numbers tell part of the story:

	Two weeks ago	Today
MCP tools	24	46
Tests	650+	1600+
Background sweepers	0	5
Autonomous agents	0	3
Storage backends	SQLite	SQLite + Postgres + in-memory
Case Studies	4	6

But the deeper change is architectural. Two weeks ago, CKS was a validator — you called it, it checked, it returned. Today, it's a platform where:

Detection is automatic. Sweepers run on timers, not on user requests.
Escalation is standardised. Every finding lands in the same outbox, regardless of type.
Resolution is autonomous. Agents consume tasks and fix problems without human intervention.
Memory is persistent. Graphs survive between conversations, browsable and searchable.

Why This Matters

The AI industry is racing to build smarter models. We're building infrastructure that makes any model more trustworthy — not through larger parameters, but through verifiable, self-maintaining knowledge.

Because the hardest problem in AI isn't generating an answer. It's knowing whether you can trust that answer tomorrow, next week, or next year. Language models generate knowledge. Trust has to be engineered.

“CKS stopped being a tool. It became a laboratory where knowledge graphs don't just sit there — they live, they evolve, and sometimes they point out their own mistakes.”

GitHub: Deus-corp/cks-mcp · Documentation: docs · PyPI: cks-mcp

The Missing Layer Between LLMs and Reality

Vladyslav — Fri, 31 Jul 2026 17:43:44 +0000

"Every AI demo works perfectly... right until someone asks, 'Where did you get that fact?'"

Every week, a new language model appears. More parameters. Longer context windows. Higher benchmark scores. The race is impressive.

But after months of building applications on top of LLMs, we kept running into the same question. Not "Can the model answer this?", but "Can we trust the answer tomorrow?"

That question changes everything. Hallucinations are only one symptom. The real problems look like this: sources disappear, facts contradict each other, knowledge silently changes over time, two agents modify the same graph, nobody knows which version introduced the mistake. Those aren't language problems. They're infrastructure problems.

Twenty years ago, Git solved this for source code. We think AI needs something similar for knowledge. That's why we built Canonical Knowledge Structure (CKS).

Two weeks ago, it was mostly a structural validator. Today, it's become something much bigger — a verifiable knowledge laboratory.

CKS, Two Weeks Later

24 tools. 650+ tests. Offline semantic search. Version history.
Sandboxed experiments. Contradiction detection. Async runtime.
Telemetry. Security hardening. Zero API keys.

Not because we wanted a bigger feature list. Because every one of these solved a real problem we hit while building AI systems. Let's look at a few of them.

Experiment #1 — Can an LLM Search by Meaning Instead of Keywords?

Most semantic search systems start with an API key. We wanted something different. So we integrated FastEmbed — a lightweight ONNX runtime that downloads a ~90MB sentence-transformers model once and runs forever, offline. No API key. No cloud. No rate limits.

To see whether it actually understood meaning, we created a tiny graph with three objects: apple, banana, and car. Then we searched for fruit. The ranking was:

apple      0.705
banana     0.671
car        0.214

Exactly what you'd hope to see. The interesting part isn't that semantic search works — it's that it now works entirely on your machine. No OpenAI embeddings, no Hugging Face token, no remote inference. Meaning became local.

We wrote up the full experiment, with code and scores, in our local embeddings case study.

Experiment #2 — Can We Catch Contradictions Before Humans Do?

LLMs rarely produce obviously wrong knowledge. They produce almost correct knowledge, and that's harder to spot. Consider a graph where "Earth supports Theory X" and "Earth refutes Theory X" both appear. Each statement is structurally valid. Together they're nonsense.

So we introduced structural constraints: MutualExclusionRule and FunctionalRelationRule. They don't evaluate language — they evaluate consistency. Because inconsistent knowledge is still incorrect knowledge. The system flagged the contradiction immediately. We ran the full experiment with conflict detection and sandbox resolution, and documented it here.

Experiment #3 — Can We Rewrite History Safely?

Imagine an agent proposes "remove this relation." Should it? Maybe. Maybe not. Most systems force you to decide immediately. CKS doesn't. Instead it creates a sandbox — try the change, inspect the graph, compare versions, discard it or merge it. Nothing touches production until you decide.

It feels surprisingly similar to opening a Git branch, except the repository is knowledge itself. We tested this by forking a session, applying a destructive edit in the sandbox, and confirming the parent session remained untouched. Then we merged the fix back. The whole flow took three tool calls.

Experiment #4 — Can We Break It?

This became our favourite experiment. Instead of adding features, we spent days trying to destroy the system. Could forged provenance records sneak in? Not anymore. Could RDF/XML trigger Billion Laughs attacks? Blocked. Could document ingestion bypass SSRF protection? No. Could middleware leak stack traces? Also fixed.

Most release posts celebrate features. We're equally proud of the bugs users will never see. We ran a full security audit, patched every hole we found, and wrote regression tests so they stay fixed. The full changelog is on GitHub.

Making Infrastructure Invisible

As the project grew, something unexpected happened. The hardest problems were no longer algorithms — they were operations. How do background workers coexist with semantic search? How do multiple sessions evolve simultaneously? How do you know which tool suddenly became slow?

So CKS became fully asynchronous. The JSON-RPC server no longer blocks on I/O. Embedding generation runs in background tasks. PostgreSQL workers coordinate through atomic SKIP LOCKED claims. Telemetry tracks every tool invocation — latency, success rate, error distribution — because infrastructure should explain itself, not require guesswork.

Bigger Than a Validator

CKS started as a way to stop fake citations. It became something else. Today it can search knowledge by meaning, detect contradictions, validate provenance, evolve graphs safely, compare versions, branch experiments, monitor itself, and run completely offline. We didn't plan for that — it happened naturally. Every missing capability became another layer in what we now think of as a knowledge operating system for LLMs.

Why This Matters

The AI industry is obsessed with making models smarter. We think the next leap forward may come from making them more trustworthy — not through larger parameter counts, but through better infrastructure.

The future probably isn't bigger prompts or bigger context windows. It's software that can answer questions like: where did this fact come from? When did it change? What contradicts it? Can I reproduce this result? Can I verify it? Language models generate knowledge. But trust has to be engineered.

Getting Started

pip install cks-mcp

Find the absolute path to the executable:

which cks-mcp

Then add this to your claude_desktop_config.json (replace /absolute/path/to/cks-mcp with the output of which):

{
  "mcpServers": {
    "cks-mcp": {
      "command": "/absolute/path/to/cks-mcp"
    }
  }
}

Restart Claude Desktop (Cmd+Q, then reopen). Done. No API keys, no cloud setup, no extra services. Just ask "Use cks-mcp to..." and start building knowledge you can actually verify.

GitHub · Documentation · PyPI

Git changed how we trusted source code. We think AI now needs the same thing for knowledge.

What's New in CKS: Semantic Search, Type Safety, and Graph Visualization for LLMs

Vladyslav — Mon, 27 Jul 2026 15:52:44 +0000

Give an LLM a fact, and it'll invent a citation. Give it a knowledge backbone, and it'll finally shut up and verify.

Last week, we introduced Canonical Knowledge Structure (CKS) — an open-source platform that gives LLMs a verifiable knowledge backbone. We showed how it catches fake citations and enables time-travel debugging.

This week, we've been busy. We shipped 10 new tools, bringing the total to 18. We added real semantic search with embeddings, ontology validation that catches nonsense like "Earth orbits Pasta," and graph visualization that renders directly in Claude Desktop. Let me show you what's new — with live experiments, as always.

What We Shipped (July 21–27)

Feature	What it does
`search_semantic`	Find objects by meaning, not keywords. Uses HuggingFace embeddings.
`visualize_graph`	Export any subgraph as a Mermaid diagram — Claude renders it natively.
`explain_diff`	Natural-language summary of what changed between two versions.
`suggest_evolution`	AI-assisted operation building — reduces trial-and-error.
`query_subgraph` (compact mode)	Extract neighbourhoods in token-efficient format.
`merge_branch` (resolutions)	Partial three-way merge — resolve one conflict, commit the rest.
`update_object`	In-place object edits without cascading relation deletions.
`type_hierarchy` extension	Declare type taxonomies (Planet is-a CelestialBody).
`relation_type` extension	Restrict which relation types can connect which object types.
`get_metrics`	Runtime statistics: invocation counts and execution times.

Experiment 4: Semantic Search That Actually Works

We built a knowledge graph about renewable energy with 3 objects: Solar Power, Wind Power, and Energy Storage. Then we asked the model to search for "battery storage systems for renewable energy" — without specifying any object IDs.

The system encoded the query with the same HuggingFace model used to index the objects, performed a cosine-similarity search, and returned Energy Storage as a match. No keyword matching — pure semantic understanding.

search_semantic(query="battery storage systems for renewable energy")
→ matched_seeds: ["energy-storage", "solar-power", "electricity"]
→ scores: {"energy-storage": 0.87, "solar-power": 0.72, "electricity": 0.68}

The scores tell you exactly how confident the match is. Energy Storage came first because its description contained "batteries," "storage," and "systems" — exactly the concepts the query was looking for.

Experiment 5: Catching "Earth Orbits Pasta"

This one's my favourite. We built a small astronomy graph with a type hierarchy: Planet, Moon, and Star are all subtypes of CelestialBody. We declared a rule that orbits relations can only connect CelestialBody objects.

Then we tried to add a relation: Earth → orbits → Pasta (where Pasta is type Food).

The system immediately flagged it:

CKS-EXT-RELATION-TYPE: Relation 'rel-earth-pasta' of type 'orbits' has target
'pasta' of type 'Food', which is not one of the allowed target types
['Star', 'Planet'] (or a declared subtype).

The best part? We then called visualize_graph and got this Mermaid diagram rendered directly in the chat:

The violating edge (Earth→Pasta) is right there, next to the valid orbits. You can literally see the error.

Experiment 6: What Changed Between Versions?

We created a simple graph, modified one object's description with update_object, and asked explain_diff to summarise the difference.

Old behaviour: "Added 1 object, Removed 1 object" — misleading, because nothing was actually added or deleted.

New behaviour:

Modified 1 object(s): Natural Selection (Concept)
Re-linked 1 relation(s) with no actual change

The tool correctly recognised that the object was modified in-place, and the relation touching it was just re-linked — not deleted and re-created. This matters when you're tracking changes across dozens of versions and need accurate summaries, not phantom add/remove noise.

60-Second Upgrade

pip install --upgrade cks-mcp

Restart Claude Desktop. All 18 tools are immediately available.

What's Next

We're working on:

detect_contradictions — logical inconsistency detection across the graph
ingest_document — fetch a URL, extract entities, build a verified knowledge graph
Docker distribution and PostgreSQL backend for production deployments
Local embeddings via fastembed (no API key needed)

The Bigger Picture, One Week Later

Last week, CKS had 8 tools and a basic anti-hallucination mechanism. Today it has 18 tools, real semantic search, type-safe ontologies, graph visualisation, field-level auto-merge, and 94 tests.

The mission hasn't changed: LLMs generate. CKS verifies. But now it also searches, explains, visualises, and catches nonsense before it enters your knowledge base.

GitHub: github.com/Deus-corp

Documentation: deus-corp.github.io/cks-core

In one week, we turned an AI lie detector into a full knowledge laboratory — with a search engine, a type checker, and a whiteboard. Imagine what a month could do.

What If Your LLM Could Never Make Up a Fake Source Again?

Vladyslav — Tue, 21 Jul 2026 16:16:41 +0000

We built an open-source platform that gives AI models a "canonical knowledge backbone" — and it caught our test model fabricating citations in its very first run.

The Problem: Your LLM Is a Fantastic Liar

Let's be honest — we've all been there. You ask an AI assistant to write a report, and it produces a beautifully formatted document with a citation to "Dr. Z, Journal of Advanced Studies, 2025." The problem? Dr. Z doesn't exist. The journal doesn't exist. The AI just hallucinated an entire academic career to make its argument sound more convincing.

This isn't a bug in a specific model. It's a fundamental property of how large language models work: they generate plausible text, not verified facts. They're storytellers, not librarians.

But what if there was a way to give LLMs a "canonical knowledge backbone" — a system where every fact, every source, every relationship between concepts had to be explicitly structured, validated, and cryptographically signed before the model could claim it as true?

That's exactly what we built. It's called Canonical Knowledge Structure (CKS), and it's fully open-source.

How CKS Works: Three Layers, One Mission

CKS isn't a single tool — it's an ecosystem of three components, each with a clear responsibility.

cks-core — The Semantic Engine

The brain of the operation. An immutable, version-controlled graph database for knowledge. Every fact gets a unique ID. Every relationship is validated against formal constraints (no dangling references, no duplicate identities, no circular derivations). Once a fact is created, it can never be changed — only a new version can be created.

cks-runtime — The Operational Layer

The body that manages the lifecycle. Sessions, transactions, version history, and event streams. Want to know who changed what and when? The runtime tracks it all. Want to roll back to a previous state? One command.

cks-mcp — The MCP Server

The interface between LLMs and the knowledge backbone. Eight tools that any MCP-compatible AI can use: validate, serialize, explain, evolve, verify sources, list versions, compare versions, and three-way merge.

Live Experiments: We Tested It So You Don't Have To

We ran Haiku 4.5 through a series of experiments using CKS tools via Claude Desktop. Here's what happened.

Experiment 1: Catching a Fake Citation

We asked the model to create a knowledge graph about Artificial Intelligence, then added a reference to a non-existent source. When we validated the structure with the embedding_projection extension enabled, the system immediately flagged the phantom reference with a CKS-EXT-EMBEDDING-PROJECTION diagnostic. The model couldn't bluff its way through — the system mechanically detected the dangling reference.

Experiment 2: Time-Travel Debugging

We evolved the graph (added the concept "Transformers"), then asked the model to list all versions, compare them with a structural diff, and revert to the original state. The model successfully rolled back, and a subsequent serialization confirmed "Transformers" had completely disappeared.

Experiment 3: Three-Way Merge

We created a base graph, then independently evolved two branches — one adding "Parrot" linked to "Dog," the other adding "Hamster" linked to "Cat." The merge succeeded automatically because the changes didn't conflict. Then we tried a conflicting scenario: both branches modified the same property of the same object. The merge correctly refused and returned a structured conflict report.

Getting Started in 60 Seconds

pip install cks-mcp # pulls cks-runtime and cks-core automatically

Then add this to your claude_desktop_config.json:

{
  "mcpServers": {
    "cks-mcp": {
      "command": "cks-mcp"
    }
  }
}

Restart Claude Desktop. Done — your LLM now has a verifiable knowledge backbone.

Full documentation: deus-corp.github.io/cks-core

The Bigger Picture

We believe the next frontier for LLMs isn't bigger models or longer context windows — it's verifiable knowledge infrastructure. A layer that sits between the model and its output, ensuring that every claim can be traced to its origin, every source can be checked, and every change is auditable.

CKS is our open-source contribution to that vision. It's MIT-licensed, production-ready, and actively maintained.

We're looking for contributors, feedback, and real-world use cases. If you're working on RAG pipelines, knowledge graphs, or AI verification — we'd love to hear from you.

GitHub: github.com/Deus-corp
Documentation: deus-corp.github.io/cks-core

LLMs generate. CKS verifies.