Concepts

This document introduces the fundamental concepts of the Canonical Knowledge Structure (CKS).

The concepts presented here are independent of any programming language or implementation and form the semantic foundation of the entire CKS ecosystem.

Knowledge

CKS begins with a simple observation:

Knowledge exists independently of the way it is represented.

A scientific theorem remains the same whether it is written in:

a book,
a PDF,
JSON,
Python,
a database,
or a knowledge graph.

Representations change.

Knowledge does not.

The purpose of CKS is to describe knowledge itself rather than any particular representation.

Representation

A representation is any concrete encoding of knowledge.

Examples include:

natural language;
source code;
JSON;
XML;
SQL databases;
graph databases;
RDF;
ontologies.

Representations are useful because they allow knowledge to be stored, transmitted, or processed.

However, representations are not the knowledge itself.

Canonical Knowledge Structure

A Canonical Knowledge Structure (CKS) is an implementation-independent semantic model describing knowledge.

It provides a single canonical representation that can be mapped to many concrete formats.

Knowledge
      │
      ▼
Canonical Knowledge Structure
      │
 ┌────┼──────────────┐
 ▼    ▼              ▼
JSON Python      Database

The canonical structure preserves meaning regardless of the representation used.

Knowledge Object

A Knowledge Object is the fundamental semantic unit of CKS.

Every object represents one identifiable piece of knowledge.

Examples include:

a definition;
a theorem;
an axiom;
an algorithm;
a proof;
a concept;
a dataset.

Each Knowledge Object consists of two components:

an identity;
a semantic structure.

Object Identity

Every Knowledge Object possesses a canonical identity.

The identity uniquely identifies the object independently of its storage location.

An identity contains:

identifier;
semantic type;
human-readable name.

Example:

id    : theorem-001
type  : Theorem
name  : Representation Independence

Canonical identities allow multiple implementations to refer to the same knowledge without ambiguity.

Semantic Structure

The semantic structure contains the observable content of a Knowledge Object.

The structure may include:

properties;
attributes;
metadata;
domain-specific information.

The interpretation of the structure depends on the object’s semantic type.

Canonical Relation

Knowledge rarely exists in isolation.

Objects are connected through semantic relationships.

CKS represents these relationships using Canonical Relations.

Examples include:

derives;
depends_on;
references;
contradicts;
extends;
proves.

A Canonical Relation is itself a Knowledge Object.

This allows relations to possess identities and semantic properties like every other object.

Knowledge Structure

A Knowledge Structure is an immutable collection of Knowledge Objects.

It represents a coherent body of knowledge.

The structure preserves:

identities;
relations;
semantic integrity.

Knowledge Structures are the primary objects processed by the reference engine.

Structural Equivalence

Two Knowledge Structures are structurally equivalent when they expose the same observable semantic structure.

Structural equivalence is independent of:

memory layout;
serialization format;
implementation language;
execution environment.

This principle allows independent implementations to interoperate reliably.

Representation Independence

Representation Independence is one of the central principles of CKS.

The observable meaning of knowledge must not depend on:

JSON formatting;
programming language;
database schema;
network protocol.

Different representations may describe the same canonical knowledge.

Determinism

Every canonical operation must be deterministic.

Identical inputs always produce identical observable outputs.

For example:

serialization;
validation;
comparison;
inspection.

Determinism ensures reproducibility across implementations.

Observational Purity

Canonical operations are observationally pure.

Executing an operation never modifies the observed Knowledge Structure.

For example:

validate(structure)

must never change structure.

This property makes canonical operations predictable and safe to compose.

Structural Evolution

Knowledge Structures are not static; they can evolve through admissible structural transformations.

Structural evolution is governed by Primitive Structural Extensions (PSE) — minimal, irreducible transformations that preserve all canonical invariants.

Two fundamental classes of operators exist:

Genesis — introduces new Knowledge Objects or Canonical Relations, expanding the structure.
Decay — removes existing objects or relations, simplifying the structure.
Mutation — changes an existing object in place (updating its structure, renaming it, or resolving a conflict between competing inferences) without altering its identity or cascading deletions to dependent relations.

All evolution operators are governed by formal contracts specifying preconditions, postconditions, and invariant obligations. Composition of operators yields complex developmental trajectories.

Structural evolution ensures that knowledge can grow, adapt, and be refined while remaining canonically valid.

The formal theory of structural evolution is defined in CKS‑004.

Inference and Belief Revision

Not every Knowledge Object is a base fact. An InferenceStep records a conclusion together with the premises it was drawn from, the operator used to derive it, a confidence score, and an optional justification — knowledge about how a belief was reached, not just the belief itself.

Because independent inference paths can reach the same conclusion with different confidence, CKS treats this as an ordinary, resolvable disagreement rather than a structural error: it is reported at WARNING severity, ranked by entrenchment, and resolved by explicitly superseding the losing steps — never by silently overwriting them. The superseded steps remain in the structure, preserving the belief’s revision history.

This principle — that conflicting beliefs are data, not errors — is what allows a Knowledge Structure to represent a reasoning process that changes its mind over time while staying canonically valid.

Validation

Validation evaluates whether a Knowledge Structure satisfies the constraints defined by the CKS specifications.

The validation process produces a ValidationResult containing:

validity status;
diagnostics;
evaluated constraints;
implementation-independent metadata.

Validation never modifies the original structure.

Serialization

Serialization converts a Knowledge Structure into its canonical JSON representation.

Deserialization performs the inverse operation.

The reference implementation guarantees canonical round-trip behaviour:

parse(serialize(S))

is structurally equivalent to

Reference Engine

The Reference Engine is the canonical implementation of the operations defined by the CKS specifications.

It provides implementation-independent behaviour for:

construction;
serialization;
validation;
comparison;
inspection;
projection;
evolution.

Applications typically interact with the engine through the public interface rather than directly.

Canonical Knowledge Interface

The Canonical Knowledge Interface (CKI) defines the public operations exposed by CKS implementations.

Examples include:

construct()
parse()
serialize()
validate()
diagnose()
inspect()
compare()
extract()
project()
evolve()

Every implementation should expose behaviour consistent with the CKS specifications.

CLI and Reference Corpus

The CKS ecosystem provides a command-line interface (CLI) for interacting with Knowledge Structures from the terminal. Commands include validate, parse, inspect, evolve, convert, export, migrate, schema, and plugin.

A Reference Corpus of canonical examples (valid and invalid structures) is maintained under examples/corpus/ to serve as a test suite and a learning resource.

Summary

The concepts introduced in this document form the semantic vocabulary of the CKS ecosystem.

The following document, Architecture, explains how these concepts are realised by the Python reference implementation while preserving implementation independence.