Skip to content
CKS Documentation

ANALYSIS-001

Runtime Dependencies on CKS Core

Section titled “Runtime Dependencies on CKS Core”

Status: Draft

Category: Architectural Analysis

Applies to: CKS Runtime Standard

1. Purpose

Section titled “1. Purpose”

This document analyses the architectural relationship between CKS Runtime and CKS Core.

Its purpose is to identify:

  • the responsibilities permanently owned by CKS Core;
  • the responsibilities delegated to CKS Runtime;
  • architectural boundaries between the two standards;
  • immutable dependency rules that shall remain valid throughout the evolution of the CKS ecosystem.

This document establishes the architectural foundation for every subsequent Runtime specification.

All Runtime specifications shall remain consistent with the dependency rules and responsibility boundaries defined herein.

2. Scope

Section titled “2. Scope”

This document defines architectural ownership and dependency rules.

It does not define:

  • Runtime APIs;
  • storage implementations;
  • execution models;
  • transport protocols.

Those topics are specified separately within the Runtime Standard.

3. Referenced Core Specifications

Section titled “3. Referenced Core Specifications”

CKS Runtime depends on the canonical semantics defined by the CKS Core Standard, including (but not limited to):

  • CKS-001 — Canonical Knowledge Model
  • CKS-002 — Canonical Object Model
  • CKS-003 — Canonical Relation Model
  • CKS-004 — Canonical Serialization
  • CKS-005 — Validator Specification
  • CKS-006 — Reference Engine
  • CKS-007 — Canonical Knowledge Interface
  • CKS-008 — Reference Conformance Specification

Future Core specifications automatically extend this dependency unless explicitly stated otherwise.

These specifications collectively define the semantic contract consumed by CKS Runtime.

4. Fundamental Terminology

Section titled “4. Fundamental Terminology”

CKS Runtime shall adopt the canonical terminology defined by CKS Core.

Runtime shall not redefine existing semantic concepts.

Whenever terminology differs between Runtime documents and Core documents, the Core definition shall prevail.

Examples include:

  • KnowledgeStructure
  • KnowledgeObject
  • CanonicalRelation
  • ObjectIdentity
  • Validation
  • Constraint
  • Diagnostic
  • Evolution
  • Serialization

The Core Standard remains the single authoritative source of terminology.

5. Architectural Principle

Section titled “5. Architectural Principle”

The CKS ecosystem is divided into independent architectural layers.

Applications
        │
        ▼
Adapters
        │
        ▼
CKS Runtime
        │
        ▼
CKS Core

Each layer has a single architectural responsibility.

Each layer may depend only on the layer immediately below it.

Dependencies flow downward.

Semantic authority originates exclusively from CKS Core. Operational behaviour originates from CKS Runtime.

5.1 Architectural Authority Model

Section titled “5.1 Architectural Authority Model”

The CKS ecosystem defines three authority domains.

Semantic Authority

Section titled “Semantic Authority”

Owned exclusively by CKS Core.

Includes:

  • knowledge meaning;
  • validation;
  • constraints;
  • canonical identities.

Operational Authority

Section titled “Operational Authority”

Owned exclusively by CKS Runtime.

Includes:

  • lifecycle;
  • sessions;
  • transactions;
  • persistence;
  • history.

Exposure Boundary

Section titled “Exposure Boundary”

Owned by Adapters.

Includes:

  • protocol translation;
  • external representation;
  • transport concerns.

No authority domain may absorb responsibilities belonging to another.

6. Responsibilities of CKS Core

Section titled “6. Responsibilities of CKS Core”

CKS Core exclusively owns the semantic definition of knowledge.

Core responsibilities include:

  • canonical knowledge model;
  • canonical object model;
  • canonical relation model;
  • canonical identities;
  • canonical serialization;
  • canonical parsing;
  • validation framework;
  • canonical constraints;
  • canonical semantic diagnostics model;
  • knowledge evolution;
  • semantic invariants;
  • conformance requirements.

Core defines what knowledge is.

Core does not define how knowledge is executed, stored, managed, or transported.

7. Responsibilities of CKS Runtime

Section titled “7. Responsibilities of CKS Runtime”

CKS Runtime exclusively owns the operational management of Canonical Knowledge Structures.

Runtime responsibilities include:

  • session management;
  • lifecycle management;
  • transaction management;
  • version history;
  • persistence orchestration;
  • storage abstraction;
  • runtime diagnostics aggregation;
  • explainability orchestration;
  • operational execution environment;
  • runtime state management.

Runtime defines how knowledge is managed.

Runtime never changes what knowledge means.

8. Forbidden Responsibilities

Section titled “8. Forbidden Responsibilities”

CKS Runtime shall never own or redefine:

  • canonical semantics;
  • canonical identities;
  • canonical validation;
  • canonical constraints;
  • canonical serialization format;
  • canonical evolution rules;
  • canonical diagnostics model;
  • duplicate semantic behaviour already defined by CKS Core;
  • become an alternative semantic authority.

These responsibilities permanently belong to CKS Core.

9. Dependency Rules

Section titled “9. Dependency Rules”

The dependency direction is immutable.

The following rules shall always hold:

  • CKS Core shall not depend on Runtime.
  • Runtime may depend on Core.
  • Adapters may depend on Runtime.
  • Applications should interact with the ecosystem through Adapters.
  • Direct Application dependency on Core or Runtime internals is discouraged.

Reverse dependencies are prohibited.

9.1 Semantic Integration Boundary

Section titled “9.1 Semantic Integration Boundary”

CKS Runtime communicates with CKS Core exclusively through the public semantic API exposed by CKS Core.

Runtime shall never depend upon internal implementation details of CKS Core.

Official Runtime implementations may provide automatic integration with the official CKS Core package.

Such integration is an implementation convenience rather than an architectural dependency.

The reference implementation of this integration is provided by the cks-runtime-core package, which contains CksCoreAdapter — a concrete implementation of CoreInterface that delegates every semantic call to cks-core.

The architectural dependency remains:

Runtime
        │
        ▼
Public CKS Core API
        │
        ▼
CKS Core

The Runtime Standard standardizes the operational contract.

The CKS Core Standard standardizes the semantic contract.

The public API constitutes the only supported architectural boundary between the two standards.

10. Compatibility Model

Section titled “10. Compatibility Model”

Conforming Runtime implementations shall operate exclusively on Canonical Knowledge Structures defined by CKS Core.

Runtime shall never require alternative knowledge representations.

A Runtime implementation shall declare the Core Standard versions it supports.

Compatibility shall be evaluated according to declared version relationships.

11. Separation of Concerns

Section titled “11. Separation of Concerns”

Core answers:

What is valid knowledge?

Runtime answers:

How is valid knowledge managed?

Adapters answer:

How is knowledge exposed to external systems?

Applications answer:

What problem is being solved?

No architectural layer shall assume responsibilities belonging to another layer.

12. Architectural Invariants

Section titled “12. Architectural Invariants”

The following architectural invariants are permanent constraints of the CKS ecosystem.

They shall remain valid across all future revisions of the Runtime Standard.

  • CKS Core owns semantics.
  • CKS Runtime owns operational lifecycle management.
  • Runtime shall never modify Core semantics.
  • Core shall never depend on Runtime.
  • Runtime shall operate exclusively on Canonical Knowledge Structures.
  • Adapters shall expose Runtime functionality without redefining Runtime behaviour.
  • Applications shall consume the ecosystem without changing canonical semantics.

These invariants constitute the constitutional architecture of the CKS ecosystem.

13. Long-Term Evolution

Section titled “13. Long-Term Evolution”

The CKS ecosystem is intended to evolve as a family of complementary standards.

CKS Standards


├── Core Standard
├── Runtime Standard
├── MCP Standard
├── CLI Standard
├── HTTP Standard
└── Conformance Suite

Each standard shall define a distinct architectural responsibility while preserving interoperability through the canonical semantics established by CKS Core.

14. Non-Negotiable Boundary

Section titled “14. Non-Negotiable Boundary”

The following boundary shall never be violated:

CKS Core
    defines meaning


          │


          ▼


CKS Runtime
    orchestrates semantic operations
    manages lifecycle


          │


          ▼


Adapters
    expose Runtime capabilities

Any implementation that moves semantic ownership outside CKS Core is not a conforming CKS implementation.

15. Summary

Section titled “15. Summary”

CKS Core is the semantic foundation of the ecosystem.

CKS Runtime is the canonical execution environment built upon that foundation.

Runtime orchestrates semantic services provided by CKS Core without becoming a semantic authority itself.

The semantic authority of the CKS ecosystem permanently resides in CKS Core.

This separation enables multiple Runtime implementations, multiple transport adapters, and future ecosystem growth while preserving a single canonical definition of knowledge.