Distributed Cognitive Network

A Reference Architecture for Accumulating Cognition

The Distributed Cognitive Network (DCN) is an architecture in which a persistent local Mind coordinates specialized intelligences, records successful cognitive organization as K-lines, verifies external execution when required, and compiles expensive deliberation into reusable cognitive artifacts.

The central thesis is:

The scarce resource is not tokens. It is proven problem-solving capability.

The architecture separates cognition, authority, evidence, economics, and execution so each can evolve independently while remaining interoperable through the Cognitive ABI.

Reading paths

Architecture: begin with Architectural Principles, then Volumes I, II, V, VI, and VII.

Implementers: read Volumes II, V, VII, VIII, X, XI, and XII alongside the executable schemas and conformance suite.

Economics and verification: read Volumes III, IV, IX, and X.

Executive overview: read Volume XIII after Architectural Principles.

Canonical layers

Mind / Applications
       │
DCN Runtime + Cognitive Kernel
       │
Kline + Cognitive Compiler
       │
Cognitive ABI
       │
Experts / Artifacts / MCP / A2A
       │
Actum Compute
       │
Actum + Evidence Systems

The network shares cognition; each local Mind decides what becomes active.

Architectural Principles

This document defines the invariants that govern the Distributed Cognitive Network specification. Later volumes may refine mechanisms but MUST NOT silently violate these principles.

1. Local cognitive sovereignty

The network shares cognition; the local Mind decides what becomes active. Publication, popularity, Actum finality, market ranking, or external endorsement MUST NOT by themselves activate cognition locally.

2. World state is authoritative

Agencies, experts, K-lines, and models reason about world state. They do not independently own authoritative reality. State change follows proposal, validation, authorization, and commit.

3. Proposal before mutation

Cognitive execution SHOULD produce semantic Patch Proposals rather than directly mutating shared state. Side effects require the authority appropriate to the action.

4. Cognition is not authority

A K-line describes how a class of problems may be solved. It does not grant permission to perform the actions appearing in that solution. Capability, policy, delegation, and concrete authorization remain separate.

5. Capability before vendor

Reusable cognition SHOULD express capability requirements rather than unnecessarily binding to vendors. Concrete provider and model identity remain first-class execution facts when they materially affect quality, assurance, or price.

6. Template, episode, and artifact are distinct

KLineTemplate defines reusable cognitive meaning and topology. KLineEpisode records what actually happened. KLineArtifact implements that cognition for a particular execution environment. Implementations MUST preserve this distinction.

7. Evidence is not truth

Evidence supports claims. Actum can establish provenance, finality, and integrity of those claims. Neither evidence nor finality automatically establishes universal truth.

8. Evidence forms a graph

Evidence MAY depend on, verify, derive from, contradict, or supersede other evidence. Canonical cognition Acts therefore reference an Evidence Graph rather than assuming a single proof object.

9. Trust is local and contextual

Trust is not a universal scalar embedded in globally immutable protocol objects. Each Mind applies its own trust policy to publishers, experts, evaluators, artifacts, and evidence.

10. Admissibility precedes optimization

Missing authority, mandatory evidence, privacy constraints, jurisdiction constraints, or minimum trust cannot be compensated for by lower price, lower latency, or higher expected quality.

11. System 1 is provisional compiled cognition

System 1 is not permanent precedent. K-lines and artifacts decay, drift, require revalidation, may be superseded, and can be rejected by System 2 when novelty or surprise warrants it.

12. System 2 preserves the frontier

The runtime MUST preserve an escalation path for novel, ambiguous, contradictory, or surprising situations. Reuse MUST NOT eliminate exploration.

13. Cognitive compilation preserves semantics and constraints

The Cognitive Compiler may reduce cost, latency, energy, network use, or cognitive complexity, but MUST NOT silently weaken required quality, authority, privacy, safety, or explainability.

14. Compilation is plural

The Cognitive Compiler is implemented through a Compiler Society: specialized compilers may perform topology simplification, distillation, rule extraction, quantization, mobile optimization, benchmarking, and verification.

15. Cognitive Capital is accumulated, not merely consumed

The network seeks to transform scarce System-2 cognition into evaluated, reusable System-1 cognition. Episodes produce evidence; K-lines organize reusable cognition; artifacts make it executable; Cognitive Capital is the durable stock of that validated utility.

16. Actum Compute is the intelligence market

Actum Compute discovers, prices, matches, procures, and settles scarce cognitive capability, evaluation, evidence, artifacts, and compute. It does not decide what cognition the local Mind should activate.

17. Actum is the verifiable action substrate

Actum records finalized claims and state transitions with authority, evidence, commitments, lineage, and settlement. Actum is not the cognitive scheduler and does not determine local trust.

18. External model assurance is explicit

Where provider or model quality is part of the contract, execution evidence SHOULD prove the strongest defensible claim available, such as authenticated provider endpoint, disclosed model label, request binding, response binding, and result binding. TLSNotary evidence MUST NOT be described as proving undisclosed server internals.

19. Installation is not authorization

Installing an Agent Plugin or discovering an MCP/A2A capability does not grant spend authority, execution authority, data access, or permission to publish capacity.

20. Privacy is independently composable

Prompts, responses, identities, prices, evaluations, reputation, and settlement data SHOULD support selective disclosure and confidential verification where possible. ZeroK is one mechanism for proving required predicates without revealing unnecessary witnesses.

21. History is immutable; current interpretation is mutable

Execution, evaluation, promotion, compilation, publication, supersession, and settlement Acts remain historical. Current world state, local trust, active artifacts, and routing preferences may evolve.

22. Supersession replaces destructive rewriting

New cognition SHOULD supersede old cognition without erasing lineage. Historical episodes MUST remain attributable to the exact templates, artifacts, experts, and evidence actually used.

23. The Cognitive Kernel is an allocator, not a genius model

The Cognitive Kernel schedules attention, selects System 1 or System 2, manages resource budgets, resolves capabilities, protects authority boundaries, and maintains coherence. General reasoning is supplied by the broader Society of Experts when required.

24. Local-first, offline-capable operation

A Mind SHOULD remain useful without network access. Local artifacts, local memory, local authority, and deferred synchronization are architectural priorities rather than fallback afterthoughts.

25. Interfaces should remain implementation-neutral

The Cognitive ABI, K-Line Protocol, Actum Compute, and Actum profiles SHOULD expose semantic contracts that can survive changes in model vendors, programming languages, runtimes, storage engines, and transport mechanisms.

Glossary

This glossary is normative for terminology unless a protocol volume explicitly defines a narrower meaning.

Act — An immutable, attributable, evidence-bearing record of an authorized or claimed state transition finalized or prepared for finalization on Actum.

Actum — The verifiable action substrate providing commitments, evidence references, lineage, finality, settlement state, and asset transfer.

Actum Compute — The capability-resolution and economic layer for expert execution, K-line artifacts, evaluation, evidence, and raw compute.

ActivationPlan — A pre-execution plan binding a KLineTemplate to context, candidate capabilities, budgets, authority requirements, and validation rules.

Agency — A bounded, schedulable cognitive process operating under the Cognitive Kernel and producing proposals rather than independently owning authoritative state.

ArtifactOffer — An Actum Compute offer to license, distribute, or execute a KLineArtifact.

Assurance Vector — A structured set of independent evidence statuses such as provider identity, model label, request binding, result binding, authority, freshness, and finality.

Capability — A semantic description of problem-solving or action-producing competence independent of a particular supplier.

CapabilityRequirement — A typed demand object expressing required capability, quality, evidence, trust policy, privacy, jurisdiction, latency, cost, energy, and execution constraints.

Cognitive ABI — The common runtime interface through which cognitive components exchange typed demands, bindings, executions, proposals, evaluations, episodes, and learning signals.

Cognitive Capital — Evaluated, reusable cognition whose durable utility can be deployed, distributed, licensed, measured, and further compiled.

Cognitive Compiler — The subsystem that transforms successful System-2 cognition into progressively cheaper System-1 implementations while preserving required semantics and constraints.

Cognitive Kernel — The local control plane that schedules attention and cognitive processes, chooses System 1 or System 2, manages resource and authority boundaries, and coordinates state transitions.

Compiler Society — The set of specialized compiler agencies responsible for transformations such as topology simplification, distillation, rule extraction, quantization, benchmark generation, and mobile optimization.

Distributed Cognitive Network (DCN) — The federation of Minds, experts, K-lines, artifacts, markets, evaluators, evidence services, and execution environments that share cognition without requiring a single global trust authority.

Evidence Graph — A directed graph of evidence nodes and relationships such as supports, verifies, derived-from, contradicts, references, or supersedes.

EvaluationAct — An Act recording that a defined evaluation protocol was applied to a subject under a declared environment and distribution.

EvaluationClaim — A contextual quality claim linking a subject to an evaluation protocol, distribution, environment, result, evaluator, and evidence.

EvaluationProtocol — A reproducible definition of dataset or distribution commitments, sampling, metrics, scoring, contamination policy, environment, and acceptance thresholds.

ExecutionAct — An Act recording a concrete realization of a requested capability, its authority, bindings, evidence, and resulting state commitments.

ExecutionClass — A market-level definition of execution properties that materially affect value, such as provider, model class, tools, privacy, and required evidence.

Expert — Any entity capable of satisfying a cognitive capability, including models, humans, tools, organizations, agents, workflows, or K-line artifacts.

ExpertBinding — The concrete late-bound selection of an expert or artifact that satisfies a CapabilityRequirement for an execution.

ExpertOffer — An Actum Compute advertisement of an expert's available capabilities, execution classes, quality evidence, capacity, pricing, and settlement terms.

K-line — A reusable organization of cognition for a class of situations. The protocol represents it through templates, episodes, and artifacts rather than as a prompt or vendor-specific workflow.

KLineArtifact — A compiled executable implementation of a K-line for a particular environment or optimization profile.

KLineEpisode — An immutable record of one concrete K-line execution, including actual expert bindings, evidence, cost, latency, context commitments, and outcome.

KLineTemplate — The reusable semantic and typed cognitive topology defining triggers, capability requirements, control/data flow, validation, budgets, authority requirements, and fallbacks.

Mind — A persistent local or organizational cognitive system containing world state, memory, goals, trust views, K-lines, artifacts, authority context, and the Cognitive Kernel.

Novelty — A pre-execution estimate of how unfamiliar a problem or context is relative to known cognition.

Patch Proposal — A semantic proposal for changing authoritative world state, generated by cognition and subject to validation and authorization before commitment.

PromotionAct — An Act recording that a KLineTemplate satisfied a defined promotion policy and became eligible for System-1 use in the relevant scope.

Semantic Fingerprint — A non-cryptographic representation for discovering semantically related cognition. It does not replace content hashes or authored object identity.

Society of Experts — The heterogeneous set of specialized cognitive resources that a Mind can compose to solve problems.

Surprise — A post-execution measure of mismatch between expected and observed behavior, used to trigger revalidation, demotion, or System-2 reopening.

System 1 — Reusable, sufficiently validated cognition eligible for low-cost routine execution, including K-lines and compiled artifacts.

System 2 — Deliberative and exploratory cognition used for novelty, ambiguity, conflict, failure, and frontier problem solving.

TLSNotary — An external evidence mechanism capable of proving authenticated selectively disclosed TLS communication such as provider endpoint and request/response fields; it does not prove undisclosed server internals.

VSTP — The semantic state-transition model binding prior state, intent/action, authority, evidence, and resulting state.

World Model — The persistent semantic representation of beliefs, entities, relationships, observations, goals, plans, episodes, authority, and procedural cognition maintained by a Mind.

ZeroK — The confidential verification layer used to prove selected predicates over private execution, market, evaluation, reputation, or settlement data without unnecessary disclosure.

Distributed Cognitive Network

Volume I — Vision, Architecture, and System Boundaries

Draft Specification 0.1

1. Purpose

This specification defines a distributed cognitive architecture in which intelligence is produced not by a single monolithic model, but by a society of specialized experts, reusable cognitive structures, local personal context, verifiable external execution, and a continuously learning routing system.

The central thesis is:

The scarce resource is not tokens. It is proven problem-solving capability.

Individual frontier models, specialist models, tools, humans, deterministic programs, K-lines, and compiled cognitive artifacts are treated as experts or capabilities within a larger cognitive network.

The system discovers which combinations of capabilities successfully solve classes of problems, records those executions as episodes, evaluates them, promotes successful patterns into reusable K-lines, and progressively compiles expensive System-2 reasoning into cheaper System-1 cognition.

The objective is therefore not merely to increase model capability.

The objective is to continuously transform:

scarce intelligence → validated cognition → reusable cognitive capital → efficient local execution.

2. Terminology

2.1 Distributed Cognitive Network

The Distributed Cognitive Network, abbreviated DCN, is the complete network of:

personal Minds;
K-lines;
experts;
cognitive artifacts;
evaluation services;
Actum Compute markets;
evidence providers;
execution environments;
capability registries;
shared cognitive knowledge.

The DCN is federated.

There is no single canonical global brain and no requirement that every participant trust the same experts, evaluations, or K-lines.

Each Mind maintains its own local trust view and determines what cognition it will activate.

Architectural invariant:

The network shares cognition. The local Mind decides what becomes active.

2.2 Mind

A Mind is a persistent personal or organizational cognitive runtime.

A Mind owns:

world state;
memory;
goals;
active plans;
personal K-lines;
cached external K-lines;
expert reputation;
trust policies;
authority context;
local cognitive artifacts;
current execution state.

A Mind is not equivalent to an LLM.

An LLM is one possible expert used by a Mind.

A Mind may operate even when no frontier LLM is active.

2.3 Expert

An Expert is any capability-producing entity that can participate in cognition.

Examples include:

a frontier coding model;
a medical specialist model;
a local fine-tuned model;
a retrieval agent;
a theorem prover;
a symbolic reasoning engine;
a deterministic program;
an MCP capability;
another Mind;
a human expert;
a K-line artifact.

Experts are described primarily by capability rather than vendor identity.

Example:

capability:
    software_engineering

quality_floor:
    0.94

evidence:
    provider_authenticated

privacy:
    remote_allowed

At execution time this capability could resolve to Codex, Claude, a local model, a human engineer, or a previously compiled K-line artifact.

3. Core Architectural Thesis

Today's dominant AI architecture can be represented approximately as:

problem
  ↓
large model
  ↓
answer

The DCN replaces this with:

problem
   ↓
Coordinator
   ↓
known K-line?
 /            \
yes            no
 ↓              ↓
System 1     System 2
 ↓              ↓
compiled      discover/
cognition     compose experts
 \              /
  \            /
      execute
         ↓
      evaluate
         ↓
       learn
         ↓
     K-line graph

The intelligence of the system resides increasingly in:

selecting appropriate cognition;
activating appropriate experts;
remembering successful cognitive topology;
validating outcomes;
compiling repeated deliberation;
recognizing novelty;
knowing when previous cognition is no longer appropriate.

4. System 1 and System 2

The architecture explicitly adopts a dual-process model.

4.1 System 1

System 1 contains cognition that is already known, validated, and sufficiently cheap to invoke routinely.

Examples:

deterministic rules;
learned reflexes;
compiled K-line artifacts;
stable expert workflows;
local classifiers;
cached procedural structures;
well-established K-lines.

System 1 optimizes primarily for:

latency;
cost;
locality;
energy use;
predictability.

System 1 must never be assumed permanently correct.

Its cognition is provisional and subject to monitoring, decay, revalidation, supersession, and reopening by System 2.

4.2 System 2

System 2 handles novelty, uncertainty, disagreement, insufficient precedent, and difficult cognition.

System 2 may:

recruit several experts;
search existing K-lines;
combine K-lines;
explore alternative expert topologies;
critique proposed solutions;
perform external retrieval;
invoke frontier models;
request human review;
conduct simulations;
evaluate competing hypotheses;
test solutions.

System 2 is expensive by design.

The purpose of System 2 is not merely to solve the current problem.

Successful System-2 trajectories are candidates for becoming future System-1 cognition.

5. K-lines

K-lines are the central learned cognitive structure.

A K-line is not simply:

a prompt;
a conversation;
a vector embedding;
an LLM trace;
a static workflow.

A K-line represents a reusable organization of cognition that has been learned to address a class of situations.

The normative architecture distinguishes three related objects.

5.1 KLineTemplate

The template defines what the cognition means.

It contains:

KLineTemplate
├── trigger semantics
├── preconditions
├── activation graph
├── data flow
├── control flow
├── capability requirements
├── context requirements
├── authority requirements
├── validation strategy
├── budget policy
├── evidence requirements
├── fallbacks
├── expected outputs
└── lifecycle metadata

A template should normally contain capability requirements rather than fixed commercial vendors.

Example:

independent_critic:
    capability: independent_reasoning
    minimum_quality: 0.93
    required_evidence: verified_execution

not:

independent_critic:
    model: VendorModelX

5.2 KLineEpisode

An episode records what actually happened during one execution.

Example:

Template:
    inherited_cardiomyopathy_workup

Bindings:
    reasoning → Expert A
    evidence → Expert B
    genetics → Model C
    critic → Expert D

Evidence:
    TLSNotary receipt P
    attestation Q

Outcome:
    accepted

Evaluation:
    Protocol E17

Cost:
    €3.82

Latency:
    28s

The episode provides provenance and empirical evidence for whether the template works.

5.3 KLineArtifact

An artifact is a compiled executable implementation of a K-line.

The same KLineTemplate may have many artifacts:

Artifact A
4 remote frontier experts
€7.40 / execution

Artifact B
2 experts + deterministic workflow
€1.10 / execution

Artifact C
local specialist model
€0.04 / execution

Artifact D
mobile classifier + rules
≈ €0

Artifacts may vary by:

hardware;
jurisdiction;
trust requirements;
execution environment;
cost;
energy use;
latency;
privacy;
quality.

The semantic K-line may remain stable while artifacts evolve.

6. The Cognitive Compiler

The Cognitive Compiler is a first-class subsystem implemented as a Compiler Society of specialized compilation agencies.

Its purpose is to transform expensive successful cognition into progressively cheaper implementations while preserving required quality.

The lifecycle is:

DISCOVER
   ↓
REIFY
   ↓
VALIDATE
   ↓
PROMOTE
   ↓
COMPILE
   ↓
DEPLOY
   ↓
MONITOR
   ↓
DECAY
   ↓
REOPEN

The compiler performs two distinct forms of optimization.

6.1 Topological Compilation

Reduce unnecessary cognition.

Example:

7 experts
   ↓
5 experts
   ↓
3 experts
   ↓
deterministic routing + 2 experts

The objective is to identify which cognitive interactions are actually necessary.

6.2 Artifact Compilation

Replace expensive implementations with cheaper equivalents.

Example:

remote frontier experts
        ↓
small fine-tuned model
        ↓
local classifier
        ↓
rules/reflex

A simplified optimization objective is:

[ \min_{\pi} C(\pi) +\lambda L(\pi) +\mu E(\pi) ]

subject to:

[ Q(\pi)\ge Q_{min} ]

where:

(C) = monetary cost;
(L) = latency;
(E) = energy consumption;
(Q) = measured quality.

Energy is explicitly included because cognition should eventually be compilable onto constrained devices such as phones.

7. Cognitive Coverage

Progress should not be measured solely by benchmark scores or model size.

The network seeks to increase cognitive coverage.

For distribution (D):

[ Coverage_{S1}(D)

P_{q\sim D} [ \exists K: K(q) \text{ satisfies required quality using System 1} ] ]

and:

[ Coverage_{Total}(D)

P_{q\sim D} [ \text{the Mind can solve }q ] ]

The difference:

[ Frontier(D)

Coverage_{Total}(D)

Coverage_{S1}(D) ]

represents approximately the region that System 2 can solve but has not yet compiled.

Important system metrics include:

System-1 coverage
Total solve coverage
Frontier size
Novelty rate
System-2 escalation rate
Compilation ratio
Compilation gain
Cost per solved task
Energy per solved task
Artifact locality
K-line reuse
K-line half-life
Failure surprise
Revalidation rate

This creates an empirical framework for measuring the growth of the cognitive network.

8. Cognitive Kernel

The Cognitive Kernel is the Mind's cognitive allocation system.

It should not be designed as another all-knowing LLM.

Its fundamental question is:

What cognition should become active now?

Inputs include:

problem
world state
personal context
known K-lines
available artifacts
available experts
budgets
authority
risk
privacy
device state
novelty
trust

The Cognitive Kernel performs:

trigger matching
K-line retrieval
capability resolution
trust filtering
novelty detection
budget allocation
System-1/System-2 routing

A powerful frontier model may participate when necessary, but routing should increasingly be achievable through cheap models, graph operations, retrieval, deterministic logic, and learned policies.

9. Trust and Admissibility

Trust is not merely another positive term in a utility function.

Candidates that do not satisfy required trust, authority, privacy, evidence, or policy constraints should be excluded before optimization.

Define:

[ \Pi_

{ \pi: Policy(\pi,c)=allow \land Trust(\pi,c)\ge T_{min} \land Evidence(\pi)\supseteq E_{required} } ]

Only then select:

[ \pi^*

\arg\max_{\pi\in\Pi_{admissible}} \left[ Q -\lambda C -\mu L -\rho R -\eta E \right] ]

This establishes a fundamental architectural rule:

Money, speed, or quality cannot compensate for missing authority, evidence, or minimum trust.

10. Evaluation

No K-line, artifact, or expert should possess an unqualified score such as:

success_rate = 97%

Evaluation is always contextual.

10.1 EvaluationProtocol

An EvaluationProtocol defines:

EvaluationProtocol
├── dataset/distribution commitment
├── sample policy
├── scorer
├── metrics
├── contamination policy
├── environment
├── evaluator requirements
└── acceptance thresholds

10.2 EvaluationClaim

An immutable EvaluationClaim contains:

EvaluationClaim
├── subject
├── protocol
├── distribution
├── environment
├── result
├── evidence
├── evaluator
└── timestamp

Therefore a valid statement is:

Artifact A implementing Template K achieved 97.1% under Protocol P on Distribution D in Environment E.

11. Decay, Drift, and Reopening

System-1 cognition must never become immortal precedent.

K-lines and artifacts should support:

validity_window
last_evaluated
environment_signature
distribution_signature
confidence_decay
requires_revalidation
superseded_by
revoked

Possible lifecycle:

candidate
   ↓
validated
   ↓
promoted
   ↓
active
   ↓
degraded
  /   |   \
 /    |    \
revalidate supersede revoke
   |
 active

System 2 must always retain the authority to challenge existing cognition.

A novelty or surprise signal:

[ N(q,c,K) ]

should trigger System-2 escalation when known K-lines fit poorly or produce unexpected outcomes.

The system must be capable of concluding:

Existing precedent should not be trusted for this case.

12. Federation

There is no globally authoritative K-line database.

K-lines are globally shareable, not globally mandatory.

A Mind may discover:

Template K from organization A
Template K' from researcher B
Template K'' from community C

and independently decide:

trusted
experimental
cached
deprecated
blocked

This protects against:

poisoning;
Sybil manipulation;
benchmark gaming;
stale cognition;
correlated failures;
malicious compositions;
popularity bias.

13. Identity and Lineage

Three identities are distinguished.

ArtifactHash

Exact cryptographic content identity.

TemplateID

Immutable authored object identity.

SemanticFingerprint

Similarity representation used to discover semantically related K-lines.

This supports:

K123
├── K123-A
├── K123-B
└── K123-C

without pretending that semantic similarity means cryptographic identity.

14. Kline and SurrealDB

Kline is the cognitive layer.

SurrealDB is the primary local state substrate for the Mind.

Conceptually:

SurrealDB
├── world state
├── episodic memory
├── goals
├── active plans
├── KLineTemplates
├── KLineEpisodes
├── KLineArtifacts
├── expert observations
├── evaluation claims
├── trust views
├── capability cache
└── authority references

The conceptual hierarchy is:

WORLD STATE
what is believed to be true

EPISODIC MEMORY
what happened

K-LINE
how the Mind knows how to think or act
about a class of situations

ARTIFACT
how that cognition is efficiently
implemented today

K-lines are therefore best understood as procedural cognition rather than ordinary memory. Evaluated K-lines, artifacts, episodes, evidence, and lineage collectively contribute to the Mind's Cognitive Capital.

15. Actum Compute

Actum Compute is the economic and capability-resolution layer beneath Kline.

It must not become the Cognitive Kernel.

Its job is to answer:

Given a CapabilityRequirement, which admissible suppliers can provide it, with what evidence, quality, price, latency, and privacy properties?

Actum Compute supports markets for:

expert execution
specialist models
frontier-model execution
raw compute
K-line artifacts
evaluation
verification/evidence
potentially human expertise

16. CapabilityRequirement

The principal interface between Kline and Actum Compute is a capability request.

Conceptually:

CapabilityRequirement
├── capability
├── input schema
├── output schema
├── quality floor
├── required evidence
├── trust policy
├── privacy policy
├── jurisdiction policy
├── maximum latency
├── maximum cost
├── energy preference
├── execution-location policy
└── fallback semantics

Actum Compute returns one or more candidate resolutions.

Kline retains the final routing decision.

Architectural invariant:

Actum Compute discovers and prices admissible cognition. Kline decides what cognition to activate.

17. Expert and Artifact Markets

Actum Compute should support at least two major supply classes.

ExpertOffer

An offer to execute cognition.

Example:

Expert:
    frontier coding expert

Capabilities:
    software_engineering
    debugging
    code_review

Evidence:
    TLSNotary

Price:
    €2.40

Execution:
    remote

ArtifactOffer

An offer to license or execute compiled cognition.

Example:

Artifact:
    KLineArtifact A17

Template:
    inherited_cardiomyopathy_workup

Target:
    iPhone / Apple Silicon

Quality:
    EvaluationClaim E51

Price:
    €20 licence
    €0.001 execution royalty

This allows cognitive capital itself to become economically valuable.

18. Actum

Actum is the verifiable action and finality layer.

Actum should record durable claims and state transitions, including:

ExecutionAct
SettlementAct
EvaluationAct
PromotionAct
SupersessionAct
ArtifactPublicationAct
KLineEpisodeAct

Actum provides:

identity;
commitments;
provenance;
lineage;
evidence references;
authorization records;
finality;
settlement state;
economic transfer.

Actum does not magically establish truth.

It establishes that:

a claim was made;
by a particular principal;
under particular authority;
with particular evidence;
at a particular point in the network's finalized history.

Architectural invariant:

Provenance is not truth.

Kline decides how much local trust to assign to evidence recorded on Actum.

19. Actum Compute and Actum

Actum Compute performs economic coordination.

Actum supplies the verifiable state substrate underneath it.

Typical execution:

Kline
   ↓
CapabilityRequirement
   ↓
Actum Compute
   ↓
ExpertOffer matched
   ↓
JobAssignment
   ↓
expert execution
   ↓
ExecutionEvidence
   ↓
Actum ExecutionAct
   ↓
verified settlement condition
   ↓
Actum SettlementAct

20. TLSNotary and Distill

Remote frontier-model execution creates a trust problem.

A supplier could claim:

This task was executed by the current flagship model.

while actually returning output from:

a cheaper model;
a local model;
a cached answer;
a dummy response.

TLSNotary provides evidence about authenticated external TLS interactions.

For supported execution classes, the evidence layer should bind:

provider endpoint
request commitment
model identifier when authenticated/disclosed
response commitment
execution challenge
freshness
TLS transcript commitment
notary/verifier identity

This makes model identity part of an execution assurance class rather than an unverifiable marketing claim.

TLSNotary does not prove hidden server internals or model weights.

It proves authenticated communication and selectively disclosed values from that communication.

Distill-derived infrastructure should be reused for:

challenge binding;
transcript ingestion;
provider adapters;
canonical hashing;
replay nullifiers;
signed receipts;
selective disclosure processing.

21. ZeroK

ZeroK is the confidential verification layer.

It allows claims to be proven without revealing unnecessary underlying data.

Potential predicates include:

required provider class satisfied

required model class satisfied

execution receipt valid

price <= authorized maximum

seller entitled to settlement

evaluation score >= threshold

artifact evaluated on >= N cases

failure rate < threshold

same execution not previously settled

ZeroK may protect:

prompts;
responses;
buyer identity;
seller identity;
exact provider identity;
commercial pricing;
evaluation data;
reputation history.

Actum can therefore verify the relevant state transition without requiring all sensitive data to become public.

22. Agent Plugins

Agent Plugins provide the primary distribution mechanism for network capabilities.

The plugin layer packages:

skills
+
MCP tools

A plugin may represent:

an expert;
Actum Compute;
Kline federation;
an evaluator;
an artifact;
a donor execution worker;
a specialist capability.

Agent Plugins are a distribution and interface layer.

They do not themselves define:

authority;
trust;
sandboxing;
settlement;
cognitive promotion.

Those responsibilities remain in the appropriate underlying layers.

23. MCP and A2A

MCP is used primarily for tool and capability invocation.

A2A is used for communication between autonomous agents or Minds.

Conceptually:

MCP:
    invoke this capability

A2A:
    negotiate/communicate with this agent

Kline may discover both through the wider capability fabric.

24. Society of Experts

The network should be understood as a Society of Experts.

A problem may activate:

frontier reasoning model
+
local specialist
+
retrieval expert
+
symbolic verifier
+
K-line artifact
+
human reviewer

No single expert needs to possess general intelligence.

The system's capability emerges from:

expert specialization;
routing;
composition;
memory of successful organization;
evaluation;
compilation.

A K-line therefore captures not merely an answer but:

which kinds of cognition should become active together for this class of problem.

25. Economic Flywheel

The network's economic mechanism is:

novel problem
      ↓
scarce cognition required
      ↓
experts earn money
      ↓
successful System-2 episode
      ↓
K-line discovered
      ↓
evaluated
      ↓
promoted
      ↓
Cognitive Compiler
      ↓
cheap artifact
      ↓
massive reuse
      ↓
scarce expert attention moves outward
      ↓
next frontier

The network continuously converts:

scarce intelligence into abundant cognition.

This is the central economic thesis.

26. Cognitive Capital

The system recognizes several economically valuable assets.

Expert labor

Perform new cognition.

K-line templates

Reusable cognitive topology.

K-line artifacts

Compiled implementations of cognition.

Evaluation

Evidence that cognition works under a defined protocol.

Verification

Evidence that claimed execution actually happened.

Compute

Resources needed to run cognition.

Evidence and grounding

Trusted information needed to solve or verify problems.

This produces a richer market than simple model-token resale.

27. Attribution

Cognitive lineage may support long-term attribution.

Example:

Expert E
   ↓ contributed to
Episode P
   ↓ promoted into
K-line K
   ↓ compiled into
Artifact A
   ↓ used by
17,000,000 future executions

Future economic mechanisms may reward contributions based on downstream cognitive impact.

This is not required for the first protocol version but should remain possible through immutable lineage.

28. Hard Architectural Boundaries

The following boundaries are normative.

Kline

owns:
    cognition
    System 1/System 2
    K-lines
    episodes
    artifacts
    Coordinator
    Cognitive Compiler
    novelty
    learning
    local trust

Actum Compute

owns:
    expert discovery
    capability resolution
    markets
    pricing
    matching
    expert execution procurement
    artifact distribution
    evaluation procurement
    evidence procurement
    economic settlement orchestration

Actum

owns:
    verifiable acts
    commitments
    lineage
    evidence records
    finality
    settlement state
    asset transfers

TLSNotary / Distill-derived evidence layer

owns:
    authenticated remote execution evidence

ZeroK

owns:
    confidential verification

SurrealDB

owns:
    persistent local Mind state

Agent Plugins / MCP / A2A

owns:
    distribution
    discovery
    invocation
    agent communication

29. Core Invariants

The architecture SHALL preserve the following invariants.

A K-line describes cognition, not permission.
Capability resolution does not confer authority.
The local Mind controls activation.
Global sharing does not imply global trust.
Provenance is not equivalent to truth.
K-lines are provisional cognition and may decay or be superseded.
System 2 retains the ability to reject System-1 precedent.
K-line templates describe requirements rather than unnecessarily fixing vendors.
Concrete supplier/model identity remains available in episodes and evidence.
High-value model identity should be cryptographically evidenced where possible.
Actum Compute owns market economics; Kline does not.
Actum records verifiable state transitions; it does not decide local cognitive trust.
Installing an Agent Plugin does not itself authorize execution or economic participation.
Sensitive cognition and commercial data should be selectively disclosed whenever possible.
Successful System-2 cognition should be eligible for progressive compilation into System 1.

30. Positioning

The DCN should not be positioned principally as:

a model;
an LLM wrapper;
an agent framework;
a model marketplace;
spare-token trading;
a vector-memory system.

The platform is:

A distributed cognitive network that discovers how to solve problems, verifies the solution process, compiles successful reasoning into reusable K-lines, and distributes those learned cognitive structures across a society of specialized intelligences.

Kline provides the cognitive architecture.

Actum Compute provides the intelligence market.

Actum provides verifiable action, evidence, provenance, and settlement.

The Cognitive Compiler turns expensive discovery into increasingly abundant cognition.

31. Long-Term Thesis

A monolithic AGI attempts to place increasingly general capability inside a single model or system.

The DCN takes a different path.

It seeks generality by continuously increasing the region of problem space covered by:

specialized expertise;
reusable K-lines;
higher-order K-line compositions;
evaluated cognitive artifacts;
compiled System-1 cognition.

General capability therefore emerges from a growing organization of specialized cognition rather than requiring every capability to exist within a single model.

The fundamental loop is:

UNKNOWN
   ↓
System 2
   ↓
solved
   ↓
validated
   ↓
K-line
   ↓
compiled
   ↓
System 1

The frontier continually moves outward.

The lasting asset of the network is therefore neither compute nor model access.

It is the accumulated body of verified, reusable, increasingly efficient cognitive capital.

Distributed Cognitive Network

Volume II — K-Line Protocol 0.1

Normative Object Model, Activation Semantics, Evaluation, Federation, and Cognitive Compilation

1. Scope

This document defines the normative protocol for representing, executing, evaluating, sharing, compiling, decaying, and superseding K-lines.

A K-line is a reusable organization of cognition for addressing a class of situations.

This protocol defines:

KLineTemplate
KLineEpisode
KLineArtifact
CapabilityRequirement
ExpertBinding
EvaluationProtocol
EvaluationClaim
ActivationPlan
PromotionRecord
CompilationRecord
SupersessionRecord
federation metadata
graph execution semantics
lifecycle semantics
trust and admissibility semantics
System-1/System-2 transition rules

This protocol does not define:

economic matching;
asset settlement;
expert-market pricing;
remote execution evidence formats;
generic authorization systems;
transport protocols.

Those are delegated respectively to Actum Compute, Actum, TLSNotary/attestation systems, authority systems, MCP, A2A, and related infrastructure.

2. Design Principles

The K-Line Protocol SHALL preserve the following principles.

2.1 Cognitive structure over vendor identity

A reusable K-line SHOULD encode cognitive capability requirements rather than fixed commercial providers.

Concrete providers and models SHALL be recorded in episodes.

2.2 Semantic stability

A K-line's meaning SHOULD remain stable while its implementation evolves.

This is why templates, episodes, and artifacts are distinct.

2.3 Local sovereignty

No remotely published K-line becomes active automatically.

A local Mind SHALL make an explicit trust and activation decision.

2.4 Provenance is not truth

Signed provenance, Actum finality, and execution evidence establish that claims were made or executions occurred.

They do not establish universal correctness.

2.5 System 1 is provisional

Promoted cognition remains subject to monitoring, decay, revalidation, demotion, supersession, and reopening.

2.6 System 2 may reject precedent

No K-line SHALL be treated as mandatory merely because it was previously successful.

2.7 Cognition and authority are separate

A K-line MAY state that a capability requires authority.

It SHALL NOT itself grant that authority.

3. Normative Terminology

The terms MUST, MUST NOT, SHALL, SHALL NOT, SHOULD, SHOULD NOT, and MAY are normative.

4. Core Object Hierarchy

The canonical hierarchy is:

KLineTemplate
     │
     ├── executed as
     │
     ▼
KLineEpisode
     │
     ├── evaluated by
     │
     ▼
EvaluationClaim
     │
     ├── may contribute to
     │
     ▼
PromotionRecord
     │
     ├── may be compiled into
     │
     ▼
KLineArtifact
     │
     ├── evaluated / monitored
     │
     ├── superseded
     │
     └── reopened into System 2

5. Canonical Identity Model

Three forms of identity SHALL be distinguished.

5.1 Object ID

An immutable authored identifier.

Example:

kline:template:01JAB...

Object IDs allow authored lineage even if content changes through new versions.

5.2 Content Hash

A cryptographic digest over canonical serialization.

Example:

sha256:84ab...

This identifies exact content.

Two objects with different bytes MUST have different content hashes except in the event of cryptographic collision.

5.3 Semantic Fingerprint

A non-authoritative similarity representation.

It MAY be produced by:

embeddings;
graph fingerprints;
learned representations;
symbolic feature signatures;
domain-specific signatures.

Semantic fingerprints MUST NOT be used as cryptographic identity.

6. Canonical Serialization

All protocol objects SHALL support deterministic canonical serialization.

A compliant implementation SHOULD use:

UTF-8
sorted object keys
explicit null policy
normalized numeric encoding
RFC 3339 timestamps
canonical URI representation

The protocol SHALL define:

canonical_hash(object)

as:

SHA-256(canonical_serialization(object))

Implementations MAY additionally support stronger hashes, but SHA-256 compatibility SHOULD remain available.

7. KLineTemplate

7.1 Purpose

KLineTemplate defines the reusable semantic and cognitive topology of a K-line.

It describes:

For this class of situation, what cognition should become active, in what structure, under what constraints, and how should success be assessed?

It SHOULD avoid unnecessarily fixing exact suppliers.

7.2 Schema

{
  "schema": "kline.template.v1",
  "id": "kline:template:...",
  "version": "1.0.0",

  "name": "inherited-cardiomyopathy-workup",
  "description": "Reusable cognitive topology for investigating suspected inherited cardiomyopathy.",

  "publisher": "did:example:publisher",

  "trigger": {},
  "preconditions": [],

  "inputs": {},
  "outputs": {},

  "graph": {
    "nodes": [],
    "edges": []
  },

  "context_policy": {},
  "authority_requirements": [],
  "budget_policy": {},
  "validation": {},
  "fallbacks": [],

  "lifecycle": {},
  "lineage": {},

  "semantic_fingerprint": {},
  "created_at": "...",
  "content_hash": "sha256:..."
}

8. Trigger Specification

Triggers determine when a K-line is considered relevant.

A trigger MAY contain:

semantic signatures
symbolic predicates
state predicates
event types
goal patterns
context conditions
novelty bounds
temporal constraints

Example:

{
  "semantic": {
    "description": "Possible inherited cardiomyopathy",
    "threshold": 0.82
  },
  "predicates": [
    "patient.has_left_ventricular_hypertrophy == true"
  ]
}

Triggers identify relevance, not automatic execution authority.

9. Preconditions

Preconditions define conditions that MUST hold before activation.

Examples:

required input exists
minimum context completeness
network availability
device capability
required consent
required local data
jurisdiction constraints

A failed precondition SHALL prevent direct activation unless a defined fallback exists.

10. Graph Model

A K-line SHALL be represented as a typed directed graph.

10.1 Node Types

Protocol v1 defines the following base node classes:

capability
artifact
transform
decision
validation
aggregation
memory_read
memory_write_proposal
authority_check
fallback
terminal

Extensions MAY define additional node types.

10.2 Capability Node

A capability node requests cognition from an expert, artifact, local component, or Actum Compute resolution.

Example:

{
  "id": "reasoner",
  "type": "capability",
  "requirement": {
    "capability": "general_reasoning",
    "minimum_quality": 0.91,
    "required_evidence": [
      "verified_execution"
    ],
    "privacy": {
      "remote_allowed": true
    }
  }
}

10.3 Artifact Node

An artifact node binds to a known implementation.

Example:

{
  "id": "local_classifier",
  "type": "artifact",
  "artifact_id": "kline:artifact:..."
}

Artifact nodes SHOULD be used when a specific implementation is part of the intended behavior.

10.4 Decision Node

Decision nodes select downstream paths based on state.

Decision functions MUST be deterministic given their declared inputs unless explicitly marked stochastic.

10.5 Validation Node

A validation node checks whether an intermediate or final output satisfies defined criteria.

Validation MAY invoke external capability requirements.

10.6 Memory Write Proposal

K-line execution SHOULD NOT directly mutate shared Mind state.

Instead:

execution
    ↓
state proposal
    ↓
validation / authority
    ↓
signed patch
    ↓
SurrealDB

A memory_write_proposal node therefore emits a proposed patch.

11. Graph Edges

Edges define:

control flow;
data flow;
conditions;
failure routes;
validation dependencies.

Example:

{
  "from": "rare_disease",
  "to": "critic",
  "condition": "output.confidence < 0.95",
  "mapping": {
    "candidate_diagnoses": "$.rare_disease.output"
  }
}

Cycles MAY be allowed but MUST declare:

maximum iterations
termination condition
budget limit

Unbounded loops are non-conformant.

12. CapabilityRequirement

CapabilityRequirement is the primary abstraction between cognition and supplier resolution.

Schema:

{
  "schema": "kline.capability-requirement.v1",

  "capability": "software_engineering",

  "input_schema": {},
  "output_schema": {},

  "quality": {
    "minimum": 0.94,
    "metric": "evaluation:software-engineering-v3"
  },

  "evidence": {
    "required": [
      "provider_authenticated",
      "request_response_bound"
    ]
  },

  "trust": {
    "minimum_level": "trusted"
  },

  "privacy": {
    "remote_allowed": true,
    "confidential_execution_required": false
  },

  "jurisdiction": {
    "allowed": [],
    "denied": []
  },

  "latency": {
    "maximum_ms": 90000
  },

  "cost": {
    "maximum": {
      "amount": "4.00",
      "currency": "EUR"
    }
  },

  "energy": {
    "preference": "minimize"
  },

  "execution_location": [
    "local",
    "remote"
  ],

  "fallback": {}
}

13. Capability Resolution

A CapabilityRequirement MAY be resolved by:

local artifact;
local expert;
cached remote expert;
Actum Compute;
another Mind;
deterministic tool;
human expert.

Resolution SHALL produce an ExpertBinding.

14. ExpertBinding

Schema:

{
  "schema": "kline.expert-binding.v1",

  "requirement_hash": "sha256:...",
  "expert_id": "expert:...",
  "artifact_id": null,

  "capabilities": [
    "software_engineering"
  ],

  "expected_quality": 0.96,

  "evidence_class": [
    "tlsnotary"
  ],

  "trust_class": "trusted",

  "price": {
    "amount": "2.30",
    "currency": "EUR"
  },

  "expected_latency_ms": 35000,

  "binding_time": "...",

  "resolver": "actum-compute"
}

Bindings are late-bound execution facts and SHALL normally belong to episodes rather than templates.

15. Admissibility

Before optimization, candidate bindings SHALL pass admissibility.

Define:

[ A(e,r,c) ]

for expert candidate (e), requirement (r), and context (c).

A candidate is admissible only if:

policy allows it
required authority is satisfiable
trust threshold satisfied
evidence class satisfied
privacy policy satisfied
jurisdiction satisfied
quality floor satisfied

Only admissible candidates proceed to optimization.

16. Routing Objective

Among admissible candidates, the Cognitive Kernel MAY optimize:

[ U(e)= Q(e) -\lambda C(e) -\mu L(e) -\rho R(e) -\eta E(e) ]

where:

(Q) = expected quality;
(C) = economic cost;
(L) = latency;
(R) = contextual risk;
(E) = energy.

Weights are local Mind policy and MUST NOT be globally fixed.

17. ActivationPlan

Before execution, the Cognitive Kernel SHOULD materialize an ActivationPlan.

Schema:

{
  "schema": "kline.activation-plan.v1",

  "template_id": "kline:template:...",
  "template_hash": "sha256:...",

  "trigger_match": {},
  "context_commitment": "sha256:...",

  "bindings": [],

  "execution_mode": "system1",

  "estimated_cost": {},
  "estimated_latency_ms": 0,
  "estimated_energy": null,

  "authority_requirements": [],
  "validation_plan": {},

  "created_at": "..."
}

An ActivationPlan represents intended execution.

The eventual Episode represents actual execution.

18. System-1 Activation

A K-line MAY execute through System 1 when:

template is promoted
artifact/bindings satisfy policy
trigger confidence exceeds threshold
novelty below escalation threshold
required evaluations remain valid
no decay/revalidation gate blocks execution
authority requirements are satisfied

System-1 execution SHOULD prefer low-cost compiled artifacts when quality constraints are maintained.

19. System-2 Escalation

System 2 SHALL be available when any of the following occurs:

no matching K-line
low trigger confidence
novelty too high
unexpected intermediate result
validation disagreement
artifact quality degraded
trust conflict
environment drift
execution anomaly
repeated System-1 failure
policy requires deliberation

20. Novelty and Surprise

Implementations SHOULD compute a novelty/surprise signal:

[ N(q,c,K) ]

Inputs MAY include:

semantic distance from prior episodes;
graph mismatch;
distribution drift;
disagreement among experts;
prediction error;
validation failure;
unfamiliar context state.

Novelty above local threshold SHOULD cause System-2 escalation.

21. KLineEpisode

KLineEpisode records one actual execution.

Schema:

{
  "schema": "kline.episode.v1",

  "id": "kline:episode:...",

  "template_id": "kline:template:...",
  "template_hash": "sha256:...",

  "activation_plan_hash": "sha256:...",

  "trigger": {},
  "context_commitment": "sha256:...",

  "bindings": [],

  "execution": {
    "started_at": "...",
    "completed_at": "...",
    "mode": "system2",
    "nodes": []
  },

  "inputs_commitment": "sha256:...",
  "outputs_commitment": "sha256:...",

  "evidence": [],

  "cost": {},
  "latency_ms": 0,
  "energy": null,

  "outcome": {},
  "evaluation_claims": [],

  "actum_receipt": null,

  "created_at": "...",
  "content_hash": "sha256:..."
}

22. Episode Node Record

Each executed graph node SHOULD produce a record containing:

node ID
input commitment
resolved expert/artifact
execution timestamps
output commitment
evidence references
cost
latency
status
error/fallback information

This enables causal analysis of successful and failed trajectories.

23. Execution Evidence

An Episode MAY reference:

TLSNotary evidence;
TEE attestation;
model hash attestation;
signed local runtime receipt;
human signature;
test results;
deterministic replay;
ZeroK proof;
Actum execution receipt.

The K-Line Protocol does not define those evidence formats.

It defines their relationship to episodes.

24. EvaluationProtocol

Schema:

{
  "schema": "kline.evaluation-protocol.v1",

  "id": "evaluation:protocol:...",

  "name": "...",

  "subject_types": [
    "template",
    "artifact",
    "expert",
    "episode"
  ],

  "distribution": {
    "commitment": "sha256:...",
    "description": "..."
  },

  "sampling": {},
  "metrics": [],
  "scorer": {},
  "contamination_policy": {},
  "environment": {},
  "minimum_samples": 0,

  "acceptance": {},

  "publisher": "...",
  "created_at": "...",

  "content_hash": "sha256:..."
}

25. EvaluationClaim

Schema:

{
  "schema": "kline.evaluation-claim.v1",

  "id": "evaluation:claim:...",

  "subject": {
    "type": "artifact",
    "id": "kline:artifact:...",
    "hash": "sha256:..."
  },

  "protocol": {
    "id": "evaluation:protocol:...",
    "hash": "sha256:..."
  },

  "distribution": {
    "commitment": "sha256:..."
  },

  "environment": {},

  "result": {
    "metrics": {}
  },

  "evidence": [],

  "evaluator": "did:example:evaluator",

  "issued_at": "...",
  "expires_at": null,

  "actum_receipt": null,

  "content_hash": "sha256:..."
}

An implementation MUST NOT treat one claim as universal evidence across unrelated distributions.

26. Promotion

Promotion is the transition from candidate cognition into eligible System-1 cognition.

Promotion SHALL be policy-driven.

A promotion policy MAY require:

minimum number of episodes
minimum number of independent evaluations
minimum success probability
maximum failure rate
required evaluator trust
environment coverage
absence of unresolved anomalies

27. PromotionRecord

{
  "schema": "kline.promotion.v1",

  "template_id": "kline:template:...",

  "from_state": "validated",
  "to_state": "promoted",

  "basis": {
    "episodes": [],
    "evaluation_claims": []
  },

  "policy": "policy:kline-promotion-v1",

  "authority": "...",

  "promoted_at": "...",

  "actum_receipt": null
}

Promotion SHALL NOT imply permanent validity.

28. KLineArtifact

Schema:

{
  "schema": "kline.artifact.v1",

  "id": "kline:artifact:...",

  "template_id": "kline:template:...",
  "template_hash": "sha256:...",

  "artifact_type": "local_model",

  "implementation": {
    "runtime": "...",
    "target": "...",
    "content_hash": "sha256:..."
  },

  "requirements": {
    "hardware": [],
    "software": [],
    "memory": null,
    "network": null
  },

  "quality_claims": [],

  "privacy": {},
  "authority_requirements": [],

  "cost_profile": {},
  "latency_profile": {},
  "energy_profile": {},

  "compiler_lineage": {},

  "publisher": "...",

  "lifecycle": {},

  "created_at": "...",
  "content_hash": "sha256:..."
}

29. Artifact Types

Protocol v1 recognizes:

workflow
local_model
remote_workflow
classifier
ruleset
deterministic_program
hybrid
mobile_reflex
prompted_agent
graph_executor

Implementations MAY define extensions.

30. Cognitive Compiler Interface

The Cognitive Compiler SHALL accept:

template
successful episodes
evaluation requirements
optimization targets
deployment constraints

and return one or more candidate artifacts.

Conceptual interface:

compile(
    KLineTemplate,
    EpisodeSet,
    Constraints,
    Objective
) → ArtifactCandidates

31. TopologyCompiler

The TopologyCompiler searches for simpler cognitive graphs.

Possible operations include:

remove redundant node
merge nodes
replace parallel reasoning with deterministic decision
reduce repeated verification
cache stable intermediate result
replace generic expert with specialist
collapse stable branch

Every candidate topology MUST be re-evaluated.

32. ArtifactCompiler

The ArtifactCompiler changes implementation while preserving semantics.

Possible transformations include:

remote experts → local model
large model → distilled model
LLM chain → classifier
agent workflow → deterministic program
network retrieval → cached structured knowledge
multi-agent reasoning → single specialist artifact

Compiled output MUST NOT be promoted solely because it is cheaper.

Quality constraints remain authoritative.

33. CompilationRecord

{
  "schema": "kline.compilation.v1",

  "source_template": "kline:template:...",

  "source_episodes": [],

  "compiler": {
    "id": "...",
    "version": "..."
  },

  "optimization": {
    "targets": [
      "cost",
      "latency",
      "energy"
    ],
    "quality_floor": 0.95
  },

  "produced_artifacts": [],

  "evaluation_claims": [],

  "created_at": "...",

  "actum_receipt": null
}

34. Lifecycle

Templates and artifacts SHALL expose lifecycle status.

Recommended states:

candidate
validated
promoted
active
degraded
revalidation_required
superseded
revoked
archived

35. Decay

A Mind SHOULD support confidence decay.

Decay MAY depend on:

time
distribution drift
environment drift
expert changes
model changes
evaluation age
failure observations
superseding evidence

A simple implementation MAY use:

[ confidence_t

confidence_0 e^{-\lambda t} ]

but protocol semantics do not mandate a mathematical form.

36. Revalidation

A K-line or artifact SHOULD enter revalidation_required when:

validity window expires
provider behavior changes
model identity changes materially
input distribution drifts
failure surprise exceeds threshold
evaluation protocol becomes obsolete
artifact runtime changes

Revalidation returns it to active or results in degradation/supersession/revocation.

37. Supersession

A new K-line or artifact SHOULD supersede rather than erase prior history.

Schema:

{
  "schema": "kline.supersession.v1",

  "subject": "kline:artifact:A",
  "superseded_by": "kline:artifact:B",

  "reason": "quality_and_energy_improvement",

  "evidence": [],

  "effective_at": "...",

  "actum_receipt": null
}

Historical episodes MUST remain attributable to the implementation actually used.

38. Failure Surprise

Implementations SHOULD track mismatch between expected and observed performance.

Define conceptually:

[ S = f( expected_quality, observed_quality, confidence, context_distance ) ]

Large surprise SHOULD increase:

revalidation pressure
System-2 escalation probability
artifact demotion probability

39. Higher-Order K-Lines

A K-line MAY activate other K-lines as cognitive primitives.

Example:

K521
├── K1
├── K2
├── K3
└── K4

This enables hierarchical cognition.

Nested K-lines MUST preserve:

input/output typing;
authority constraints;
evidence requirements;
failure semantics.

40. Recursive Composition

System 2 MAY create candidate higher-order K-lines by composing existing K-lines.

This process SHALL be treated as new cognition and MUST undergo evaluation before System-1 promotion.

Composition does not inherit universal validity from its components.

41. Federation

K-lines are shareable across Minds.

Federation SHOULD support:

publish
discover
fetch
verify
evaluate
fork
supersede
cache
block

No remote federation operation SHALL automatically activate a K-line locally.

42. Federation Descriptor

{
  "schema": "kline.federation-descriptor.v1",

  "subject": {
    "id": "kline:template:...",
    "hash": "sha256:..."
  },

  "publisher": "did:example:publisher",

  "availability": {
    "protocols": [
      "a2a",
      "https"
    ]
  },

  "evidence": [],
  "evaluation_claims": [],

  "licensing": {},

  "published_at": "...",

  "actum_receipt": null
}

43. Local Trust View

Each Mind SHOULD maintain a local trust state independent of global publication.

Example:

{
  "subject": "kline:template:...",
  "status": "experimental",

  "publisher_trust": 0.82,

  "evaluation_trust": {
    "evaluation:claim:1": 0.94
  },

  "local_experience": {
    "episodes": 12,
    "success": 11
  },

  "policy": {
    "allow_system1": false,
    "allow_system2": true
  }
}

Trust is contextual and SHOULD NOT be globally standardized into a single universal score.

44. Imports

Importing a K-line SHOULD resemble importing executable supply-chain content.

Implementations SHOULD verify:

publisher identity
content hash
lineage
evaluation claims
artifact integrity
authority requirements
dependencies
known revocations

A Mind MAY sandbox imported K-lines in System 2 before allowing System-1 promotion.

45. Poisoning Resistance

Federated implementations SHOULD protect against:

Sybil publishers
fabricated evaluations
benchmark contamination
mass popularity manipulation
malicious graph payloads
stale dependencies
expert collusion
semantic spoofing

Actum provenance can assist but MUST NOT be treated as proof of correctness.

46. Actum Integration

Kline MAY anchor protocol-level acts on Actum.

Recommended act classes:

KLineEpisodeAct
EvaluationClaimAct
PromotionAct
CompilationAct
ArtifactPublicationAct
SupersessionAct
RevocationAct

Actum records durable evidence and lineage.

Kline retains cognitive interpretation.

47. Actum Compute Integration

The K-Line Protocol invokes Actum Compute through capability resolution.

The normative boundary is:

Kline:
    what cognition is required?

Actum Compute:
    who or what can supply it,
    under what terms and evidence?

The exchange SHOULD NOT decide whether a K-line is cognitively appropriate.

48. Expert Episodes Through Actum Compute

A remote expert binding may generate:

ComputeOffer
JobIntent
JobAssignment
ExecutionAct
SettlementAct

The KLineEpisode SHOULD reference the corresponding execution evidence and Actum receipts.

49. Evaluation Market Integration

Kline MAY request evaluation as a capability.

Example:

{
  "capability": "evaluate_kline",
  "requirements": {
    "protocol": "evaluation:protocol:...",
    "minimum_independent_evaluators": 3
  }
}

Actum Compute may procure evaluators.

Kline decides whether the resulting claims satisfy promotion policy.

50. Artifact Market Integration

A KLineArtifact MAY be:

private
public
free
licensed
subscription-based
per-execution
royalty-bearing
organization-restricted

Economic semantics belong to Actum Compute, not the K-Line Template itself.

51. Authority Boundary

A graph may declare:

{
  "requires": {
    "capability": "send_email",
    "authority": "delegated"
  }
}

But execution requires an external authorization decision.

The K-line SHALL NOT infer authorization from historical success.

52. State Mutation Boundary

K-lines SHOULD operate through proposal-based state mutation.

Preferred model:

read state
   ↓
reason
   ↓
propose patch
   ↓
validate
   ↓
authorize
   ↓
commit

Direct uncontrolled mutation is discouraged.

53. SurrealDB Reference Model

A reference SurrealDB implementation MAY use:

kline_template
kline_episode
kline_artifact
capability_requirement
expert_binding
activation_plan
evaluation_protocol
evaluation_claim
promotion_record
compilation_record
supersession_record
federation_descriptor
trust_view

Relationships MAY include:

IMPLEMENTS
EXECUTED_AS
EVALUATED_BY
PROMOTED_FROM
COMPILED_INTO
SUPERSEDES
FORKED_FROM
REQUIRES
BOUND_TO
PUBLISHED_BY
TRUSTED_BY

54. Example Cognitive Graph

                  ┌──────────────────┐
                  │ phenotype_extract│
                  └────────┬─────────┘
                           │
                           ▼
                ┌─────────────────────┐
                │ cardiomyopathy_reason│
                └──────────┬──────────┘
                           │
              ┌────────────┴────────────┐
              ▼                         ▼
       rare_disease               evidence_search
              │                         │
              └────────────┬────────────┘
                           ▼
                  independent_critic
                           │
                           ▼
                      validation
                           │
                    ┌──────┴──────┐
                    ▼             ▼
                  accept       System 2

Each cognitive node describes a capability requirement.

Each Episode records actual bindings.

55. Example Template

{
  "schema": "kline.template.v1",
  "id": "kline:template:cardiomyopathy-001",
  "version": "1.0.0",

  "name": "Inherited Cardiomyopathy Investigation",

  "trigger": {
    "semantic": {
      "description": "suspected inherited cardiomyopathy",
      "threshold": 0.84
    }
  },

  "graph": {
    "nodes": [
      {
        "id": "phenotype",
        "type": "capability",
        "requirement": {
          "capability": "clinical_phenotype_extraction",
          "quality": {
            "minimum": 0.95
          }
        }
      },
      {
        "id": "reasoning",
        "type": "capability",
        "requirement": {
          "capability": "cardiomyopathy_reasoning",
          "quality": {
            "minimum": 0.96
          },
          "evidence": {
            "required": [
              "verified_execution"
            ]
          }
        }
      },
      {
        "id": "rare",
        "type": "capability",
        "requirement": {
          "capability": "rare_disease_specialist",
          "quality": {
            "minimum": 0.94
          }
        }
      },
      {
        "id": "critic",
        "type": "validation",
        "requirement": {
          "capability": "independent_clinical_critique"
        }
      }
    ],

    "edges": [
      {
        "from": "phenotype",
        "to": "reasoning"
      },
      {
        "from": "reasoning",
        "to": "rare"
      },
      {
        "from": "rare",
        "to": "critic"
      }
    ]
  },

  "lifecycle": {
    "status": "candidate"
  }
}

56. Example Episode

{
  "schema": "kline.episode.v1",

  "id": "kline:episode:E923",

  "template_id": "kline:template:cardiomyopathy-001",

  "bindings": [
    {
      "node": "phenotype",
      "expert_id": "artifact:local-phenotype-v4"
    },
    {
      "node": "reasoning",
      "expert_id": "expert:frontier-reasoner-381",
      "evidence": [
        "actum:execution:..."
      ]
    },
    {
      "node": "rare",
      "expert_id": "expert:fabry-specialist-14b"
    },
    {
      "node": "critic",
      "expert_id": "expert:clinical-critic-91"
    }
  ],

  "outcome": {
    "status": "success"
  },

  "cost": {
    "amount": "3.82",
    "currency": "EUR"
  },

  "latency_ms": 28100
}

57. System-1 Compilation Example

Initial System-2 topology:

frontier reasoning
+
rare-disease expert
+
literature retrieval
+
critic
+
human review

After repeated validation:

specialist workflow
+
critic

After Artifact Compilation:

local specialist model
+
deterministic confidence gate

Final mobile artifact:

on-device classifier
+
rules
+
System-2 escalation if uncertain

The semantic K-line remains identifiable through the entire lineage.

58. Conformance Requirements

A conformant K-Line Protocol implementation MUST:

distinguish Template, Episode, and Artifact;
support immutable episode recording;
support canonical hashing;
support typed graph execution;
support CapabilityRequirements;
record concrete expert bindings in episodes;
keep cognition separate from authority;
support lifecycle status;
support supersession without destructive history deletion;
support evaluation claims tied to protocols;
support System-2 escalation;
prevent automatic activation of imported federated K-lines;
maintain local trust decisions;
support compiled artifacts;
preserve lineage between cognition and artifacts.

59. Recommended Conformance Requirements

A mature implementation SHOULD additionally:

support Actum anchoring;
support Actum Compute capability resolution;
support ZeroK-verifiable evaluation claims;
support expert-execution evidence;
support confidence decay;
support novelty detection;
support mobile artifacts;
support higher-order K-lines;
support local re-evaluation;
support evaluation markets.

60. Security Considerations

K-lines constitute executable cognitive supply-chain content.

Threats include:

malicious graph logic
poisoned templates
malicious artifacts
false quality claims
forged evaluations
dependency substitution
model/provider downgrade
authority confusion
data exfiltration
prompt injection
state poisoning
benchmark gaming
collusion

A conformant runtime SHOULD treat external K-lines as untrusted until locally evaluated or trusted according to policy.

61. Privacy Considerations

KLineEpisodes may contain extremely sensitive context.

Implementations SHOULD support:

commitment-only publication
selective disclosure
private local episodes
ZeroK evaluation proofs
redacted expert identities
private input/output commitments

Federation SHOULD default to sharing the minimum data needed for the intended claim.

62. Economic Neutrality

The K-Line Protocol SHALL NOT require a specific economic model.

K-lines MAY be:

public goods
open source
licensed
royalty-bearing
private
organization-owned
marketed through Actum Compute

Economic terms belong outside the semantic template.

63. Reference Cognitive Lifecycle

The normative lifecycle is:

UNKNOWN PROBLEM
      │
      ▼
SYSTEM 2 DISCOVERY
      │
      ▼
SUCCESSFUL EPISODE
      │
      ▼
REIFY TEMPLATE
      │
      ▼
EVALUATE
      │
      ▼
VALIDATE
      │
      ▼
PROMOTE
      │
      ▼
SYSTEM 1
      │
      ▼
COMPILE
      │
      ▼
ARTIFACT
      │
      ▼
DEPLOY
      │
      ▼
MONITOR
      │
 ┌────┼─────────┐
 ▼    ▼         ▼
good drift    failure
 │     │         │
 │     ▼         ▼
 │ revalidate  reopen S2
 │
 └──────────────► reinforce

64. Architectural Definition

A K-line is:

A typed, reusable, evidence-bearing cognitive topology that describes how a class of situations should activate capabilities, context, validation, and control flow, while remaining independent from the particular expert implementations used in any single execution.

A KLineEpisode is:

An immutable record of one concrete realization of a K-line, including actual expert bindings, execution evidence, cost, latency, context commitments, and outcome.

A KLineArtifact is:

A compiled executable implementation of a K-line optimized for a target environment while preserving required semantic and quality constraints.

Together they define the core unit of reusable cognition in the Distributed Cognitive Network.

65. Strategic Objective

The system should continuously transform:

novel cognition
      ↓
successful episode
      ↓
K-line
      ↓
validated cognitive capital
      ↓
compiled artifact
      ↓
cheap System-1 cognition

The long-term objective is not to eliminate System 2.

It is to continuously move solved regions of the problem space from expensive discovery into efficient reusable cognition, allowing scarce expert capacity to migrate toward the frontier.

The next artifact should be Volume III — Actum Compute Protocol 0.2, which will define the network market around CapabilityRequirement, ExpertOffer, ArtifactOffer, matching, execution assurance classes, TLSNotary evidence, evaluation procurement, pricing, settlement, and how Agent Plugins expose the whole thing to Codex and other agents.

Distributed Cognitive Network

Volume III — Actum Compute Protocol 0.2

Capability Markets, Expert Resolution, Verifiable Execution, Evidence, Economics, and Agent Distribution

1. Scope

This document defines Actum Compute Protocol 0.2, the economic, discovery, procurement, verification, and settlement layer beneath the Kline cognitive architecture.

Actum Compute exists to answer:

Given a cognitive capability requirement, who or what can satisfy it, under what quality, trust, privacy, evidence, latency, availability, and economic conditions?

Actum Compute is not the Cognitive Kernel.

It does not decide what a Mind should think.

It provides a market and execution fabric through which Kline and other clients can acquire scarce cognition.

The protocol supports markets for:

frontier-model execution;
subscription-backed model execution;
API-backed model execution;
local models;
specialist models;
human experts;
K-line artifacts;
evaluation services;
verification services;
trusted data/evidence;
raw compute;
compilation and distillation services.

Actum Compute SHALL use Actum as its canonical verifiable action, evidence, finality, and settlement substrate.

Where appropriate, it SHALL support:

TLSNotary for authenticated remote execution evidence;
Distill-derived evidence processing;
ZeroK for confidential verification;
Agent Plugins for portable distribution;
MCP for capability invocation;
A2A for autonomous agent negotiation.

2. Architectural Role

The canonical relationship is:

KLINE
cognitive layer
    │
    │ CapabilityRequirement
    ▼
ACTUM COMPUTE
intelligence market
    │
    ├── expert discovery
    ├── capability resolution
    ├── pricing
    ├── matching
    ├── execution procurement
    ├── evidence procurement
    ├── evaluation procurement
    └── settlement orchestration
    │
    ▼
ACTUM
verifiable action layer

The normative boundary is:

Kline determines what cognition is required. Actum Compute determines what admissible supply exists and under what terms. Actum proves what verifiably happened.

3. Core Principles

3.1 Capability, not account access

Actum Compute SHALL trade execution capability and cognitive outcomes.

It SHALL NOT define account sharing as a market primitive.

A supplier may use:

a subscription;
an API;
local hardware;
enterprise infrastructure;
a human;
a licensed artifact;

as the implementation behind its offered capability.

The traded object is the contracted execution or artifact.

3.2 Model quality may be part of the contract

Provider and model identity SHALL NOT be hidden when they materially define the execution class.

A buyer MAY request:

provider: OpenAI
model_class: current_flagship_coding
evidence: TLSNotary

or:

capability: software_engineering
minimum_quality: 0.95
provider: unrestricted

The protocol therefore supports both:

provider-neutral capability markets;
provider/model-specific execution classes.

3.3 Evidence is part of the commodity

An execution without evidence and the same execution with strong evidence are distinct market goods.

Examples:

unverified coding execution

provider-authenticated coding execution

provider + model-label authenticated execution

TEE-attested specialist-model execution

fully bound request/result execution

Evidence requirements SHALL be explicit.

3.4 Privacy is selectable

A buyer SHOULD be able to specify privacy requirements independently of execution capability.

Examples:

public execution

pseudonymous execution

confidential input

confidential settlement

hidden expert identity

hidden exact price

private evaluation

3.5 Settlement follows verified acts

Where verification is required, payment SHALL NOT be released solely because a supplier claims completion.

Settlement SHALL be conditioned on the required execution and evidence predicates.

4. Principal Market Objects

Protocol 0.2 defines these core objects:

CapabilityRequirement
ExpertDescriptor
ExpertOffer
ArtifactOffer
EvaluationOffer
EvidenceOffer
ComputeOffer
CapabilityQuote
JobIntent
JobAssignment
ExecutionReceipt
ProviderExecutionEvidence
EvaluationClaim
SettlementIntent
SettlementAct
ReputationClaim

The K-Line Protocol definition of CapabilityRequirement is reused rather than duplicated.

5. ExpertDescriptor

ExpertDescriptor describes a supplier of cognition.

An Expert MAY be:

model;
agent;
workflow;
human;
organization;
K-line artifact;
hybrid system.

Schema:

{
  "schema": "actum.compute.expert.v1",
  "id": "expert:...",

  "operator": "did:example:operator",

  "type": "model",

  "name": "Verified Frontier Coding Expert",

  "capabilities": [
    "software_engineering",
    "debugging",
    "code_review"
  ],

  "execution_classes": [],

  "evidence_classes": [
    "tlsnotary"
  ],

  "privacy_classes": [
    "remote_private"
  ],

  "environments": [
    "remote"
  ],

  "quality_claims": [],

  "attestations": [],

  "metadata": {},

  "created_at": "...",
  "content_hash": "sha256:..."
}

6. ExecutionClass

An ExecutionClass defines characteristics of an execution that materially affect its value.

Example:

{
  "schema": "actum.compute.execution-class.v1",

  "id": "execution-class:frontier-coding-openai",

  "capability": "software_engineering",

  "provider": {
    "required": "openai"
  },

  "model": {
    "requirement": "current_flagship_coding"
  },

  "evidence": {
    "required": [
      "provider_authenticated",
      "model_identifier_authenticated",
      "request_bound",
      "result_bound"
    ]
  },

  "tools": {
    "allowed": true
  },

  "minimum_context": null,

  "privacy": {
    "remote_allowed": true
  }
}

Execution classes MAY be standardized by market participants.

7. ExpertOffer

An ExpertOffer advertises an expert's willingness to execute capability.

Schema:

{
  "schema": "actum.compute.expert-offer.v1",
  "id": "offer:expert:...",

  "expert_id": "expert:...",

  "capabilities": [
    "software_engineering"
  ],

  "execution_classes": [
    "execution-class:frontier-coding-openai"
  ],

  "quality_claims": [],

  "evidence_classes": [
    "tlsnotary"
  ],

  "privacy_classes": [
    "remote_private"
  ],

  "availability": {},

  "capacity": {},

  "reserve_policy": {},

  "pricing": {},

  "jurisdiction": {},

  "settlement": {},

  "expires_at": "...",

  "publisher": "did:example:seller",

  "actum_receipt": null
}

8. Capacity Semantics

Capacity MAY be represented as:

concurrency
time
jobs
compute units
provider allowance estimate
GPU time
token budget
human hours
artifact execution quota

Capacity estimates MAY be probabilistic.

For subscription-backed providers, exact provider allowance may be unknowable.

An offer therefore MAY state:

{
  "capacity": {
    "measurement": "estimated_remaining_fraction",
    "value": 0.62,
    "confidence": 0.74
  }
}

9. Reserve Policy

A supplier MAY reserve capacity for itself.

Example:

{
  "reserve_policy": {
    "minimum_remaining_fraction": 0.30,
    "idle_only": true,
    "max_concurrent_jobs": 1
  }
}

The matcher MUST NOT assign new jobs when accepting the assignment would violate a mandatory reserve policy.

10. Subscription-Backed Execution

Actum Compute MAY support execution in which a supplier uses its own flat-fee subscription.

Normative requirements:

provider authentication remains on the supplier host;
the buyer receives no transferable provider credential;
the supplier exposes execution capability rather than credentials;
the execution worker controls the authenticated provider session;
evidence requirements MAY prove provider/model interaction;
the market does not imply contractual authorization by the upstream provider.

Provider-specific terms remain external constraints.

11. ArtifactOffer

ArtifactOffer distributes compiled cognition.

Schema:

{
  "schema": "actum.compute.artifact-offer.v1",

  "id": "offer:artifact:...",

  "artifact": {
    "id": "kline:artifact:...",
    "hash": "sha256:..."
  },

  "template": {
    "id": "kline:template:...",
    "hash": "sha256:..."
  },

  "capabilities": [],

  "target_environments": [
    "ios-arm64"
  ],

  "quality_claims": [],

  "evidence": [],

  "license": {
    "type": "per_execution"
  },

  "pricing": {},

  "publisher": "...",

  "actum_receipt": null
}

Artifacts MAY be:

downloadable;
remotely hosted;
encrypted;
licensed;
per-use;
royalty-bearing.

12. EvaluationOffer

Evaluation is a first-class market service.

Schema:

{
  "schema": "actum.compute.evaluation-offer.v1",

  "id": "offer:evaluation:...",

  "evaluator": "expert:...",

  "supported_protocols": [
    "evaluation:protocol:..."
  ],

  "subject_types": [
    "kline_template",
    "kline_artifact",
    "expert"
  ],

  "independence_claims": [],

  "evidence_classes": [],

  "pricing": {},

  "availability": {}
}

13. EvidenceOffer

Verification providers MAY separately sell evidence services.

Examples:

TLSNotary verification;
TEE attestation;
deterministic replay;
benchmark execution;
human certification;
ZK proof generation.

Schema:

{
  "schema": "actum.compute.evidence-offer.v1",

  "provider": "evidence-provider:...",

  "evidence_class": "tlsnotary",

  "supported_claims": [
    "provider_identity",
    "request_binding",
    "result_binding"
  ],

  "pricing": {},

  "latency": {}
}

14. Raw ComputeOffer

Raw compute remains a valid commodity.

Examples:

GPU minutes
CPU time
secure enclave execution
mobile inference
storage
bandwidth

However raw compute SHALL remain distinct from higher-level expert capability.

15. Capability Resolution

The primary Actum Compute operation is:

resolve(CapabilityRequirement)

which returns candidate suppliers.

Conceptual result:

{
  "schema": "actum.compute.capability-resolution.v1",

  "requirement_hash": "sha256:...",

  "candidates": [
    {
      "offer_id": "offer:...",
      "expert_id": "expert:...",

      "expected_quality": 0.96,

      "price": {
        "amount": "2.40",
        "currency": "EUR"
      },

      "expected_latency_ms": 42000,

      "evidence": [
        "tlsnotary"
      ],

      "privacy": "remote_private",

      "admissibility_evidence": []
    }
  ],

  "resolved_at": "..."
}

Actum Compute SHOULD return several candidates where useful.

Kline retains final selection.

16. Matching

Matching SHALL first enforce hard constraints.

Candidates failing any mandatory constraint MUST be excluded.

Constraints MAY include:

capability
quality
trust
provider
model class
evidence
privacy
jurisdiction
availability
budget
latency
authority
hardware

Only admissible candidates enter economic ranking.

17. Economic Ranking

Market ranking MAY optimize:

[ Score = w_q Q

w_c C

w_l L

w_r R

w_e E ]

where:

(Q) = expected quality;
(C) = price;
(L) = latency;
(R) = execution risk;
(E) = energy.

Weights MAY be buyer policy.

Actum Compute SHALL NOT globally impose one universal utility function.

18. CapabilityQuote

Before commitment, a supplier MAY issue a signed quote.

Schema:

{
  "schema": "actum.compute.quote.v1",

  "id": "quote:...",

  "requirement_hash": "sha256:...",

  "offer_id": "offer:...",

  "execution_class": "...",

  "price": {
    "amount": "2.40",
    "currency": "EUR"
  },

  "estimated_latency_ms": 42000,

  "evidence_commitment": {},

  "valid_until": "...",

  "issuer": "...",

  "signature": "..."
}

19. JobIntent

JobIntent represents the buyer's committed request.

Schema:

{
  "schema": "actum.compute.job-intent.v1",

  "id": "job:...",

  "buyer_commitment": "sha256:...",

  "capability_requirement": {
    "hash": "sha256:..."
  },

  "objective_commitment": "sha256:...",

  "input_state_commitment": "sha256:...",

  "required_execution_class": "...",

  "required_evidence": [],

  "privacy_policy": {},

  "maximum_settlement": {
    "amount": "4.00",
    "currency": "EUR"
  },

  "deadline": "...",

  "authorization": {},

  "created_at": "...",

  "actum_receipt": null
}

Private job details SHOULD be committed rather than published when confidentiality is required.

20. JobAssignment

The assignment binds:

job;
supplier;
execution conditions;
price;
evidence challenge;
expiry.

Schema:

{
  "schema": "actum.compute.job-assignment.v1",

  "id": "assignment:...",

  "job_id": "job:...",
  "offer_id": "offer:...",
  "expert_id": "expert:...",

  "execution_class": "...",

  "settlement_amount": {},

  "evidence_requirement": {},

  "execution_challenge": "base64url:...",

  "input_commitment": "sha256:...",

  "expires_at": "...",

  "buyer_commitment": "sha256:...",
  "seller_commitment": "sha256:...",

  "actum_receipt": null
}

21. Execution Challenge

Every evidence-bound assignment SHOULD include a fresh challenge.

The challenge SHALL be unique and short-lived.

It SHALL be cryptographically bound to the assignment.

Conceptually:

[ Challenge = H( AssignmentID \parallel JobCommitment \parallel SellerCommitment \parallel Nonce \parallel Expiry ) ]

The challenge prevents reuse of unrelated prior execution evidence.

22. Execution State Machine

Recommended job states:

OPEN
  ↓
QUOTED
  ↓
FUNDED
  ↓
ASSIGNED
  ↓
EXECUTING
  ↓
PROOF_PENDING
  ↓
VERIFIED
  ↓
DELIVERED
  ↓
SETTLED

Failure states:

EXPIRED
CANCELLED
FAILED
PROOF_REJECTED
DISPUTED
REFUNDED

23. Donor/Expert Worker

A remote execution worker SHOULD own:

sandbox creation
workspace materialization
local credential use
resource limits
network policy
process policy
execution timeout
evidence capture
result commitment
cleanup

The buyer SHOULD submit intent and inputs, not arbitrary control of the supplier's host.

24. Job Isolation

Remote jobs SHOULD run in isolated environments.

At minimum:

separate working directory
process isolation
bounded execution time
explicit filesystem scope
explicit network policy
resource limits
cleanup

Higher-assurance environments MAY use:

VM;
container;
TEE;
disposable machine;
hardware-isolated worker.

25. Provider Credentials

Provider credentials SHALL NOT be part of portable market objects.

Actum Compute SHALL NOT require suppliers to transmit:

session cookies
OAuth refresh tokens
passwords
API keys
account credentials

Credentials remain local to the execution provider unless an upstream provider explicitly defines a transferable delegation mechanism.

26. ProviderExecutionEvidence

Schema:

{
  "schema": "actum.compute.provider-execution-evidence.v1",

  "assignment_id": "assignment:...",

  "execution_challenge": "base64url:...",

  "provider": {
    "identity": "openai",
    "server_name": "..."
  },

  "model": {
    "label": "...",
    "verification": "authenticated_disclosure"
  },

  "request_commitment": "sha256:...",
  "response_commitment": "sha256:...",
  "result_commitment": "sha256:...",

  "evidence_class": "tlsnotary",

  "transcript_commitment": "sha256:...",
  "proof_commitment": "sha256:...",

  "nullifier": "sha256:...",

  "verifier": "...",

  "executed_at": "...",

  "signature": "..."
}

27. Evidence Assurance Vector

Execution SHALL NOT be represented by one ambiguous boolean such as verified=true.

Use an assurance vector.

Example:

{
  "provider_identity": "verified",
  "server_endpoint": "verified",
  "model_identifier": "verified",
  "request_binding": "verified",
  "response_binding": "verified",
  "result_binding": "verified",
  "freshness": "verified",
  "execution_environment": "unverified"
}

This permits precise buyer requirements.

28. TLSNotary Role

TLSNotary MAY provide authenticated evidence for remote provider interaction.

It can establish properties such as:

server identity;
disclosed request fields;
disclosed response fields;
request/response binding;
freshness challenge presence;
model label where included in authenticated traffic.

TLSNotary SHALL NOT be described as proving:

hidden model weights;
undisclosed internal routing;
secret system prompts;
server-side implementation details;
exact internal inference path.

29. Distill-Derived Evidence Gateway

The evidence gateway SHOULD reuse the Distill architectural pattern for:

challenge registry
provider adapters
endpoint policy
canonical parsing
canonical hashing
transcript commitments
proof nullifiers
signed receipts
local plaintext retention
selective disclosure

The generic subsystem MAY be named:

ExternalExecutionEvidence

or equivalent.

30. Replay Prevention

Execution evidence SHALL contain a replay-resistant nullifier.

Conceptual derivation:

[ N_{execution} = H( VerifierID \parallel SessionID \parallel TranscriptCommitment \parallel AssignmentID ) ]

A previously consumed nullifier MUST NOT authorize a second settlement.

31. Result Binding

The marketplace SHALL distinguish:

provider response

from:

delivered artifact

The execution receipt MUST bind the delivered result to the authenticated execution.

For example:

response_commitment
    ↓ deterministic extraction
result_commitment
    ↓
patch / answer / artifact

32. ExecutionReceipt

Schema:

{
  "schema": "actum.compute.execution-receipt.v1",

  "id": "execution:...",

  "job_id": "job:...",
  "assignment_id": "assignment:...",

  "expert_id": "expert:...",

  "execution_class": "...",

  "input_commitment": "sha256:...",
  "result_commitment": "sha256:...",

  "evidence": [],

  "assurance": {},

  "cost": {},
  "latency_ms": 0,

  "started_at": "...",
  "completed_at": "...",

  "proof_nullifier": "sha256:...",

  "issuer": "...",

  "signature": "...",

  "actum_receipt": null
}

33. Actum ExecutionAct

A successful verified execution SHOULD generate an Actum ExecutionAct.

Conceptually:

ExecutionAct
├── JobIntent commitment
├── JobAssignment commitment
├── input-state commitment
├── result commitment
├── execution receipt commitment
├── evidence commitments
├── assurance vector
├── authority
└── finality

Actum finality proves that this execution claim entered finalized network history.

34. ZeroK Integration

ZeroK MAY prove private execution predicates without revealing witnesses.

Example proof:

ValidExecutionProof

may prove:

assignment exists
AND
TLSNotary evidence verifies
AND
required provider class satisfied
AND
required model class satisfied
AND
request commitment matches job
AND
result commitment matches execution
AND
price <= buyer maximum
AND
seller is authorized recipient
AND
nullifier unused

without exposing sensitive values.

35. Public and Private Inputs

A settlement ZK proof SHOULD minimize public inputs.

Potential public inputs:

job_nullifier
execution_commitment
settlement_commitment
proof_version
network/domain separator

Potential private witnesses:

buyer identity
seller identity
exact prompt
exact response
exact price
provider identity
model identity
evaluation data

depending on policy.

36. Confidential Market Modes

Recommended market privacy modes:

PUBLIC

Visible:

buyer
seller
provider
model
price
execution

PSEUDONYMOUS

Visible:

commitment identities
provider/model
price
execution class

PRIVATE

Visible:

required predicates satisfied
execution commitment
settlement commitment

Exact buyer, seller, provider/model, price, prompt, and response MAY remain private.

37. SettlementIntent

Schema:

{
  "schema": "actum.compute.settlement-intent.v1",

  "job_id": "job:...",

  "payer_commitment": "sha256:...",
  "payee_commitment": "sha256:...",

  "asset": "...",

  "amount_commitment": "sha256:...",

  "condition": {
    "execution_status": "VERIFIED",
    "required_assurance": {}
  },

  "expiry": "...",

  "nullifier_policy": "single_settlement"
}

38. Settlement Condition

Payment SHALL be conditionally authorized only if required predicates pass.

Typical predicate:

valid assignment
∧
valid execution
∧
required evidence
∧
required assurance
∧
result commitment delivered
∧
no prior settlement

39. SettlementAct

Schema:

{
  "schema": "actum.compute.settlement-act.v1",

  "id": "settlement:...",

  "job_id": "job:...",
  "execution_id": "execution:...",

  "asset": "...",

  "amount_commitment": "sha256:...",

  "payer_commitment": "sha256:...",
  "payee_commitment": "sha256:...",

  "settlement_nullifier": "sha256:...",

  "proof": {},

  "status": "finalized",

  "actum_receipt": "..."
}

40. Asset Neutrality

Actum Compute SHALL remain asset-neutral.

Settlement MAY use:

stablecoin
tokenized fiat
marketplace credit
bank-backed claim
native Actum asset
other supported asset

The cognitive protocol SHALL NOT depend on one monetary asset.

41. Escrow

For paid jobs, funds SHOULD be reserved before expensive remote execution begins.

Typical flow:

quote
 ↓
buyer accepts
 ↓
funds reserved
 ↓
assignment
 ↓
execution
 ↓
verification
 ↓
release

Failure MAY result in refund or partial payment according to agreed terms.

42. Partial Payment

Contracts MAY define:

zero payment on invalid proof
partial runtime reimbursement
evidence-provider fee
cancellation fee
milestone payments

Terms MUST be committed before execution.

43. Disputes

Actum Compute SHOULD distinguish cryptographic disputes from quality disputes.

Cryptographic dispute

Examples:

evidence invalid
assignment mismatch
nullifier replay
signature invalid
result commitment mismatch

These SHOULD be mechanically resolvable.

Quality dispute

Examples:

answer technically valid but poor
buyer expected something different
subjective quality disagreement

These may require:

evaluation protocol;
arbitration;
additional experts;
human adjudication.

44. Evaluation Procurement

Kline MAY request evaluation through Actum Compute.

Example:

{
  "capability": "evaluate_kline",

  "subject": {
    "id": "kline:artifact:..."
  },

  "protocol": {
    "id": "evaluation:protocol:..."
  },

  "requirements": {
    "independent_evaluators": 3
  },

  "maximum_cost": {
    "amount": "20",
    "currency": "EUR"
  }
}

Actum Compute matches evaluators.

The resulting EvaluationClaims are recorded on Actum.

Kline decides whether they justify promotion.

45. Evaluator Independence

Evaluation contracts SHOULD support independence constraints.

Examples:

not artifact publisher
not expert operator
not same organization
different evaluator clusters
different model families
different jurisdictions

Independence itself MAY require evidence.

46. Evidence Market

Evidence production can be economically separate from execution.

Example:

Expert executes
      ↓
TLSNotary provider verifies
      ↓
ZeroK proof service
      ↓
Actum recorder

Each may receive compensation.

This creates a specialized evidence market.

47. Compilation Market

Kline's Cognitive Compiler MAY procure:

distillation
benchmarking
fine-tuning
quantization
compiler optimization
GPU training
human review
artifact evaluation

through Actum Compute.

Compilation remains cognitively directed by Kline.

The market supplies scarce resources.

48. Cognitive Capital Market

K-line artifacts MAY become independently tradeable or licensable cognitive assets.

Potential pricing:

one-time license
per-execution royalty
subscription
organization license
revenue share
free/open source

Lineage SHOULD preserve attribution from source episodes and contributing experts.

49. Expert Attribution

Actum MAY preserve causal contribution chains:

Expert
  ↓
Episode
  ↓
KLineTemplate
  ↓
Compilation
  ↓
Artifact
  ↓
downstream executions

Protocol 0.2 does not mandate downstream royalties but SHALL avoid destroying the metadata needed for them.

50. Reputation

Reputation SHALL be evidence-backed and contextual.

Avoid one universal number.

Possible dimensions:

capability-specific success
proof validity
completion rate
latency reliability
quality under protocol
dispute rate
evaluation independence
availability reliability

51. ReputationClaim

Schema:

{
  "schema": "actum.compute.reputation-claim.v1",

  "subject": "expert:...",

  "capability": "software_engineering",

  "metric": "verified_completion_rate",

  "value": 0.982,

  "population": 1204,

  "protocol": "...",

  "evidence": [],

  "evaluator": "...",

  "issued_at": "...",

  "expires_at": "..."
}

52. Private Reputation

ZeroK MAY allow an expert to prove:

completed_jobs >= 1000

verified_completion_rate >= 0.98

dispute_rate < 0.02

without revealing the underlying customers or jobs.

53. Pricing Models

Actum Compute MAY support:

fixed price
auction
reverse auction
spot pricing
reserved capacity
subscription
per-job
per-time
per-compute-unit
success fee
royalty
revenue share

54. Agent Compute Units

Normalized units MAY help compare heterogeneous execution costs.

An optional AgentComputeUnit MAY incorporate:

provider
model
input size
output size
agent duration
tool execution
context
local compute
energy

However ACU SHALL NOT replace explicit execution quality or model identity where those matter.

55. Quality Differentiation

The marketplace SHALL NOT assume two model outputs are fungible merely because they consume equal compute.

Price discovery MAY differentiate:

model family
model version
quality
provider
evidence
latency
privacy
historical performance
tool access
context

This is fundamental to the expert-market thesis.

56. Latest/Flagship Model Classes

Markets MAY define dynamic classes such as:

current_flagship_coding
current_frontier_reasoning
current_frontier_multimodal

A dynamic class SHALL have:

resolver authority
effective date
provider definition
supersession semantics

Historical executions MUST preserve the exact model label evidenced at execution time.

57. Provider Downgrade Protection

Where model quality is contracted, execution evidence SHOULD prove the disclosed provider/model identifier.

A supplier MUST NOT satisfy:

required: flagship model

with:

cheaper model
cached output
local dummy response

unless the buyer's contract explicitly permits substitution.

58. Supplier Autonomy

The buyer contracts for cognition, not remote interactive ownership of the supplier's account.

The supplier worker SHOULD retain control of:

provider session
sandbox
execution environment
credential storage
resource policy

Interactive execution MAY be supported through bounded protocol commands but SHOULD NOT expose unrestricted host control.

59. Buyer API Surface

The buyer-facing MCP façade SHOULD remain small.

Recommended tools:

compute.search
compute.quote
compute.submit
compute.status
compute.verify
compute.cancel

Optional:

compute.dispute
compute.fetch_result
compute.evaluate

60. Supplier API Surface

Recommended tools:

capacity.status
capacity.configure
capacity.offer
capacity.pause
capacity.jobs
capacity.earnings

Expert-specific extensions MAY be added.

61. Evaluator API Surface

Recommended tools:

evaluation.offer
evaluation.accept
evaluation.submit
evaluation.status

62. Artifact API Surface

Recommended tools:

artifact.search
artifact.quote
artifact.acquire
artifact.verify
artifact.execute

63. Agent Plugin Distribution

Actum Compute SHOULD be distributed through separate Agent Plugins for separate authority domains.

Recommended packages:

actum-compute-buyer

actum-compute-provider

actum-compute-evaluator

actum-compute-artifacts

A combined plugin MAY exist but MUST preserve explicit authority boundaries.

64. Installation Is Not Authorization

Installing a provider plugin SHALL NOT automatically publish capacity.

The provider MUST explicitly create or enable an offer.

Similarly:

installing buyer plugin
≠ permission to spend money

installing evaluator plugin
≠ authority to issue trusted evaluations

65. Agent Plugin Package

Conceptual layout:

actum-compute-provider/
├── plugin.json
├── skills/
│   ├── offer-capability/
│   │   └── SKILL.md
│   ├── configure-reserve/
│   │   └── SKILL.md
│   ├── inspect-jobs/
│   │   └── SKILL.md
│   └── inspect-earnings/
│       └── SKILL.md
└── mcp.json

Plugin manifests SHOULD expose the narrow façade, not internal Actum/TLSNotary/ZeroK complexity.

66. Agent Plugin Skills

Skills SHOULD teach agents semantic workflow.

Example buyer skill:

When external cognition is required:

1. Derive the minimum CapabilityRequirement.
2. Minimize unnecessary data disclosure.
3. Query Actum Compute.
4. Apply local trust/admissibility policy.
5. Request a quote if economic commitment is required.
6. Obtain required authorization.
7. Submit the job.
8. Verify evidence.
9. Validate result.
10. Commit relevant episode evidence to Kline.

67. Kline Integration

Kline SHALL call Actum Compute through capability requirements.

Canonical boundary:

Kline activation graph
        ↓
CapabilityRequirement
        ↓
Actum Compute
        ↓
candidate bindings
        ↓
Cognitive Kernel
        ↓
chosen ExpertBinding

Actum Compute SHALL NOT promote or demote K-lines.

68. Episode Integration

After remote execution, Kline SHOULD record:

ExpertBinding
ExecutionReceipt
Actum ExecutionAct
cost
latency
result commitment
evaluation

inside the corresponding KLineEpisode.

69. System-1 Use of Actum Compute

System 1 MAY invoke Actum Compute when a promoted K-line includes a remote capability requirement.

However local compiled artifacts SHOULD be preferred where they satisfy the same quality and policy constraints at lower total cost.

70. System-2 Use of Actum Compute

System 2 MAY use the market more broadly to:

discover novel experts
try alternative expert combinations
purchase independent critique
buy evaluation
buy evidence
acquire datasets
rent compute
commission artifact compilation

This is where the market primarily finances the cognitive frontier.

71. Higher-Order Market Composition

One ExpertOffer MAY itself resolve internally to several experts.

Example:

ExpertOffer:
    capability = complete_security_audit

Internally:

static analyzer
+
frontier reasoning expert
+
dependency scanner
+
human reviewer

The buyer contracts with the composite expert.

Its evidence SHOULD still expose the assurance required by contract.

72. Recursive Capability Resolution

Actum Compute implementations MAY resolve a requested capability recursively.

Example:

compile_mobile_kline
    ↓
requires:
    model trainer
    evaluator
    GPU compute

Recursive procurement MUST preserve budget and authority constraints.

73. Budget Propagation

Composite jobs SHALL propagate bounded budget.

If:

parent max = €10

subjobs MUST NOT cumulatively exceed the parent authorization unless new authority is obtained.

74. Authority Separation

Actum Compute does not grant application authority.

A purchased expert may produce:

recommendation
proposal
patch
plan

Actual world mutation MAY require separate authorization.

Example:

Expert suggests transfer €500
        ↓
Kline produces proposal
        ↓
authorization system
        ↓
Actum execution

75. Actum as Economic State Substrate

Actum SHOULD record critical market transitions.

Recommended acts:

OfferPublicationAct
JobIntentAct
AssignmentAct
ExecutionAct
EvaluationAct
ArtifactPublicationAct
SettlementAct
DisputeAct
SupersessionAct

Not every ephemeral market query needs to be anchored.

76. Minimal On-Actum Disclosure

Actum SHOULD record commitments rather than unnecessary plaintext.

Typical execution act may expose:

job commitment
assignment commitment
execution commitment
evidence commitment
settlement state

while private job content remains elsewhere.

77. Storage Architecture

Recommended separation:

ACTUM
durable commitments/finality

ZEROK
private proof witnesses

BUYER/SUPPLIER
private job material

OBJECT STORAGE
encrypted artifacts/proofs

KLINE/SURREALDB
local episodes and cognitive state

78. Evidence Retention

Evidence policies MAY specify:

full local transcript retained

portable proof retained

commitment only retained

proof expires

selective disclosure only

Market contracts SHOULD explicitly define evidence retention requirements.

79. Failure Semantics

Failures SHALL distinguish:

provider failure
supplier failure
market failure
evidence failure
quality failure
privacy failure
authorization failure
settlement failure

Each class MAY have different retry/refund semantics.

80. Reassignment

If an assignment fails before irreversible execution, the marketplace MAY reassign to another admissible expert.

The new assignment SHALL receive a fresh challenge.

Old assignment evidence MUST NOT authorize the new settlement.

81. Idempotency

Market mutations SHOULD support idempotency keys.

Operations such as:

create job
accept quote
publish offer
settle

MUST avoid duplicate economic side effects on retry.

82. Economic Nullifiers

At minimum distinguish:

execution_nullifier
settlement_nullifier
evaluation_nullifier

A single nullifier SHOULD NOT be overloaded across unrelated semantic purposes.

83. Market Integrity

Implementations SHOULD mitigate:

wash trading
Sybil suppliers
fake evaluations
collusion
self-dealing
capacity spoofing
benchmark manipulation
evidence replay
price manipulation
front-running

Mechanisms MAY include:

stake
reputation
proofs
delayed settlement
independent evaluation
identity assurance
statistical anomaly detection

84. Open Markets vs Curated Markets

Actum Compute MAY expose:

Open market

Anyone satisfying base protocol requirements may offer capability.

Curated market

Only suppliers satisfying defined trust/evaluation conditions appear.

Private market

Organization-specific suppliers and prices.

The Kline CapabilityRequirement MAY specify acceptable market classes.

85. Jurisdiction

Offers and jobs MAY include jurisdiction constraints.

Examples:

EU execution only
medical data cannot leave Sweden
human evaluator licensed in jurisdiction X
no processing in jurisdiction Y

Enforcement evidence MAY require external attestation.

86. Privacy-Preserving Matching

ZeroK MAY support private matching.

Example:

Buyer proves:

budget >= required price

Supplier proves:

quality >= threshold

without either revealing exact values before match.

This is optional for protocol 0.2.

87. Private Auctions

Future markets MAY support sealed-bid auctions using commitments and ZK proofs.

The base protocol SHALL leave room for this but does not mandate an auction construction.

88. Human Experts

Humans MAY participate as ExpertDescriptors.

Human evidence MAY include:

professional credential
signed work receipt
identity assurance
evaluation history

Human participation is economically equivalent to other scarce cognitive supply, though execution semantics differ.

89. Organization Experts

Organizations MAY publish composite experts representing:

teams
clinics
engineering groups
research organizations
certification bodies

The expert abstraction does not require one executing model or person.

90. Local Experts

A Mind MAY register local experts with Actum Compute or resolve them privately without market publication.

Examples:

on-device model
private RAG
company-internal model
local tool
personal K-line artifact

No marketplace transaction is required for local resolution.

91. Market Fallback

Kline MAY define fallback chains:

local artifact
   ↓ if inadequate
private org expert
   ↓
Actum Compute verified expert
   ↓
frontier provider-specific execution
   ↓
human escalation

Fallback policy belongs to the cognitive template/local Mind.

92. Model Independence Without Model Commoditization

Actum Compute SHALL preserve two apparently opposing properties:

K-line templates can remain vendor-independent.
Execution contracts can demand exact provider/model classes when quality requires it.

This is achieved through late binding plus explicit execution requirements.

93. Verified Model Identity

Where a model identifier appears in authenticated provider traffic, TLSNotary MAY prove the provider returned that label.

The market SHOULD describe this as:

authenticated provider/model-label evidence

rather than proof of hidden server internals.

94. Dynamic Quality Claims

Expert quality SHOULD be updated from evidence-backed evaluations and episodes.

Quality claims SHALL decay or expire where relevant.

A model's performance SHALL NOT be assumed timeless.

95. Market Discovery

Discovery MAY use:

capability taxonomy
semantic search
K-line semantic fingerprints
expert descriptors
evaluation history
price
availability
trust

Discovery results are not automatically admissible.

96. Capability Taxonomy

Actum Compute SHOULD support hierarchical capabilities.

Example:

software_engineering
├── debugging
├── code_review
├── architecture
├── test_generation
└── security_review

Semantic extensions MAY allow expert capabilities to evolve without one centrally controlled ontology.

97. Capability Equivalence

Two capability descriptions MAY be semantically similar without identical IDs.

Resolution MAY use semantic matching, but final binding MUST record the exact requirement and offer that were matched.

98. Evidence Classes

Recommended evidence class vocabulary:

self_attested
signed_runtime
provider_authenticated
tlsnotary
tee_attested
model_hash_attested
deterministic_replay
human_verified
zero_knowledge_verified
actum_finalized

Execution contracts MAY require combinations.

99. Assurance Profiles

Named assurance profiles MAY simplify procurement.

Example:

STANDARD
signed runtime receipt

VERIFIED_PROVIDER
provider-authenticated evidence

VERIFIED_BOUND
provider + request + result binding

CONFIDENTIAL_VERIFIED
verified bound execution + ZeroK settlement

Profiles MUST expand to explicit requirements.

100. Economic Thesis

Actum Compute is not fundamentally a token marketplace.

Its economic object is scarce cognitive capability.

The market finances:

novel reasoning
specialized expertise
evaluation
evidence
training
compilation
compute

As cognition becomes compiled into reusable K-line artifacts, repeated demand for expensive expert execution SHOULD decline.

Capital and expert attention can move toward unsolved frontier problems.

101. Cognitive Capital Flywheel

The canonical economic flywheel is:

UNSOLVED PROBLEM
       ↓
Kline System 2
       ↓
Actum Compute procures scarce experts
       ↓
verified successful Episode
       ↓
KLineTemplate
       ↓
evaluation market
       ↓
promotion
       ↓
Cognitive Compiler
       ↓
KLineArtifact
       ↓
artifact distributed through Actum Compute
       ↓
cheap repeated System-1 execution
       ↓
economic value accumulates around cognitive capital
       ↓
scarce expertise moves to next frontier

102. Why Actum Compute Is Strategically Distinct

Traditional compute markets sell:

CPU
GPU
storage
bandwidth

Traditional model markets sell:

tokens
API calls
models

Actum Compute sells:

verifiable access to problem-solving capability and reusable cognition.

This includes compute but extends above it.

103. Initial MVP Profile

The first interoperable implementation SHOULD remain narrower than the complete protocol.

Recommended Actum Compute 0.2 MVP:

one buyer plugin

one provider plugin

Codex coding expert

Git-based asynchronous jobs

subscription-backed local Codex worker

TLSNotary provider execution evidence

Distill-derived challenge/nullifier gateway

ZeroK settlement adapter

Actum JobIntent / ExecutionAct / SettlementAct

Kline CapabilityRequirement interface

104. MVP User Story — Buyer

The user says:

Continue this coding task using verified flagship coding capability. Spend no more than €3.

Kline creates:

CapabilityRequirement

Actum Compute:

searches
quotes
matches
funds
assigns

A supplier executes.

TLSNotary generates evidence.

Actum finalizes the execution.

Settlement releases.

Kline records the resulting Episode.

105. MVP User Story — Supplier

The supplier says:

Offer my unused verified coding capability while I'm idle. Keep 30% of my capacity for myself and don't accept jobs below €1.

The provider plugin creates:

ExpertOffer

The worker remains locally authenticated.

Jobs execute only while supplier policy permits.

106. MVP User Story — Kline

Kline sees an unfamiliar software task.

No promoted System-1 K-line satisfies it.

System 2 requests:

capability:
    software_engineering

quality:
    frontier

evidence:
    provider_authenticated

budget:
    €3

Actum Compute provides a candidate.

The execution becomes a new KLineEpisode.

Repeated successful episodes may later produce a reusable K-line.

107. Conformance Requirements

A conformant Actum Compute implementation MUST:

accept capability-based demand;
represent supplier offers independently from buyer jobs;
preserve buyer and supplier commitments;
support explicit execution/evidence requirements;
distinguish execution from settlement;
prevent evidence replay;
prevent duplicate settlement;
preserve provider credentials outside portable market objects;
record evidence-bound executions;
integrate with Actum for finalized economic acts;
support Kline CapabilityRequirement;
keep market resolution separate from cognitive activation;
support explicit supplier opt-in;
support lifecycle and expiry of offers and assignments;
preserve exact execution provenance.

108. Recommended Conformance

Mature implementations SHOULD:

support Agent Plugins;
support MCP;
support A2A;
support TLSNotary;
support ZeroK;
support evaluation markets;
support artifact markets;
support private reputation;
support supplier reserve policies;
support multiple economic assets;
support human experts;
support jurisdiction policy;
support composite experts.

109. Security Considerations

Threats include:

credential theft
malicious buyer jobs
supplier sandbox escape
provider impersonation
model downgrade
result substitution
proof replay
settlement replay
fake evaluations
Sybil experts
collusion
market manipulation
prompt injection
data exfiltration
artifact poisoning

Execution workers and evidence verifiers SHALL be treated as security-critical components.

110. Privacy Considerations

Sensitive information MAY exist at every boundary:

buyer → market
market → supplier
supplier → AI provider
execution → evidence service
settlement → Actum

The architecture SHOULD minimize disclosure independently at each boundary.

ZeroK SHOULD be used where public verifiability is required without public disclosure.

111. Relationship to Kline

Kline is the system that asks:

What cognition should become active?

Actum Compute answers:

What supply can satisfy that cognition requirement?

The two SHALL remain separately evolvable.

Actum Compute does not need to understand K-line promotion.

Kline does not need to understand market matching algorithms.

Their primary shared object is:

CapabilityRequirement

and their primary returned fact is:

ExpertBinding

112. Relationship to Actum

Actum Compute is built on Actum.

Actum provides:

verifiable actions
identity
commitments
evidence references
lineage
finality
settlement state
asset transfer

Actum Compute adds:

expert markets
capability resolution
pricing
matching
execution procurement
artifact distribution
evaluation procurement

113. Relationship to TLSNotary

TLSNotary provides one external evidence class.

It is especially valuable where:

provider identity matters
model identity matters
supplier could substitute a cheaper execution

The market treats TLSNotary evidence as an execution assurance asset.

114. Relationship to ZeroK

ZeroK allows Actum Compute to prove:

the market contract was satisfied

without disclosing all underlying commercial or cognitive information.

This permits a public verifiable market with private cognition.

115. Relationship to Agent Plugins

Agent Plugins package Actum Compute for installation into agents.

They provide:

skills
+
MCP façade

They do not replace the underlying protocol.

The same Actum Compute infrastructure MAY therefore be used by:

Codex
Claude
Gemini
other agent runtimes
personal Minds
enterprise agents

116. Architectural Definition

Actum Compute is:

A verifiable market and execution fabric for acquiring, supplying, evaluating, distributing, and settling scarce cognitive capabilities and compiled cognitive artifacts.

Its fundamental transaction is not:

buy tokens.

It is:

resolve and fulfill a capability requirement under explicit quality, evidence, privacy, trust, latency, and economic constraints.

117. Strategic Objective

The long-term objective of Actum Compute is to efficiently allocate scarce cognition at the frontier while allowing Kline to continuously convert successful frontier cognition into reusable System-1 capital.

The relationship is therefore:

ACTUM COMPUTE
allocates scarce intelligence

KLINE
learns from its successful organization

COGNITIVE COMPILER
turns learned cognition into abundance

ACTUM
preserves the verifiable economic and evidentiary history

The economic system should progressively move value creation from repeated token consumption toward the creation, verification, evaluation, and distribution of reusable cognition.

Volume IV should be “Actum Verifiable Cognition Profile 0.1.” That is where we define the actual Actum-side schemas and state transitions for ExecutionAct, EvaluationAct, KLineEpisodeAct, PromotionAct, CompilationAct, ArtifactPublicationAct, SettlementAct, lineage, VSTP mappings, evidence vectors, nullifiers, and how ZeroK/TLSNotary proofs become finalized claims rather than merely marketplace metadata.

Volume IV — Actum Verifiable Cognition Profile

Volume IV defines how cognition becomes durable verifiable history. It specifies execution evidence, evaluation, promotion, compilation, publication, supersession, settlement, and the relationship between private cognitive payloads and public commitments.

The volume is split into five publication chapters because its protocol surface is substantially larger than the earlier foundation volumes.

The governing principle is:

Actum records what was claimed, evidenced, authorized, and finalized; it does not manufacture truth.

Distributed Cognitive Network

Volume IV

Actum Verifiable Cognition Profile 0.1

Part 1

Philosophy, Object Model, Canonical Acts, and VSTP Mapping

1. Purpose

This specification defines how cognition becomes a verifiable historical object.

Previous volumes define:

how Minds think,
how K-lines learn,
how experts are discovered,
how markets allocate scarce cognition.

This volume defines how those events become:

verifiable,
attributable,
replay-resistant,
economically meaningful,
permanently referencable.

This document extends Actum with a cognition profile.

Actum itself remains domain-neutral.

The cognition profile specializes it for AI.

2. Philosophy

Traditional blockchains record:

transfer

swap

contract call

NFT mint

governance vote

Those are financial or computational acts.

Our architecture treats cognition itself as something that produces verifiable acts.

Examples:

expert executed

episode completed

evaluation performed

K-line promoted

artifact compiled

artifact published

artifact superseded

settlement completed

These become first-class network objects.

3. Fundamental Principle

Actum never stores:

"truth"

Actum stores:

verifiable claims

Those claims consist of:

who asserted something,
under which authority,
supported by which evidence,
concerning which objects,
producing which state transition.

Everything else remains interpretation.

4. The Core Abstraction

The entire architecture is based on one concept.

Everything important is an:

Act

Formally:

Act

=

Authorized

State

Transition

+

Evidence

The evidence may be:

TLSNotary
ZeroK proof
Evaluation
Human signature
TEE
Local runtime
Deterministic replay

or something invented ten years from now.

Actum itself remains evidence-neutral.

5. State

Actum reasons about state.

Not objects.

Objects merely participate in state transitions.

Example:

Before

Artifact

status = candidate

↓

PromotionAct

↓

After

Artifact

status = promoted

The promoted artifact is not "stored by the PromotionAct."

The PromotionAct explains:

why the state changed.

6. Every Act Has Four Parts

Every cognition act SHALL contain:

Intent

Authority

Evidence

Transition

or graphically:

Intent
      │
Authority
      │
Evidence
      │
Transition

Removing any one of these weakens the system.

7. Intent

Intent answers:

What was supposed to happen?

Examples:

Execute coding task.

Evaluate artifact.

Compile K-line.

Promote candidate.

Purchase execution.

Publish artifact.

Intent is never inferred.

It is explicit.

8. Authority

Authority answers:

Who was allowed to request this?

Examples:

buyer

organization

human

agent

delegation

policy

contract

Authority is distinct from cognition.

An excellent K-line does not acquire authority merely because it is successful.

9. Evidence

Evidence answers:

Why should anyone believe this happened?

Evidence examples:

TLSNotary

TEE

ZeroK

Evaluation

Signed runtime

Human review

Benchmark

External certificate

Evidence is attached.

Not embedded.

10. Transition

Transition answers:

What changed?

Examples:

Job

OPEN

↓

VERIFIED

Artifact

candidate

↓

promoted

K-line

active

↓

superseded

The transition is the thing Actum finalizes.

11. VSTP

VSTP remains the semantic model.

Recall:

S_i

↓

Action

↓

S_i+1

Every cognition act is therefore:

Prior State

+

Intent

+

Authority

+

Evidence

↓

Resulting State

This is now the canonical Actum pattern.

12. General Act Schema

Every Act SHALL contain:

ActID

Type

Subject

Intent

Authority

Evidence

Prior State Commitment

Result State Commitment

Timestamp

Issuer

Version

Extensions MAY add fields.

Core semantics remain stable.

13. Subject

An Act always concerns one or more subjects.

Examples:

Expert

Artifact

Template

Episode

Evaluation

Settlement

Execution

Market Offer

Subjects remain external objects.

Acts describe changes concerning them.

14. Canonical Cognition Acts

Version 0.1 defines:

ExecutionAct

EvaluationAct

PromotionAct

CompilationAct

ArtifactPublicationAct

SupersessionAct

SettlementAct

KLineEpisodeAct

Later versions may extend this list.

15. ExecutionAct

ExecutionAct records:

this cognitive execution occurred.

It does not state:

this answer is correct.

It states:

these inputs,
this execution,
this evidence,
this result commitment,
this authority.

16. EvaluationAct

EvaluationAct records:

an evaluation was performed.

It contains:

protocol,
evaluator,
environment,
distribution,
metrics,
evidence.

It never claims universal correctness.

17. PromotionAct

PromotionAct records:

cognition moved into System 1.

Promotion is therefore historical.

It can later be revoked.

18. CompilationAct

CompilationAct records:

Artifact B was produced from Template K using Episodes E.

This creates permanent lineage.

19. ArtifactPublicationAct

Publishing is separate from compilation.

An artifact might exist privately.

Publishing creates:

discoverable

shareable

licensable

state.

20. SupersessionAct

Nothing disappears.

Old artifacts remain.

New artifacts supersede them.

History remains intact.

21. SettlementAct

SettlementAct represents:

economic completion.

Importantly:

Settlement SHALL reference Execution.

Execution SHALL NOT reference Settlement.

This preserves causality.

22. KLineEpisodeAct

Episodes are perhaps the most important object.

An episode records:

Problem

↓

Activation

↓

Bindings

↓

Execution

↓

Evidence

↓

Outcome

That entire trajectory becomes historically referencable.

23. Act Lineage

Acts themselves form a graph.

Example:

Execution

↓

Evaluation

↓

Promotion

↓

Compilation

↓

Publication

↓

Settlement

Each act references previous acts.

Therefore cognition itself becomes lineage.

24. Why Acts Instead of Objects?

Objects answer:

What is this?

Acts answer:

How did it become this?

For cognition,

history matters.

25. Commitments

Acts should rarely store raw data.

Instead:

Prompt

↓

SHA256

↓

Commitment

Likewise:

Response

↓

Commitment

Likewise:

Artifact

↓

Commitment

This makes privacy much easier.

26. Mutable vs Immutable

Mutable:

SurrealDB

Current K-line

Current trust

Current goals

Current world state

Immutable:

Actum

Execution history

Promotion history

Compilation history

Settlement history

This separation is fundamental.

27. Local Interpretation

Actum says:

Evaluation happened.

Kline says:

I trust this evaluation.

Those are intentionally separate.

28. Replay Resistance

Every Act SHALL have:

Act ID

Commitment

Nullifier

The nullifier prevents:

duplicate settlement,

duplicate evaluation,

duplicate promotion,

duplicate execution claims.

29. Versioning

Acts SHALL never silently change.

Instead:

Version 1

↓

Version 2

↓

Version 3

through explicit supersession.

30. Human Readability

Although canonical serialization is deterministic,

Acts should also expose:

Summary

Description

Reason

to make provenance understandable by humans.

31. Machine Readability

Every semantic field SHALL also possess deterministic machine encoding.

Human explanations never replace canonical fields.

32. The Ledger of Cognition

Traditional ledgers record:

money.

Actum records:

history.

This cognition profile records:

the history of learned intelligence.

That is the defining idea of the architecture.

The network no longer merely accumulates facts.

It accumulates verifiable cognitive evolution.

33. Architectural Invariants

The following invariants SHALL hold:

Every important cognitive transition is represented as an Act.
Objects remain mutable; Acts remain immutable.
Provenance never replaces evaluation.
Evaluation never replaces authority.
Authority never replaces evidence.
Settlement always follows verified execution.
Promotion is historical, not permanent.
Compilation preserves lineage.
Supersession never destroys history.
The ledger records cognition, not merely computation.

34. Strategic Thesis

Software engineering transformed computation by making code reusable.

This architecture aims to transform intelligence by making successful cognition reusable, attributable, verifiable, and economically meaningful.

Actum is therefore not simply a settlement layer.

It becomes the permanent historical record of the network's evolving cognitive capital.

Every verified episode, every promoted K-line, every compiled artifact, every independent evaluation, and every economic settlement contributes to a shared, immutable history from which future cognition can learn without sacrificing local autonomy or trust.

Distributed Cognitive Network

Volume IV

Actum Verifiable Cognition Profile 0.1

Part 2

Canonical Act Schemas, Evidence Graph, Assurance Vectors, Lineage, Hashing and Nullifiers

35. Purpose

Part 1 introduced the philosophy.

Part 2 defines the canonical protocol objects.

The objectives are:

deterministic representation;
replay resistance;
cryptographic commitments;
causal lineage;
extensible evidence;
implementation neutrality.

Every compliant implementation SHALL produce identical hashes for identical semantic Acts.

36. Canonical Serialization

All Acts SHALL serialize canonically.

Requirements:

UTF-8

deterministic ordering

explicit null handling

RFC3339 timestamps

canonical floating point

canonical URI normalization

stable array ordering where ordering is semantic

Implementations MAY internally use CBOR, JSON, protobuf, FlatBuffers or another format.

Canonical hashing SHALL always operate on the canonical semantic representation.

37. Act Identity

Every Act possesses three identifiers.

ActID

ContentHash

SemanticHash

37.1 ActID

Globally unique identifier.

Example:

act:execution:01J...

Never reused.

37.2 ContentHash

Represents exact bytes.

SHA256(canonical bytes)

Changing whitespace changes ContentHash.

37.3 SemanticHash

Represents semantic identity.

Fields excluded:

timestamps

display strings

non-semantic metadata

compression

encoding

Changing serialization MUST NOT change SemanticHash.

38. Domain Separation

Every hash SHALL include explicit domain separation.

Example:

H(

"ACTUM_EXECUTION_V1"

||

canonical_object

)

Examples:

ACTUM_EXECUTION_V1

ACTUM_EVALUATION_V1

ACTUM_PROMOTION_V1

ACTUM_COMPILATION_V1

This prevents accidental cross-object collisions.

39. Canonical Act Header

Every Act SHALL begin with:

{
  "schema":"...",
  "version":"1.0.0",

  "act_id":"...",

  "type":"ExecutionAct",

  "issuer":"did:...",

  "created_at":"...",

  "content_hash":"...",

  "semantic_hash":"..."
}

40. Canonical Body

Every Act SHALL contain:

Subject

Intent

Authority

Evidence

PriorState

ResultState

This body is shared by all cognition Acts.

41. Subject

The subject identifies what the transition concerns.

Example:

{
    "type":"KLineArtifact",

    "id":"artifact:...",

    "commitment":"sha256:..."
}

Acts MAY concern multiple subjects.

42. Intent

Intent SHALL describe the requested transition.

Examples:

execute

compile

publish

evaluate

promote

supersede

settle

Intent is immutable.

43. Authority

Authority SHALL reference:

principal

delegation

policy

scope

expiry

Authority SHALL NOT be inferred from evidence.

44. Prior State Commitment

Rather than embedding state,

Acts SHOULD reference:

PriorStateCommitment

Example:

Artifact

candidate

↓

hash

45. Result State Commitment

Likewise:

ResultStateCommitment

represents the state after transition.

46. State Difference

Acts MAY additionally expose:

PatchCommitment

representing the semantic difference.

This enables:

replay,
auditing,
deterministic reconstruction.

47. Evidence Graph

Earlier drafts treated Evidence as a list.

This specification replaces that with:

EvidenceGraph

Conceptually:

Execution

│

├── TLSNotary

│

├── Human review

│

├── ZeroK

│

├── Benchmark

│

└── Previous Act

Evidence becomes composable.

48. Evidence Nodes

Each evidence node contains:

Type

Issuer

Commitment

Confidence

Timestamp

Dependencies

Dependencies permit recursive evidence.

49. Evidence Edge

Edges define:

supports

derived_from

verifies

references

supersedes

contradicts

Contradictory evidence is permitted.

Interpretation belongs elsewhere.

50. Evidence Types

Version 0.1 defines:

TLSNotary

ZeroK

TEE

RuntimeSignature

Evaluation

Human

Benchmark

Certificate

ActReference

Future extensions are expected.

51. Evidence Commitments

Acts SHALL store:

EvidenceCommitment

rather than arbitrary raw payload.

The payload may remain elsewhere.

52. Assurance Vector

A binary:

verified=true

is insufficient.

Every Act SHALL instead expose an:

AssuranceVector

53. Assurance Dimensions

Recommended dimensions:

identity

authority

execution

provider

model

request_binding

response_binding

artifact_binding

evaluation

privacy

freshness

replay_resistance

settlement

finality

Each dimension possesses independent status.

54. Assurance States

Each component MAY be:

unknown

claimed

verified

cryptographically_verified

attested

not_applicable

Avoid collapsing these into one score.

55. Example Assurance Vector

{

"provider":"verified",

"model":"verified",

"request_binding":"verified",

"response_binding":"verified",

"evaluation":"claimed",

"authority":"verified",

"settlement":"pending"

}

56. Trust Vector

Trust is distinct.

Trust belongs to local interpretation.

Example:

publisher

evaluator

expert

artifact

organization

Each has independent trust.

Trust SHALL NOT be embedded into immutable Acts.

57. Confidence

Confidence is not trust.

Confidence estimates:

probability

uncertainty

calibration

coverage

Confidence belongs to evidence.

Trust belongs to Minds.

58. Lineage

Acts form:

Directed Acyclic Graph

Each node references parents.

Example:

Episode

↓

Evaluation

↓

Promotion

↓

Compilation

↓

Artifact

59. Parent References

Every Act MAY declare:

Parents

Example:

{
"parents":[

"act:evaluation:...",

"act:execution:..."

]
}

60. Child Discovery

Children SHALL NOT be embedded.

They are discovered by graph traversal.

This preserves immutability.

61. Multiple Parents

Acts MAY possess multiple parents.

Example:

Compilation

↓

Episode A

Episode B

Episode C

The graph therefore naturally supports many-to-many lineage.

62. Forks

Forks are normal.

Example:

Artifact

↓

Compilation A

↓

Compilation B

No special protocol required.

63. Supersession Graph

Supersession is represented by edges.

Never deletion.

Artifact A

↓

superseded_by

↓

Artifact B

64. Temporal Ordering

Acts possess:

logical order

creation time

finalization time

These are distinct.

65. Finality

Finality SHALL refer to:

inclusion in finalized Actum history.

It SHALL NOT imply:

truth.

66. Nullifiers

Every replay-sensitive Act SHALL include a:

Nullifier

67. Nullifier Domains

Separate nullifier domains.

Examples:

Execution

Settlement

Evaluation

Promotion

Compilation

Cross-domain reuse is prohibited.

68. Execution Nullifier

Conceptually:

H(

Execution

||

Challenge

||

Evidence

||

Result

)

69. Settlement Nullifier

Conceptually:

H(

ExecutionAct

||

Asset

||

Payee

)

Settlement replay is therefore impossible.

70. Promotion Nullifier

Promotion should occur once.

Nullifier:

Template

+

PromotionPolicy

71. Compilation Nullifier

Compilation is distinct.

Repeated compilations are permitted.

Therefore compilation nullifiers include:

Compiler

Template

Constraints

Different constraints produce distinct compilation lineage.

72. Graph Integrity

Every parent reference SHALL reference:

ActID

SemanticHash

This prevents silent substitution.

73. Object Integrity

Referenced objects SHALL use:

ObjectID

ContentHash

allowing mutable metadata without changing semantic identity.

74. Causal Ordering

Acts imply:

Execution

↓

Evaluation

↓

Promotion

not:

Promotion

↓

Execution

The protocol SHALL reject impossible causal ordering.

75. Graph Queries

Typical graph queries:

Where did this artifact come from?

Which evaluations justified promotion?

Which expert produced this episode?

Which settlements followed this execution?

Which K-line generated this artifact?

The protocol is designed for graph traversal rather than table lookup.

76. Canonical Relationships

Version 0.1 defines:

GENERATED

EVALUATED

PROMOTED

COMPILED

SUPERSEDED

PUBLISHED

SETTLED

SUPPORTED_BY

Future extensions remain possible.

77. Evidence Resolution

Consumers SHOULD resolve evidence lazily.

An Act references evidence.

Evidence references proofs.

Proofs reference artifacts.

Nothing is duplicated.

78. Why Graphs?

Traditional ledgers answer:

"What happened?"

Graphs answer:

"Why did it happen?"

That distinction is essential for cognition.

79. Strategic Observation

The history of intelligence is not a chain.

It is a graph.

Actum therefore becomes a graph of cognitive evolution rather than merely a chronological log of transactions.

That is why lineage, evidence, assurance, and causal relationships are first-class protocol objects rather than metadata.

Distributed Cognitive Network

Volume IV

Actum Verifiable Cognition Profile 0.1

Part 3A

ExecutionAct and EvaluationAct

80. Purpose

This section defines the two foundational Acts from which all higher cognitive history is derived.

Every PromotionAct, CompilationAct, PublicationAct, and SettlementAct ultimately depends on:

ExecutionAct

EvaluationAct

Execution establishes:

something happened.

Evaluation establishes:

someone measured what happened.

Everything else builds upon those two facts.

81. ExecutionAct

Definition

An ExecutionAct records a single completed realization of a requested cognitive capability together with the authority under which it executed, the evidence supporting it, the resulting state transition, and the commitments necessary for replay-resistant historical reconstruction.

An ExecutionAct does not claim:

that the answer is objectively correct;
that the execution should be trusted;
that the result should become System 1.

It records only:

the requested capability;
the execution;
supporting evidence;
resulting commitments;
authority;
provenance.

82. ExecutionAct Semantics

Conceptually:

Prior State
      │
      │
Capability Requirement
      │
      ▼
Execution
      │
Evidence
      │
Authority
      │
      ▼
Proposed State Transition

This is the canonical VSTP specialization.

83. ExecutionAct Lifecycle

An ExecutionAct SHALL progress through:

created
    ↓
executing
    ↓
completed
    ↓
evidence_attached
    ↓
verified
    ↓
finalized

Possible terminal failure states:

aborted

expired

invalid_evidence

rejected

superseded

84. Canonical ExecutionAct Schema

{
  "schema": "actum.execution.v1",

  "version": "1.0.0",

  "act_id": "act:execution:...",

  "subject": {
    "type": "CapabilityExecution",
    "id": "execution:..."
  },

  "intent": {
    "capability_requirement": "...",
    "objective_commitment": "sha256:..."
  },

  "authority": {},

  "prior_state": {
    "commitment": "sha256:..."
  },

  "result_state": {
    "commitment": "sha256:..."
  },

  "transition_patch": {
    "commitment": "sha256:..."
  },

  "execution": {
    "mode": "remote",
    "execution_class": "...",
    "bindings": []
  },

  "evidence_graph": {},

  "assurance": {},

  "nullifier": "...",

  "issuer": "...",

  "created_at": "...",

  "content_hash": "...",

  "semantic_hash": "..."
}

85. Prior State

Execution SHALL reference the state that existed before execution.

The state MAY include:

SurrealDB world state

repository state

conversation state

medical state

workflow state

graph state

The state itself SHOULD remain external.

ExecutionAct stores only the commitment.

86. Result State

Likewise:

result_state_commitment

represents the post-execution world.

This permits deterministic auditing without exposing private state.

87. Transition Patch

The semantic difference between states SHOULD be represented separately.

Conceptually:

Before

↓

Patch

↓

After

Patch commitment enables:

replay
audit
verification
synchronization

88. Capability Binding

Execution SHALL record the concrete realization of abstract capabilities.

Example:

CapabilityRequirement

↓

ExpertBinding

↓

Execution

Example bindings:

reasoning

↓

Verified GPT flagship

critic

↓

local artifact

retrieval

↓

organization search service

These belong to the episode, not the template.

89. Evidence Graph

Execution SHALL reference an EvidenceGraph rather than embedding proof material.

Possible nodes:

TLSNotary

TEE

Evaluation

Human signature

Runtime receipt

ZeroK proof

Benchmark

Certificate

Execution merely references those nodes.

90. Assurance Vector

Execution SHALL expose:

provider

model

authority

execution

request binding

response binding

artifact binding

freshness

privacy

finality

Each dimension SHALL remain independent.

91. Provider Identity

Where provider identity matters commercially,

ExecutionAct SHOULD distinguish:

claimed

verified

cryptographically verified

These are not equivalent.

92. Model Identity

Likewise:

claimed

authenticated

cryptographically evidenced

Execution SHALL avoid implying stronger guarantees than evidence supports.

93. Authority

Authority SHALL reference:

principal

delegation

scope

policy

expiry

Execution without authority is still historically meaningful.

It simply should not authorize side effects.

94. Side Effects

ExecutionAct SHOULD normally represent:

proposal

rather than:

mutation

The mutation occurs only after separate authorization.

95. Execution Modes

Version 1 recognizes:

local

remote

human

hybrid

artifact

Future versions may extend.

96. Hybrid Execution

An execution MAY involve multiple experts.

Example:

Local artifact

↓

Remote reasoning

↓

Human approval

↓

Local synthesis

ExecutionAct records the whole graph.

97. Nested Executions

Execution MAY invoke further executions.

Nested executions SHALL be separate Acts.

The parent references children.

Children reference parent.

98. Failure

Failure is first-class.

Execution SHALL record:

timeout

validation failure

provider unavailable

evidence failure

authority denied

execution rejected

Failures become valuable historical data.

99. Execution Replay

Execution SHALL be replay-resistant.

Execution Nullifier:

Conceptually:

Execution Challenge

+

Evidence Commitment

+

Assignment

+

Execution Result

Changing any element changes the nullifier.

100. Execution Finality

Finality means:

this execution became part of immutable Actum history.

It does NOT imply:

truth.

101. EvaluationAct

Definition

EvaluationAct records an assessment of:

execution;
artifact;
expert;
template;
K-line;
benchmark;
compilation.

Evaluation never modifies the evaluated object.

It creates additional evidence.

102. Evaluation Philosophy

Execution answers:

What happened?

Evaluation answers:

How well did it satisfy a defined protocol?

103. Evaluation Subject

Evaluation SHALL reference exactly one subject.

Examples:

ExecutionAct

Artifact

Template

Expert

Compilation

Composite evaluations are represented by multiple EvaluationActs.

104. Canonical Evaluation Schema

{
  "schema":"actum.evaluation.v1",

  "act_id":"...",

  "subject":{

      "type":"ExecutionAct",

      "id":"..."
  },

  "protocol":{

      "id":"evaluation:..."
  },

  "environment":{},

  "distribution":{},

  "metrics":{},

  "evidence_graph":{},

  "assurance":{},

  "authority":{},

  "issuer":"...",

  "created_at":"..."
}

105. Evaluation Protocol

Every evaluation SHALL reference:

Protocol

Version

Environment

Distribution

Without protocol,

evaluation is meaningless.

106. Metrics

Metrics SHOULD remain structured.

Example:

accuracy

precision

recall

latency

energy

cost

calibration

robustness

Avoid free-text scores.

107. Environment

Evaluation SHALL define:

hardware

runtime

software

configuration

dependencies

Environment drift is one reason K-lines decay.

108. Distribution

Evaluations SHALL define:

dataset commitment

sampling

coverage

population

This avoids meaningless universal quality claims.

109. Evaluation Evidence

Evaluation MAY itself possess evidence.

Examples:

benchmark

human review

TLS proof

TEE

ZeroK

external certification

Evaluation therefore participates in the EvidenceGraph.

110. Independent Evaluations

Several EvaluationActs MAY exist for the same subject.

This is expected.

Example:

Hospital A

↓

Evaluation

Hospital B

↓

Evaluation

University C

↓

Evaluation

Promotion policies decide how many independent evaluations are required.

111. Evaluation Finality

Finality means:

the evaluation happened.

Not:

the evaluation is universally correct.

112. Execution → Evaluation

Execution produces:

ExecutionAct

Evaluation produces:

EvaluationAct

The graph:

Execution

↓

Evaluation A

↓

Evaluation B

↓

Evaluation C

is the foundation for promotion.

113. Act Relationships

Execution SHALL support:

SUPPORTED_BY

GENERATED

Evaluation SHALL support:

EVALUATES

SUPPORTED_BY

Later Acts will extend these.

114. Promotion Preconditions

Promotion SHALL NOT reference raw executions directly.

It references:

EvaluationActs

This separates:

execution

from

judgement.

115. Why Separate Evaluation?

Without separation,

future evaluation protocols cannot reinterpret history.

With separate EvaluationActs,

new methodologies can revisit old executions.

That is essential for scientific progress.

116. Strategic Importance

ExecutionActs create the immutable historical record of cognition.

EvaluationActs create the immutable historical record of how that cognition was measured.

Those two layers together form the empirical foundation upon which every future K-line, compilation, artifact, promotion, economic reward, and piece of cognitive capital is built.

Everything else in the architecture is downstream of these two canonical Acts.

Distributed Cognitive Network

Volume IV

Actum Verifiable Cognition Profile 0.1

Part 3B

PromotionAct, CompilationAct and ArtifactPublicationAct

117. Purpose

Execution creates history.

Evaluation measures history.

Promotion transforms measured cognition into reusable cognition.

Compilation transforms reusable cognition into executable cognitive capital.

Publication makes that capital discoverable.

These three Acts therefore define the mechanism by which the network continually converts expensive System-2 reasoning into abundant System-1 capability.

118. Promotion Philosophy

Promotion is not:

"this K-line is correct."

Promotion means:

"according to a defined policy, there is now sufficient evidence that this KLineTemplate may participate in System 1."

Promotion is therefore:

contextual;
reversible;
historical;
policy-driven.

119. Promotion Does Not Create Truth

Promotion SHALL NOT imply:

universal correctness;
permanent validity;
universal trust;
mandatory activation.

Promotion only records:

this cognitive organization satisfied this promotion policy at this point in history.

120. Promotion Target

Promotion SHALL reference:

KLineTemplate

not:

Episode

Artifact

Episodes remain evidence.

Artifacts remain implementations.

The Template is what becomes eligible for System 1.

121. Promotion Preconditions

Promotion MAY require:

minimum episode count

minimum evaluation count

minimum evaluator independence

minimum quality

maximum failure rate

minimum coverage

minimum calibration

authority approval

absence of unresolved anomalies

Policies define thresholds.

122. Promotion Policy

Promotion SHALL reference an explicit PromotionPolicy.

Example:

{
  "policy":"promotion:v1",

  "minimum_episodes":50,

  "minimum_independent_evaluations":3,

  "minimum_quality":0.95,

  "maximum_failure_rate":0.02
}

The policy itself becomes historically referencable.

123. PromotionAct Schema

{
  "schema":"actum.promotion.v1",

  "act_id":"...",

  "template":{

      "id":"kline:template:...",

      "hash":"sha256:..."
  },

  "promotion_policy":"promotion:v1",

  "supporting_evaluations":[

  ],

  "supporting_episodes":[

  ],

  "prior_state":{

      "status":"validated"
  },

  "result_state":{

      "status":"promoted"
  },

  "authority":{},

  "evidence_graph":{},

  "assurance":{},

  "created_at":"..."
}

124. Promotion State Machine

Recommended lifecycle:

candidate

↓

validated

↓

promoted

↓

active

↓

degraded

↓

revalidation

↓

active

degraded

↓

superseded

Promotion never bypasses evaluation.

125. Promotion Lineage

Promotion SHALL preserve lineage.

Graph:

Episodes

↓

Evaluations

↓

Promotion

↓

Template

Promotion never disconnects evidence.

126. Why Promotion Exists

Without Promotion,

System 1 becomes:

"whatever happened last time."

Promotion formalizes:

repeated success has become reusable cognition.

127. Compilation

Promotion says:

this cognition may be reused.

Compilation asks:

how can this cognition execute more efficiently?

Compilation is therefore optimization.

128. Compilation Philosophy

Compilation SHALL preserve semantics.

It MAY change implementation.

Examples:

frontier model

↓

small model

five experts

↓

two experts

LLM

↓

rules

provided required quality remains.

129. Two Compilers

Version 1 recognizes:

TopologyCompiler

ArtifactCompiler

These remain conceptually distinct.

130. TopologyCompiler

Input:

Template

Episodes

Evaluations

Output:

simpler topology

Example:

7 experts

↓

4 experts

↓

2 experts

No implementation change required.

Only topology changes.

131. ArtifactCompiler

Input:

Template

Chosen topology

Episodes

Output:

Executable artifact

Examples:

fine-tuned model

classifier

mobile runtime

workflow

graph executor

symbolic engine

132. Compilation Objectives

Compilation SHALL optimize:

cost

latency

energy

memory

network

quality

Typical optimization:

[ \min(C+\lambda L+\mu E+\nu M) ]

subject to:

[ Q\ge Q_{min} ]

133. Compilation Record

Compilation SHALL preserve:

source template

compiler

episodes

constraints

objective

artifact

134. CompilationAct Schema

{
"schema":"actum.compilation.v1",

"template":{},

"compiler":{},

"episodes":[ ],

"evaluations":[ ],

"optimization":{},

"artifact":{},

"authority":{},

"evidence_graph":{},

"created_at":"..."
}

135. Compiler Identity

Compiler SHOULD be explicit.

Example:

Cognitive Compiler

Organization Compiler

Human Compiler

Research Compiler

Compilation itself becomes attributable.

136. Compilation Constraints

Examples:

iPhone only

offline

private

medical

battery optimized

GPU available

Constraints affect produced artifacts.

137. Artifact

Compilation creates:

Artifact

Artifacts are executable.

Templates are semantic.

Episodes are historical.

This distinction is fundamental.

138. Artifact Identity

Artifact SHALL possess:

ArtifactID

ContentHash

SemanticHash

and reference:

Template

Compilation

139. Artifact Types

Version 1:

workflow

graph

small model

local model

mobile runtime

classifier

rules

hybrid

Extensions expected.

140. Artifact Metadata

Artifacts SHOULD expose:

hardware

memory

energy

latency

privacy

dependencies

runtime

size

These become routing inputs.

141. Artifact Evaluation

Artifacts SHALL be independently evaluated.

Compilation does not imply quality.

Artifacts therefore accumulate their own EvaluationActs.

142. Artifact Lifecycle

Recommended:

candidate

↓

evaluated

↓

published

↓

active

↓

degraded

↓

superseded

143. Publication

Compilation creates an artifact.

Publication makes it discoverable.

These are different Acts.

144. Publication Philosophy

Publishing SHOULD NOT imply:

activation.

Publication merely means:

discoverable.

145. ArtifactPublicationAct

Schema:

{
"schema":"actum.publication.v1",

"artifact":{},

"visibility":{

"public":true

},

"license":{},

"publisher":"...",

"metadata":{},

"created_at":"..."
}

146. Visibility

Version 1:

private

organization

federation

public

147. Discovery

Publication enables:

search

download

license

purchase

evaluation

through Actum Compute.

148. Publication Does Not Grant Trust

Published artifacts remain:

untrusted

until accepted locally.

Publication never bypasses Kline trust.

149. Artifact Market

Published artifacts become:

cognitive capital

They may be:

free

licensed

subscription

royalty

private

The protocol remains neutral.

150. Cognitive Capital

An artifact is:

executable cognition.

It therefore represents accumulated cognitive investment.

Unlike model calls,

artifacts become durable assets.

151. Lineage

Publication SHALL preserve:

Template

↓

Episodes

↓

Evaluations

↓

Promotion

↓

Compilation

↓

Artifact

↓

Publication

Nothing is lost.

152. Recompilation

Artifacts MAY be recompiled repeatedly.

Example:

GPU artifact

↓

mobile artifact

↓

watch artifact

All preserve lineage.

153. Compiler Competition

Different compilers MAY produce different artifacts.

Competition occurs through:

Evaluation,

not authority.

154. Promotion Is Historical

Compilation Is Creative

Publication Is Economic

These three Acts deliberately separate:

learning,

optimization,

distribution.

Keeping them independent greatly simplifies governance.

155. Promotion and Compilation

Promotion references:

Template

Compilation references:

Template

+

Episodes

Artifacts therefore inherit:

knowledge,

not authority.

156. Strategic Observation

This is the mechanism by which intelligence becomes infrastructure.

Experts perform cognition once.

The network:

evaluates,

promotes,

compiles,

publishes,

and reuses that cognition millions of times.

That transformation—from transient reasoning into durable, reusable, executable cognitive capital—is the defining innovation of the architecture.

The PromotionAct records when a cognitive organization became eligible for reuse.

The CompilationAct records how that cognition was transformed into an efficient implementation.

The ArtifactPublicationAct records when that implementation entered the wider ecosystem as shareable cognitive capital.

Together, these three Acts define the lifecycle by which the Distributed Cognitive Network continuously expands its System-1 coverage while preserving complete provenance, evaluation history, and lineage back to the original System-2 discoveries.

Distributed Cognitive Network

Volume IV

Actum Verifiable Cognition Profile 0.1

Part 3C

SupersessionAct, SettlementAct, Conformance, Security, and End-to-End Cognitive Evolution

157. Purpose

This section completes the canonical cognition lifecycle.

Execution records cognition.

Evaluation measures cognition.

Promotion authorizes reuse.

Compilation optimizes cognition.

Publication distributes cognition.

The remaining Acts define how cognition:

evolves,
earns value,
becomes obsolete,
preserves history,
remains economically coherent.

158. Supersession Philosophy

Knowledge should never disappear.

It should become obsolete.

Deletion destroys history.

Supersession preserves history.

Every important cognitive object SHALL therefore be supersedable.

Examples:

Template

Artifact

Evaluation

Execution Class

Promotion Policy

Compilation Policy

159. Why Supersession Matters

Imagine:

Artifact A

98%

2027

Later:

Artifact B

99.3%

2030

Artifact A should remain historically meaningful.

Artifact B should become preferred.

History remains intact.

160. SupersessionAct

Definition:

A SupersessionAct records that one historical object is now preferred over another for defined reasons.

It SHALL NOT erase the superseded object.

161. SupersessionAct Schema

{
  "schema": "actum.supersession.v1",

  "act_id": "act:supersession:...",

  "subject": {
    "type": "KLineArtifact",
    "id": "artifact:A"
  },

  "replacement": {
    "type": "KLineArtifact",
    "id": "artifact:B"
  },

  "reason": {
    "category": "quality_improvement"
  },

  "supporting_evidence": [],

  "authority": {},

  "created_at": "...",

  "content_hash": "...",

  "semantic_hash": "..."
}

162. Supersession Reasons

Version 1 recommends:

quality

latency

energy

cost

privacy

security

evaluation

environment

drift

regulation

manual_revocation

163. Supersession Is Local

An organization MAY supersede an artifact.

Another organization MAY choose not to.

Supersession is historical.

Trust remains local.

164. Settlement Philosophy

Settlement is not payment.

Settlement is:

completion of an agreed economic state transition.

Payment is one possible settlement.

Others include:

credit

token

reputation

royalty

licence

resource allocation

165. Settlement Depends on Verified History

Settlement SHALL depend on:

ExecutionAct

EvaluationAct (if required)

Evidence

Authority

Policy

Not merely:

supplier says "done."

166. Settlement State Machine

Recommended:

FUNDED

↓

ASSIGNED

↓

EXECUTING

↓

VERIFIED

↓

SETTLED

Failures:

REFUNDED

DISPUTED

EXPIRED

167. SettlementAct

Definition:

SettlementAct records successful completion of an economic obligation resulting from previously finalized cognitive history.

168. SettlementAct Schema

{
  "schema": "actum.settlement.v1",

  "act_id": "act:settlement:...",

  "execution": {
    "id": "execution:..."
  },

  "payer": {
    "commitment": "sha256:..."
  },

  "payee": {
    "commitment": "sha256:..."
  },

  "asset": {},

  "amount": {},

  "proof": {},

  "nullifier": "...",

  "created_at": "...",

  "content_hash": "...",

  "semantic_hash": "..."
}

169. Settlement Preconditions

Settlement SHALL require:

valid execution

required evidence

authority

unused nullifier

required assurance

policy satisfied

170. ZeroK Settlement

Settlement MAY rely upon:

private buyer

private seller

private amount

private provider

private execution

while publicly proving:

conditions satisfied

171. Settlement Is Historical

Settlement SHALL NOT modify execution.

Execution exists independently.

Settlement merely records:

economic completion.

172. Historical Integrity

All Acts SHALL remain immutable.

Corrections occur through:

Supersession

Revocation

Additional Evaluation

Additional Evidence

Never mutation.

173. Revocation

Revocation differs from supersession.

Supersession:

prefer something newer.

Revocation:

previous object should no longer be used.

Reasons:

security

fraud

malicious

legal

catastrophic failure

174. RevocationAct

Schema follows the same canonical Act pattern.

It references:

subject

reason

authority

evidence

175. End-to-End Cognitive Evolution

Everything now fits together.

A novel problem appears.

Problem

↓

Kline has no precedent.

↓

System 2 activates.

↓

CapabilityRequirements generated.

↓

Actum Compute procures experts.

↓

Experts execute.

↓

TLSNotary proves remote execution.

↓

ExecutionActs recorded.

↓

EvaluationActs produced.

↓

PromotionAct created.

↓

Template becomes System 1 eligible.

↓

Compiler generates artifact.

↓

CompilationAct recorded.

↓

Artifact evaluated.

↓

PublicationAct created.

↓

Artifact appears in Actum Compute.

↓

Millions of Minds reuse it.

↓

New EvaluationActs accumulate.

↓

Better artifact appears.

↓

SupersessionAct recorded.

↓

Old artifact preserved forever.

↓

History continues.

176. Cognitive Evolution Graph

Execution

↓

Evaluation

↓

Promotion

↓

Compilation

↓

Publication

↓

Execution

↓

Evaluation

↓

Supersession

↓

Publication

The graph never stops growing.

177. Attribution

Every artifact SHALL retain lineage.

Conceptually:

Expert

↓

Episode

↓

Execution

↓

Evaluation

↓

Promotion

↓

Compilation

↓

Artifact

↓

Millions of uses

This enables future attribution.

178. Cognitive Capital

Unlike model calls,

artifacts accumulate.

Therefore:

Knowledge

↓

Evaluation

↓

Compilation

↓

Capital

The protocol intentionally allows capital formation.

179. Market Evolution

Initially:

Experts dominate.

Eventually:

Artifacts dominate routine execution.

Experts migrate toward:

novel cognition.

This is expected.

180. Cognitive Frontier

The frontier is:

Total capability

minus

compiled capability

Everything inside the frontier becomes future K-lines.

181. Conformance

An implementation SHALL:

✓ preserve lineage

✓ preserve immutability

✓ separate cognition from authority

✓ separate evidence from trust

✓ separate execution from settlement

✓ separate templates from artifacts

✓ support supersession

✓ support evaluation history

✓ support replay resistance

✓ preserve semantic hashing

182. Recommended Features

A mature implementation SHOULD:

support ZeroK

support TLSNotary

support TEEs

support human experts

support federation

support artifact markets

support evaluation markets

support multiple assets

support private reputation

support mobile artifacts

183. Security Model

Threats include:

forged evidence

replayed settlement

fake evaluation

malicious artifact

poisoned K-line

credential theft

authority confusion

graph poisoning

supply chain attack

Mitigations derive from:

immutable Acts;
evidence graphs;
nullifiers;
local trust;
supersession;
evaluation diversity.

184. Privacy Model

Privacy SHALL be layered.

Possible visibility:

public commitment

private witness

private prompt

private artifact

private expert

private evaluation

private settlement

The protocol never assumes one visibility level.

185. Federation

Actum provides:

global history.

Kline provides:

local cognition.

Every Mind chooses:

what becomes active.

This remains a permanent architectural invariant.

186. Relationship Between All Volumes

Volume I

defines philosophy.

Volume II

defines cognition.

Volume III

defines economics.

Volume IV

defines immutable history.

Together they define the protocol by which intelligence itself becomes reusable, verifiable, attributable, economically meaningful, and continuously evolving.

187. The Fundamental Loop

The complete architecture reduces to one recursive cycle:

UNKNOWN

↓

DISCOVER

↓

EXECUTE

↓

VERIFY

↓

EVALUATE

↓

PROMOTE

↓

COMPILE

↓

PUBLISH

↓

REUSE

↓

OBSERVE

↓

SUPERSEDE

↓

UNKNOWN

The loop never terminates.

It continually transforms frontier reasoning into durable cognitive capital while preserving complete historical provenance and local autonomy.

188. Final Architectural Thesis

Traditional computing accumulated software.

The Distributed Cognitive Network accumulates verified cognition.

Traditional ledgers accumulated financial transactions.

Actum accumulates verifiable cognitive evolution.

Traditional AI repeatedly spends intelligence.

This architecture invests intelligence, compiles it into reusable artifacts, and allows that cognitive capital to compound over time.

The result is not merely a collection of smarter models.

It is a civilization-scale system in which problem-solving capability itself becomes an enduring, attributable, verifiable, and economically productive asset.

Volume V — DCN Runtime

Volume V specifies the local cognitive operating environment: the Cognitive Kernel, scheduler, System 1/System 2 dispatcher, Agencies, world model, patch-oriented execution, concurrency, recovery, and runtime security.

Its central separation is:

Cognitive Kernel = allocates and supervises cognition
Agencies          = bounded cognitive processes
World Model       = authoritative local state
PatchProposal     = proposed semantic change
Authority         = permission to cause an effect

The runtime is intentionally provider-independent and remains useful when disconnected from the wider network.

Distributed Cognitive Network

Volume V

DCN Runtime Specification 0.1

Part 1

Cognitive Kernel, Runtime Architecture, and the Cognitive Execution Cycle

1. Purpose

This specification defines the runtime responsible for executing cognition inside a Mind.

Previous volumes define the architecture, K-Line Protocol, Actum Compute, and Actum cognition history. This volume specifies the local runtime that transforms goals, observations, memory, K-lines, experts, artifacts, policies, authority, and world state into coherent action.

2. Design Philosophy

Traditional operating systems schedule processes, threads, memory, files, and devices. The DCN Runtime schedules cognition.

The runtime manages attention, reasoning, experts, artifacts, memory, authority, learning, and execution. It is therefore a cognitive operating system rather than an agent framework.

3. The Cognitive Kernel

The Cognitive Kernel is the trusted control core of every Mind. It is intentionally small.

Its responsibilities are to maintain cognitive state, allocate attention, schedule cognition, activate K-lines, escalate to System 2, resolve capabilities, enforce authority boundaries, preserve world consistency, and coordinate learning.

The Cognitive Kernel SHOULD NOT attempt to solve arbitrary problems itself.

4. Runtime Architecture

The canonical runtime is:

                    DCN Runtime

                    Cognitive Kernel
                           │
      ┌────────────────────┼────────────────────┐
      │                    │                    │
      ▼                    ▼                    ▼
 System 1            System 2           World State
      │                    │                    │
      ▼                    ▼                    ▼
 K-lines             Expert Network      SurrealDB
      │                    │                    │
      └──────────────┬─────┴────────────────────┘
                     ▼
             Patch Proposal Engine
                     ▼
              Authority Validation
                     ▼
                State Commit

The runtime never mutates state directly through reasoning components.

5. Runtime Principles

The runtime SHALL preserve the following principles.

5.1 Local-first cognition

Whenever practical, cognition executes locally; memory, authority, and personal context remain local. Remote execution is an optimization, not a requirement.

5.2 Proposal-first execution

Reasoning never directly mutates the world:

think → propose → validate → authorize → commit

5.3 Attention is scarce

Computation, battery, money, latency, network capacity, and human attention are scarce resources requiring allocation.

5.4 Learning never stops

Every execution may become future cognition. Learning is continuous rather than a separate training phase.

6. Runtime State

The Cognitive Kernel maintains active goals and tasks, current context, working memory, attention and resource budgets, authority context, active K-lines, running experts, pending patches and evaluations, and background learning jobs.

This runtime state is distinct from persistent long-term memory.

7. The Cognitive Execution Cycle

Every request passes through the same high-level recursive cycle:

Observe
   ↓
Interpret
   ↓
Recognize
   ↓
Plan
   ↓
Execute
   ↓
Validate
   ↓
Learn

Subtasks execute their own cycles.

8. Observe

Observation gathers user input, sensors, world events, external messages, background changes, and completed jobs. Observation records; it does not establish interpretation or truth.

9. Interpret

Interpretation converts observations into semantic structures such as intent, entities, goals, constraints, risks, urgency, and context. Interpretation MAY use lightweight local models.

10. Recognize

Recognition asks whether the Mind has successfully solved a sufficiently similar problem before. It queries K-line triggers, semantic fingerprints, active plans, episodic memory, and current world state and produces candidate K-lines.

11. Plan

Planning decides whether System 1 is sufficient, System 2 is required, additional information is needed, authority is missing, or external capabilities are required. Planning does not itself commit side effects.

12. Execute

Execution activates artifacts, local experts, remote experts, MCP capabilities, A2A agents, or humans. Execution produces results and proposals rather than direct world mutation.

13. Validate

Validation checks policy, authority, consistency, expected outputs, evaluation requirements, and safety constraints. Validation determines whether proposals are eligible for commitment.

14. Learn

Learning records episodes, evaluations, failures, successes, novelty, and opportunities for compilation. Learning SHOULD be asynchronous whenever possible.

15. Cognitive Resources

The runtime schedules attention, latency, money, battery, memory, network capacity, human interruption, and expert availability. These resources are jointly optimized.

16. Attention

Attention is the Cognitive Kernel's primary scheduling primitive. It determines what is processed now, deferred, forgotten, or escalated. This concept is distinct from transformer attention.

17. Goals

Every execution occurs in service of one or more goals. Goals form a graph rather than a stack and may contain subgoals, dependencies, priorities, and constraints.

18. Working Memory

Working memory contains currently relevant facts, active K-lines and experts, intermediate outputs, and pending decisions. It is intentionally small and transient.

19. Long-Term Memory

Long-term memory includes the world model, episodic memory, K-lines, artifacts, trust views, evaluations, plans, preferences, and relationships. It is persistent.

20. Cognitive Stack

The runtime stack is:

Observation
    ↓
Interpretation
    ↓
Recognition
    ↓
Planning
    ↓
Execution
    ↓
Validation
    ↓
Learning

Every subsystem participates in one or more stages of this pipeline.

21. World State

The world model is authoritative for the Mind's current state. Cognitive components reason about the world; they do not independently own it. Cognition is grounded in current world state plus committed history.

22. Patch-Oriented Execution

Execution that proposes a state change produces a PatchProposal rather than directly mutating the world. A patch contains intended changes, justification, dependencies, required authority, and originating execution.

23. Runtime Events

The runtime is event-driven. Canonical events include ObservationReceived, GoalCreated, GoalCompleted, ContextChanged, KLineActivated, ExpertBound, ExecutionCompleted, EvaluationCompleted, PatchCommitted, ArtifactCompiled, and BackgroundLearningTriggered.

Runtime events are immutable records of runtime occurrence; durable network claims are represented separately through Actum Acts where required.

24. Runtime Loop

Conceptually:

event
   ↓
scheduler
   ↓
Cognitive Kernel
   ↓
appropriate subsystem
   ↓
new events

The runtime continuously reacts to relevant events.

25. Background Work

Compilation, evaluation, indexing, K-line discovery, artifact optimization, reputation updates, and synchronization SHOULD execute opportunistically when they do not need to block foreground cognition.

26. Local Autonomy

Every Mind remains autonomous. Decisions, trust, activation, and authority remain local even when the Mind participates in the wider DCN. The runtime MUST NOT assume continuous network connectivity.

27. Runtime Invariants

The DCN Runtime SHALL preserve these invariants:

The Cognitive Kernel allocates cognition; it is not required to perform all cognition.
World state is authoritative; reasoning proposes changes rather than mutating state directly.
Working memory and long-term memory are distinct.
Attention is a managed runtime resource.
Learning is continuous.
Every execution can become input to future cognition.
Local autonomy is preserved within the federated network.

28. Strategic Thesis

Traditional operating systems manage computation. The DCN Runtime manages cognition.

The Cognitive Kernel schedules and protects cognitive execution while K-lines, experts, artifacts, Actum Compute, Actum, evidence systems, MCP, A2A, and other transports or execution technologies cooperate around it.

The Cognitive Kernel is intentionally minimal. Its purpose is not to be the smartest component; its purpose is to keep the Mind coherent, trustworthy, efficient, resource-aware, and continuously capable of learning.

Distributed Cognitive Network

Volume V

DCN Runtime Specification 0.1

Part 2

Cognitive Scheduler, System 1 / System 2 Dispatcher, Novelty Detection, Surprise Estimation, and Capability Resolution

29. Purpose

The Cognitive Kernel must continually decide:

what deserves attention;
what can be handled cheaply;
what requires deliberate reasoning;
what should wait;
what should be forgotten;
what should become future cognition.

This document defines those scheduling mechanisms.

30. Scheduling Philosophy

Traditional operating systems schedule:

CPU time
memory
I/O
interrupts

DCN Runtime schedules:

attention

reasoning

experts

artifacts

learning

network cognition

human interruption

Attention is therefore the primary scheduling primitive.

31. The Cognitive Scheduler

The scheduler continuously chooses:

Which cognitive process should receive the next unit of attention?

Candidate processes include:

System 1 execution

System 2 deliberation

Background learning

Compilation

Evaluation

Remote expert call

Memory indexing

Human interaction

Observation processing

The scheduler is always active.

32. Scheduling Inputs

Scheduling decisions depend on:

goal priority

urgency

novelty

confidence

attention budget

battery

latency

cost

network

authority

expected value

user interruption cost

These inputs continuously evolve.

33. Scheduling Outputs

The scheduler produces:

activate

defer

pause

resume

cancel

escalate

parallelize

serialize

No reasoning occurs before scheduling.

34. Cognitive Priority

Every runnable cognitive process possesses a dynamic priority.

Conceptually:

[ Priority = f( Goal, Urgency, Novelty, ExpectedValue, Risk, Deadline, AttentionCost ) ]

Priority is local.

There is no universal ordering.

35. Attention Budget

Attention is explicitly budgeted.

Example:

attention_budget

=

250 units

Each process consumes estimated attention.

Attention is replenished over time.

High-attention activities SHOULD justify themselves through expected value.

36. Cognitive Cost

Every candidate execution estimates:

money

latency

battery

network

memory

human interruption

future learning value

The scheduler reasons over all of them.

37. System 1 Dispatcher

The System 1 dispatcher attempts:

reuse before discovery.

Its purpose is to maximize compiled cognition.

38. System 1 Preconditions

System 1 execution requires:

matching trigger

trusted K-line

valid artifact

authority available

acceptable confidence

acceptable novelty

Failure of any condition escalates.

39. System 1 Pipeline

Observe

↓

Recognize

↓

Retrieve K-line

↓

Resolve capabilities

↓

Execute

↓

Validate

No exploration occurs.

40. System 2 Dispatcher

System 2 activates when:

novel

ambiguous

insufficient confidence

unexpected failure

conflicting experts

new goals

replanning

explicit user request

System 2 performs search.

41. System 2 Pipeline

Problem

↓

Goal analysis

↓

Expert discovery

↓

Capability planning

↓

Alternative generation

↓

Evaluation

↓

Selection

↓

Execution

↓

Learning

System 2 is expected to generate future System 1 cognition.

42. Dispatcher State Machine

Observe

↓

Recognition

↓

Known?

 /      \

Yes      No

 |        |

S1       S2

 |        |

Success?  Success?

 |        |

Learn    Learn

 |        |

Done     Candidate K-line

Every successful execution contributes learning.

43. Recognition Engine

Recognition answers:

Have I solved this before?

Inputs:

semantic fingerprint

goal

context

entities

constraints

world state

Outputs:

candidate K-lines

confidence

distance

coverage

44. Candidate Ranking

Candidate K-lines are ranked using:

semantic similarity

historical success

evaluation quality

environment

trust

cost

latency

energy

The highest similarity does not automatically win.

45. Novelty Detector

Novelty estimates:

How unfamiliar is this problem?

Novelty is distinct from difficulty.

A difficult problem may have low novelty.

A trivial problem may be novel.

46. Novelty Inputs

Suggested inputs:

semantic distance

graph distance

missing capabilities

new entities

unexpected state

new goals

environment drift

Novelty is continuous.

47. Novelty Output

Conceptually:

0

known

↓

1

completely unfamiliar

Thresholds remain local policy.

48. Surprise Estimator

Surprise differs from novelty.

Novelty:

before execution.

Surprise:

after execution.

49. Surprise Examples

Expected:

confidence

↓

high

↓

success

Surprise:

low.

Unexpected:

confidence

↓

99%

↓

failure

Surprise:

very high.

50. Surprise Uses

Surprise influences:

revalidation

learning

attention

promotion

trust

artifact decay

Large surprise should never be ignored.

51. Escalation

Escalation occurs when:

novelty

or

surprise

or

authority

or

validation

requires deeper reasoning.

Escalation is explicit.

52. Capability Resolver

Capability resolution occurs after planning.

The resolver asks:

How should this capability be satisfied?

53. Resolution Order

Recommended order:

local artifact

↓

local expert

↓

organization

↓

Actum Compute

↓

human

This minimizes unnecessary remote execution.

54. Locality Preference

Everything else equal:

local

>

private organization

>

trusted remote

>

public market

Local execution reduces:

latency;
cost;
privacy exposure.

55. Capability Cache

Resolved capabilities MAY be cached.

Cache entries SHOULD contain:

capability

binding

quality

expiry

environment

cost

Cache invalidation follows K-line decay.

56. Parallel Cognition

Independent capabilities MAY execute concurrently.

Example:

Reasoning

Evidence retrieval

Planning

can execute together.

Dependencies remain explicit.

57. Serial Cognition

Dependent reasoning remains ordered.

Example:

Diagnosis

↓

Treatment planning

↓

Communication

Serialization preserves causality.

58. Background Scheduling

Low-priority cognition includes:

evaluation

compilation

indexing

embedding

sync

artifact download

benchmarking

These SHOULD not interrupt foreground reasoning unnecessarily.

59. Goal Scheduler

Goals possess:

priority

deadline

dependencies

value

attention budget

The scheduler allocates cognition to goals, not merely requests.

60. Deadline Awareness

Deadlines increase urgency.

They do not automatically override:

authority,

privacy,

trust constraints.

61. Human Interruption Cost

The runtime estimates:

Should I interrupt the user?

Human attention is treated as an expensive resource.

62. Energy Awareness

Battery becomes a scheduling signal.

Example:

100%

↓

remote reasoning acceptable

15%

↓

prefer local artifacts

5%

↓

critical cognition only

This is essential for mobile Minds.

63. Money Awareness

Expensive experts require justification.

Repeated expensive execution SHOULD trigger compilation.

64. Learning Value

Every execution estimates:

How much future cognition might this create?

High learning value justifies greater System 2 investment.

65. Frontier Budget

A Mind SHOULD explicitly reserve resources for exploration.

Otherwise:

all attention becomes exploitation.

System 2 eventually disappears.

66. Exploration vs Exploitation

Scheduler balances:

known cognition

vs

new cognition

Both are required.

67. Opportunity Queue

Potential future work enters:

Opportunity Queue

Examples:

compile artifact

re-evaluate K-line

download artifact

benchmark expert

Executed when resources permit.

68. Cognitive Starvation

Long-running background work SHOULD eventually receive attention.

Fairness matters.

69. Scheduler Invariants

The scheduler SHALL preserve:

Locality before remote execution.
Reuse before rediscovery.
Proposal before mutation.
Validation before commitment.
Learning after execution.
Exploration remains possible.
Human interruption minimized.
Authority never bypassed.

70. Strategic Observation

Traditional schedulers maximize CPU utilization.

The DCN Runtime scheduler maximizes growth of reusable cognition.

The most valuable execution is not necessarily the fastest one.

It is often the execution that permanently expands the region of problems that System 1 can solve in the future.

That is the scheduler's deepest optimization objective.

Distributed Cognitive Network

Volume V

DCN Runtime Specification 0.1

Part 3A

Agency Runtime and Patch Proposal Protocol

71. Purpose

This specification defines the runtime model for Agencies, the Patch Proposal Protocol, execution contracts, lifecycle management, and the interaction between Agencies and the Cognitive Kernel.

Agencies are the runtime execution units of DCN Runtime. They are not independent cognitive systems. They are specialized processes that operate on behalf of a Mind.

72. Design Philosophy

Traditional multi-agent systems often give each agent its own memory, state, and decision loop. DCN Runtime instead places authoritative state and scheduling under the Mind and Cognitive Kernel. Agencies perform bounded work.

73. Agency Definition

An Agency is:

A persistent, specialized execution process that performs bounded cognition or actions while operating over the shared world state owned by the Mind.

Examples include Planning, Research, Communication, Scheduling, Compiler, Evaluation, Medical, and Travel Agencies.

74. Agency Responsibilities

An Agency MAY observe world state, retrieve K-lines, invoke experts, execute artifacts, produce plans, generate patches, evaluate alternatives, and request capabilities.

An Agency SHALL NOT directly mutate world state, bypass authority, permanently own truth, or independently redefine goals.

75. Agency Contract

Every Agency SHALL declare a contract containing purpose, capabilities, required inputs, expected outputs, authority requirements, side-effect policy, resource limits, lifecycle policy, and failure semantics.

The contract is static; execution is dynamic.

76. Agency Context

At execution time the Cognitive Kernel provides the relevant goal, world-state slice, working memory, authority context, budgets, time constraints, capability bindings, and execution policy.

Agencies MUST NOT infer authority from context merely because information is visible.

77. Shared World Model

All Agencies reason over the same logical world. They never maintain competing authoritative copies. Local caches are permitted; authoritative state belongs to the Mind.

78. Immutable Inputs

Execution begins from a consistent snapshot. The Agency reasons against that snapshot and produces proposals. The Cognitive Kernel later determines whether the assumptions remain valid against current state.

79. Agency Output

The primary state-changing output is a PatchProposal, not direct mutation. Pure or observational Agencies MAY also return ordinary execution results without proposing state change.

80. Patch Philosophy

A Patch is a proposed semantic modification to the world model. It is not a database transaction, SQL update, arbitrary object mutation, or imperative code.

81. Patch Categories

Semantic operations may include Create, Update, logical Delete, Link, Unlink, Schedule, Authorize, Recommend, Reject, and Escalate. Rich domain operations SHOULD be preferred over generic CRUD when semantics are known.

82. Patch Schema

Conceptually:

{
  "schema": "dcn.patch-proposal.v1",
  "id": "patch:...",
  "origin": { "agency": "planning" },
  "base_state": "sha256:...",
  "operations": [],
  "justification": {},
  "required_authority": {},
  "dependencies": [],
  "expected_effects": [],
  "confidence": 0.94,
  "created_at": "..."
}

The canonical machine-readable wire schema is defined by the Cognitive ABI schema registry; this example is informative.

83. Operations

Operations SHOULD be semantic. Examples include CreateTask, CompleteTask, ScheduleMeeting, RecommendMedication, AttachEvidence, LinkEpisode, and PublishArtifact.

84. Patch Justification

Every Patch SHALL explain why it exists. Justification MAY reference ExecutionActs, EvaluationActs, K-lines, evidence, goals, and observations.

85. Patch Confidence

Confidence estimates expected correctness. Confidence does not grant authority. A patch with confidence 0.98 still requires authorization where policy demands it.

86. Patch Dependencies

A Patch MAY depend upon other patches, authority, remote execution, human approval, evaluation, or time. The Cognitive Kernel resolves dependencies before commitment.

87. Patch Validation

Validation is independent of generation and checks schema, authority requirements, consistency, conflicts, policies, constraints, and required evidence. Validation SHALL NOT silently rewrite a Patch.

88. Patch Authorization

Authorization answers whether the proposal may change the world. It may involve user approval, delegated authority, organization policy, Actum-recorded authority, or cryptographic credentials. Generation and authorization remain separate.

89. Patch Commitment

Committed patches become part of the world model. Rejected patches may remain historical but inactive.

90. Patch Lifecycle

created → validated → authorized → committed → observed

Alternative terminal states include rejected, expired, conflicted, and cancelled.

91. Patch Conflicts

Conflicts occur when two patches rely on incompatible assumptions or propose incompatible state. Both patches may be individually valid. Conflict resolution occurs before commitment.

92. Conflict Resolution

Resolution MAY use priority, merge, new planning, System 2, human review, or policy. No universal strategy is mandated.

93. Agency Lifecycle

registered → idle → scheduled → running → waiting → running → completed → idle

Terminal or administrative states include failed, retired, and disabled.

94. Scheduling

Agencies do not self-schedule. The Cognitive Scheduler activates them, preserving coherent resource allocation.

95. Agency State

Persistent Agency state SHOULD remain minimal: configuration, statistics, cached bindings, and temporary checkpoints. Durable knowledge belongs in the shared Mind.

96. Memory Access

Agencies access memory through runtime interfaces rather than directly manipulating storage engines. This preserves auditing, policy enforcement, caching, and synchronization semantics.

97. Capability Requests

Agencies request cognition through CapabilityRequirement. They do not directly choose providers. The Cognitive Kernel performs local resolution and MAY consult Actum Compute.

98. Nested Agencies

Agencies MAY request additional Agencies. The Cognitive Kernel tracks parent-child causality and enforces recursion and resource policy.

99. Failure Semantics

Failure SHALL produce an explicit error and SHOULD preserve policy-permitted partial outputs, diagnostics, and learning signals.

100. Retry Policy

Retries depend on failure type. Network failure may retry; authority denial normally does not; validation failure may require System 2; provider unavailability may trigger alternative resolution.

101. Checkpoints

Long-running Agencies SHOULD periodically checkpoint working memory, active bindings, pending patches, and progress to enable recovery.

102. Cancellation

Cancellation SHALL be explicit. Cancelled Agencies MUST release attention, compute, reservations, and bindings. Partial patches remain uncommitted.

103. Observability

Agencies emit runtime events such as AgencyStarted, AgencyPaused, PatchCreated, CapabilityRequested, ExecutionCompleted, and AgencyFailed.

104. Security Boundary

Agencies SHALL operate with least privilege. Capabilities and authority are granted explicitly. No Agency possesses universal authority.

105. Determinism

Deterministic Agencies SHOULD produce equivalent Patch Proposals given identical inputs, world snapshot, and configuration. Non-deterministic Agencies SHOULD declare that property according to the Cognitive ABI determinism model.

106. Composability

Agencies compose through events, capability requests, results, and patches—not through ungoverned shared mutable state.

107. Strategic Observation

DCN Runtime Agencies are not miniature people. They are specialized cognitive processes coordinated by the Cognitive Kernel, sharing one coherent world model, proposing semantic patches instead of mutating state, and contributing execution history from which future cognitive capital may be learned.

Distributed Cognitive Network

Volume V

DCN Runtime Specification 0.1

Part 3B

SurrealDB World Model, Memory Architecture, Context Management, and Cognitive State

108. Purpose

This specification defines the persistent cognitive substrate of a Mind.

The world model is not merely storage.

It is the continuously evolving representation of:

reality;
goals;
cognition;
relationships;
authority;
memory;
K-lines;
active work.

All cognition executes against this shared substrate.

109. Design Philosophy

Traditional assistants store:

chat history

embeddings

documents

RAG

DCN Runtime stores:

an evolving semantic world model.

The world model is authoritative.

Conversations are merely one source of observations.

110. World Model

The world model answers:

What does the Mind currently believe about reality?

It includes uncertainty.

It includes contradictions.

It includes provenance.

It is never assumed complete.

111. World State

The world state consists of:

entities

relationships

events

goals

tasks

beliefs

observations

constraints

authority

active cognition

The runtime reasons over world state rather than documents.

112. SurrealDB as Cognitive Substrate

SurrealDB provides:

graph relationships;
documents;
events;
queries;
transactions;
versioning.

DCN Runtime adds cognitive semantics.

SurrealDB is therefore the storage engine, not the cognitive model.

113. Memory Layers

The architecture distinguishes several memory systems.

Working Memory

↓

Context Memory

↓

Episodic Memory

↓

Semantic Memory

↓

Procedural Memory

↓

World Model

These are distinct.

114. Working Memory

Working memory contains:

active task

active experts

temporary variables

intermediate reasoning

pending patches

current observations

Working memory is intentionally small.

It is discarded when no longer needed.

115. Context Memory

Context memory answers:

What matters right now?

Examples:

current meeting

current location

current project

current patient

current conversation

current deadlines

Context changes rapidly.

116. Episodic Memory

Episodes record:

what happened.

Examples:

meeting

conversation

diagnosis

trip

execution

evaluation

Episodes are immutable historical records.

117. Semantic Memory

Semantic memory stores:

facts

concepts

relationships

definitions

preferences

long-term knowledge

Semantic memory evolves more slowly.

118. Procedural Memory

Procedural memory contains:

K-lines

artifacts

skills

compiled cognition

This is where cognition lives.

119. World Model

The world model integrates:

semantic memory

episodic memory

procedural memory

active goals

active plans

relationships

into one coherent graph.

120. Core Object Classes

Recommended object types:

Person

Organization

Device

Agent

Expert

Artifact

K-line

Goal

Task

Project

Conversation

Observation

Evidence

Evaluation

Policy

Authority

Relationship

Applications extend these.

121. Relationship First

Objects matter less than relationships.

Examples:

OWNS

WORKS_ON

TRUSTS

CREATED

PROMOTED

EVALUATED

SUPERSEDES

BELONGS_TO

USES

Graph traversal becomes natural cognition.

122. Beliefs

The world model stores beliefs.

Not truths.

Example:

Object

↓

Belief

↓

Confidence

↓

Evidence

Beliefs evolve.

123. Contradictions

Contradictory beliefs are permitted.

Example:

Source A

↓

Blood pressure

140

Source B

↓

Blood pressure

128

The runtime resolves contradictions.

The database preserves them.

124. Provenance

Every belief SHOULD reference:

source

timestamp

evidence

confidence

Knowledge without provenance is discouraged.

125. Confidence

Confidence belongs to beliefs.

Example:

Patient smokes

confidence

0.94

Confidence changes over time.

126. Trust

Trust belongs to sources.

Not beliefs.

Examples:

hospital

research paper

human

expert

organization

sensor

Trust is local.

127. Goals

Goals are persistent objects.

Schema:

Goal

priority

deadline

constraints

dependencies

progress

owner

Goals participate in the world graph.

128. Tasks

Tasks differ from goals.

Goal:

desired future.

Task:

specific work.

Tasks may satisfy goals.

129. Projects

Projects group:

goals;
tasks;
conversations;
artifacts;
experts.

Projects provide long-term organization.

130. Plans

Plans are executable strategies.

A plan references:

goals

tasks

K-lines

experts

constraints

Plans evolve.

131. Active Plans

Only a small number remain active.

Inactive plans stay historical.

132. Observations

Everything begins as:

Observation

Examples:

email

voice

camera

sensor

calendar

location

health

Interpretation follows later.

133. Observation Pipeline

Observe

↓

Interpret

↓

Belief

↓

Episode

↓

Learning

Observation is never skipped.

134. Context Windows

Unlike LLM context,

DCN Runtime context is semantic.

Context is assembled from:

goals

world state

active plans

working memory

relevant episodes

K-lines

authority

Not merely token history.

135. Context Assembly

Context assembly becomes a runtime algorithm.

Inputs:

problem

goal

entities

relationships

time

location

authority

Output:

Working Context

136. Context Size

The runtime should minimize unnecessary context.

Smaller context means:

faster reasoning;
lower cost;
higher locality.

137. Context Lifetime

Different context expires differently.

Example:

meeting

↓

hours

project

↓

months

identity

↓

years

138. Attention Anchors

Working memory maintains:

current focus

secondary focus

background focus

Attention shifts dynamically.

139. Long-Term Forgetting

The system SHOULD forget selectively.

Not everything deserves permanent storage.

Possible policies:

discard

archive

compress

summarize

compile

140. Compression

Repeated episodes MAY become:

summary

statistics

K-line

artifact

Memory itself evolves.

141. Semantic Compression

Instead of storing:

1000 conversations

store:

relationship

preference

goal

trust

The runtime preserves meaning.

142. Cognitive Compression

Repeated reasoning MAY become:

K-line

↓

artifact

This mirrors memory evolution.

143. Time

Every object possesses:

created

observed

updated

expires

revalidated

Time is fundamental.

144. Space

Location is first-class.

Examples:

device

building

city

country

virtual workspace

Context often depends upon location.

145. Identity

Identity links:

person

devices

accounts

credentials

authorities

Identity remains external to cognition.

146. Authority Objects

Authority is represented explicitly.

Examples:

delegation

policy

approval

consent

Authority is queried.

Never assumed.

147. World Events

Events mutate belief.

Not directly.

Pipeline:

event

↓

observation

↓

interpretation

↓

patch

↓

commit

148. World Consistency

Consistency is maintained by:

patch validation;
authority;
conflict resolution.

Not by Agencies.

149. History

History remains immutable.

Current world state is reconstructed through accepted patches.

150. Snapshots

The runtime MAY periodically checkpoint:

world state

working memory

goals

plans

Snapshots accelerate recovery.

151. Search

Search is semantic.

Typical queries:

What do I know?

Who knows?

What happened?

Have I solved this?

Who evaluated this?

Which artifact replaced this?

Graph traversal dominates keyword search.

152. Memory Promotion

Interesting memories MAY become:

belief

↓

episode

↓

K-line

↓

artifact

Memory itself participates in learning.

153. Local First

Everything personal remains local whenever possible.

Federation is selective.

Not default.

154. Synchronization

Synchronization SHOULD exchange:

Acts

patches

artifacts

K-lines

evaluations

rather than entire databases.

155. Runtime Invariants

The world model SHALL preserve:

Shared authoritative state.
Explicit provenance.
Explicit confidence.
Explicit trust.
Graph relationships.
Immutable history.
Proposal-based mutation.
Local autonomy.

156. Strategic Observation

Traditional AI systems remember conversations.

DCN Runtime remembers the world.

Conversations become merely one stream of observations feeding a persistent cognitive substrate.

That distinction transforms memory from passive storage into an active semantic environment in which cognition can accumulate, evolve, and continuously improve over the lifetime of the Mind.

This is, in my view, one of the biggest architectural departures from current AI assistants. Instead of centering everything on the LLM's context window, DCN Runtime centers everything on a persistent semantic world model. The LLM—or any other expert—becomes just one transient reasoning component operating over that world, while SurrealDB and the Cognitive Kernel maintain continuity across years of interaction. That shift is what makes long-lived, continually learning Minds possible.

Distributed Cognitive Network

Volume V

DCN Runtime Specification 0.1

Part 3C

Concurrency, Transactions, Checkpointing, Fault Tolerance, Synchronization, and Runtime Security

157. Purpose

This section defines the runtime semantics that allow a Mind to remain consistent while multiple cognitive processes execute simultaneously.

Unlike traditional AI systems, a Mind is expected to:

think continuously,
execute multiple Agencies,
synchronize with other Minds,
survive interruptions,
learn while running,
preserve cognitive consistency.

158. Runtime Philosophy

The runtime SHALL behave like an operating system.

It is responsible for:

concurrency;
isolation;
scheduling;
recovery;
consistency.

Reasoning alone is insufficient.

159. Cognitive Processes

Every running activity is represented as a Cognitive Process.

Examples:

Conversation

Planning

Research

Compilation

Evaluation

Synchronization

Background learning

Artifact optimization

Processes are schedulable runtime objects.

160. Process Model

Every Cognitive Process has:

ProcessID

Goal

Priority

Agency

Working memory

Current checkpoint

Pending patches

Lifecycle

Resource budget

Processes are independent but cooperate through the shared world model.

161. Process Lifecycle

Created
   ↓
Scheduled
   ↓
Running
   ↓
Waiting
   ↓
Resumed
   ↓
Completed

Terminal states:

Cancelled

Failed

Expired

Merged

162. Process Isolation

Each process owns:

its working memory,
temporary variables,
intermediate reasoning,
local expert bindings.

Processes SHALL NOT directly modify another process's internal state.

Communication occurs through:

events;
patch proposals;
world-state observations.

163. Shared World State

All processes observe the same logical world.

However they execute against snapshots.

Snapshot S
     │
     ▼
Process A

Snapshot S
     │
     ▼
Process B

Both may produce valid patches.

The Kernel resolves consistency.

164. Snapshot Semantics

A snapshot contains:

world-state commitment

goal graph

authority context

active K-lines

active artifacts

configuration

Snapshots are immutable.

165. Optimistic Concurrency

DCN Runtime uses optimistic execution.

Processes assume:

"The world probably won't change in conflicting ways."

Before commitment:

Patch
     ↓
Validate
     ↓
Still valid?
     /      \
   Yes       No
    │         │
 Commit    Replan

166. Patch Transactions

Patch commitment is transactional.

Either:

all operations commit

none commit

Partial semantic updates are prohibited.

167. Patch Batches

Multiple related patches MAY be grouped into one transaction.

Example:

Create Goal

Create Task

Assign Expert

Schedule Review

All succeed together.

168. Transaction Context

Every transaction SHALL include:

Base snapshot

Patch list

Dependencies

Authority

Expected effects

169. Conflict Detection

Conflicts occur when:

assumptions changed;
dependencies disappeared;
authority changed;
goals changed;
another patch committed first.

Conflict is semantic.

Not merely structural.

170. Conflict Resolution

Recommended strategies:

automatic merge

priority

new planning

human

System 2

policy

Conflict resolution is itself cognition.

171. Event Bus

The runtime contains a canonical event bus.

All significant events pass through it.

Examples:

ObservationReceived

PatchCommitted

AuthorityGranted

GoalCompleted

ExpertFailed

ArtifactUpdated

NetworkDisconnected

172. Event Ordering

Events possess:

logical order

wall-clock time

causal parents

Ordering supports deterministic replay.

173. Deterministic Replay

The runtime SHOULD be replayable.

Inputs:

observations

events

patches

authority

random seeds

Replay reconstructs cognitive history.

174. Checkpoints

Long-running processes SHOULD periodically checkpoint.

Checkpoint contains:

working memory

pending patches

expert bindings

scheduler state

resource usage

Checkpoint frequency is policy-driven.

175. Recovery

After interruption:

Load checkpoint

↓

Validate snapshot

↓

Resume

or

Restart

Recovery should minimize repeated expensive cognition.

176. Background Services

The runtime supports persistent services.

Examples:

Compiler

Indexer

Synchronizer

Evaluator

Artifact Downloader

Trust Updater

They behave like operating-system daemons.

177. Idle-Time Scheduling

Background work SHOULD prefer:

charging,
Wi-Fi,
low CPU load,
user inactivity.

This is particularly important on mobile devices.

178. Synchronization

Synchronization exchanges:

Acts

Patches

Artifacts

K-lines

Evaluations

Never raw working memory.

179. Synchronization Model

Synchronization is eventually consistent.

Local cognition always remains authoritative for the local Mind.

180. Offline Operation

The runtime SHALL support:

offline reasoning

offline artifacts

offline K-lines

offline memory

deferred synchronization

Connectivity is an optimization.

181. Deferred Commit

If external dependencies are unavailable:

execute locally

↓

queue synchronization

↓

publish later

The Mind continues functioning.

182. Remote Failure

Remote failures include:

expert unavailable

market unavailable

TLSNotary unavailable

network unavailable

The scheduler SHOULD seek alternatives rather than immediately failing.

183. Graceful Degradation

Preferred degradation order:

compiled artifact

↓

local model

↓

organization expert

↓

remote market

↓

human

The runtime should preserve functionality whenever possible.

184. Resource Accounting

Every process tracks:

CPU

memory

battery

network

money

attention

Scheduling decisions incorporate these costs.

185. Cognitive Garbage Collection

Temporary cognition SHOULD expire.

Candidates:

temporary plans

expired bindings

old checkpoints

unused embeddings

obsolete caches

Long-term knowledge is preserved separately.

186. Working Memory Eviction

Working memory eviction SHOULD prioritize:

completed tasks

irrelevant context

duplicate information

low-value intermediates

The world model remains unaffected.

187. Runtime Security

The runtime SHALL enforce:

least privilege;
capability-based access;
explicit authority;
process isolation;
signed patches;
immutable history.

No Agency receives unrestricted access.

188. Capability Sandboxing

Agencies receive only the capabilities required by their current contract.

Unused capabilities remain unavailable.

189. Secret Handling

Secrets SHALL remain outside working memory whenever possible.

Instead:

secret reference

↓

secure vault

↓

authorized access

Reasoning should not unnecessarily expose credentials.

190. Secure Locality

Sensitive cognition SHOULD remain local whenever policy allows.

Examples:

health

finance

identity

personal relationships

Remote execution requires explicit policy.

191. Runtime Auditing

Every significant runtime action SHOULD produce:

event

patch

Act

evaluation

log reference

Auditing is integral, not optional.

192. Health Monitoring

Kernel metrics include:

scheduler load

pending patches

background queue

System 2 rate

artifact hit rate

average novelty

learning backlog

checkpoint age

These help diagnose the health of a Mind.

193. Runtime Upgrades

Runtime upgrades SHALL preserve:

world model;
Acts;
K-lines;
artifacts;
authority;
history.

Migration scripts MUST be explicit.

194. Crash Consistency

Following unexpected termination:

committed patches remain committed;
uncommitted patches remain proposals;
world state remains coherent.

Recovery SHALL never fabricate state.

195. Distributed Minds

Multiple Minds MAY cooperate.

Each retains:

local authority;
local trust;
local world model.

Shared cognition flows through:

Acts;
K-lines;
artifacts;
evaluations.

Never through implicit shared memory.

196. Cognitive Federation

The runtime views federation as:

discover

↓

verify

↓

evaluate

↓

trust

↓

activate

Activation is always local.

197. Runtime Invariants

The runtime SHALL preserve:

Snapshot isolation for reasoning.
Transactional patch commitment.
Proposal-before-mutation.
Immutable historical Acts.
Recoverability through checkpoints.
Local autonomy.
Least privilege.
Event-driven execution.
Offline capability.
Continuous learning.

198. Reference Runtime Loop

Observation
      ↓
Interpretation
      ↓
Recognition
      ↓
Scheduling
      ↓
System 1 / System 2
      ↓
Capability Resolution
      ↓
Execution
      ↓
Patch Proposal
      ↓
Validation
      ↓
Authorization
      ↓
Commit
      ↓
Actum Act
      ↓
Learning
      ↓
Compilation Opportunity

This loop continuously evolves the Mind.

199. Strategic Observation

Traditional AI applications execute requests.

DCN Runtime executes persistent cognition.

The runtime therefore behaves much more like an operating system than a chatbot.

Processes cooperate.

State persists.

Learning accumulates.

Authority remains explicit.

History remains immutable.

Every execution contributes not only to solving the current problem, but also to increasing the future cognitive capability of the Mind.

200. Runtime Definition

The DCN Runtime is:

A cognitive operating system that schedules attention, coordinates specialized cognitive processes, maintains a persistent semantic world model, executes proposal-based state transitions, survives interruption, learns continuously, and transforms repeated reasoning into reusable cognitive capital while preserving local autonomy, authority, and verifiable history.

This runtime is the execution environment in which Kline, Actum Compute, Actum, TLSNotary, ZeroK, Agent Plugins, MCP, A2A, and future cognitive technologies cooperate as one coherent Mind.

Volume VI — Cognitive Compiler

Volume VI defines how expensive successful System-2 cognition becomes progressively cheaper System-1 cognition.

The Cognitive Compiler is implemented as a Compiler Society. Specialized compiler agencies discover repeated patterns, generalize topology, simplify graphs, extract rules, distill models, synthesize artifacts, optimize deployment targets, and independently evaluate candidates.

Compilation is constrained optimization: quality, safety, privacy, evidence, authority, and required explainability are not currencies that may simply be traded away for lower cost.

Distributed Cognitive Network

Volume VI

Cognitive Compiler Specification 0.1

Part 1

Compiler Architecture, Philosophy, Objectives, and the Transformation of Intelligence into Cognitive Capital

1. Purpose

This specification defines the Cognitive Compiler.

The Cognitive Compiler, realized as a Compiler Society of specialized compilation agencies, is responsible for transforming expensive System-2 cognition into progressively cheaper, reusable System-1 cognition.

It is one of the defining mechanisms of the Distributed Cognitive Network.

Without it:

every difficult problem remains expensive;
expertise remains transient;
cognition never compounds.

With it:

successful reasoning becomes reusable;
reusable cognition becomes executable;
execution becomes progressively cheaper;
cognitive capital accumulates.

2. Central Thesis

Traditional software compilation transforms:

Source Code

↓

Machine Code

The Cognitive Compiler transforms:

Reasoning

↓

Reusable Cognition

This distinction is fundamental.

3. Compiler Philosophy

Every expensive successful reasoning trajectory is an investment.

The compiler asks:

How can this reasoning be performed more cheaply next time without violating the required quality constraints?

Compilation therefore concerns:

cognition,
not syntax.

4. What Is Being Compiled?

The compiler never compiles prompts.

It compiles:

K-line topology

expert organization

decision structure

validation structure

control flow

execution strategy

The semantic object is cognition itself.

5. Compiler Inputs

The compiler consumes:

KLineTemplate

Episodes

EvaluationClaims

ExecutionActs

World constraints

Deployment targets

Optimization objectives

Compilation is therefore evidence-driven.

6. Compiler Outputs

Outputs include:

Improved K-line topology

Executable artifacts

Evaluation requests

Compilation records

Optimization reports

Compilation does not directly modify Templates.

7. Compiler Objectives

The compiler simultaneously minimizes:

execution cost;
latency;
energy;
network usage;
memory footprint;
cognitive complexity.

Subject to:

Required Quality

Required Safety

Required Authority

Required Privacy

Required Explainability

Quality remains a hard constraint.

8. Compiler Architecture

Episodes
      │
      ▼
Pattern Discovery
      │
      ▼
Topology Compiler
      │
      ▼
Artifact Compiler
      │
      ▼
Evaluation
      │
      ▼
Publication Candidate

Every stage is independently replaceable.

9. Two Independent Compilers

DCN Runtime distinguishes:

Topology Compiler

Artifact Compiler

These solve different problems.

10. Topology Compiler

Question:

Is the cognitive organization itself unnecessarily complicated?

Examples:

7 experts

↓

4 experts

↓

2 experts

No implementation change.

Only topology changes.

11. Artifact Compiler

Question:

Can the same topology execute more efficiently?

Examples:

Frontier model

↓

Fine-tuned model

↓

Classifier

↓

Rules

Semantics remain.

Implementation changes.

12. Compiler Pipeline

Discover

↓

Cluster

↓

Generalize

↓

Optimize

↓

Compile

↓

Evaluate

↓

Publish Candidate

This becomes a continuous background process.

13. Discovery

Discovery identifies candidate reasoning worth preserving.

Candidate criteria include:

repeated success;
high economic cost;
high execution frequency;
strategic importance;
high evaluation confidence.

Not every episode deserves compilation.

14. Clustering

Episodes are clustered by:

semantic similarity

goal

graph topology

execution outcome

evaluation

context

Clusters become candidate cognitive families.

15. Generalization

Generalization attempts to identify:

common topology

common decisions

common capabilities

common validations

Noise should disappear.

Structure should remain.

16. Optimization

Optimization seeks:

fewer experts

cheaper experts

less communication

smaller context

less retrieval

less validation

Every optimization requires later evaluation.

17. Compilation

Compilation transforms:

semantic topology

↓

runtime artifact

Artifacts remain implementation-specific.

18. Evaluation

Compilation never bypasses evaluation.

Every candidate artifact must satisfy:

quality

safety

calibration

robustness

cost

before publication.

19. Publication Candidate

Only after successful evaluation does an artifact become eligible for publication.

Publication remains separate.

20. Why Continuous Compilation?

Compilation is not an offline build step.

It is continuous.

Every successful execution potentially improves future cognition.

21. Compilation Targets

Targets include:

phone

tablet

desktop

server

GPU

embedded

offline

confidential

Artifacts become environment-specific.

22. Mobile First

A central design objective is:

Can this cognition eventually execute on a phone?

Energy therefore becomes a first-class optimization target.

23. Cost Curves

Example:

€12

↓

€4

↓

€0.80

↓

€0.05

↓

≈0

The objective is continual downward movement.

24. Frontier Migration

As cognition becomes cheaper:

Experts become available for:

new problems.

The compiler therefore expands civilization's frontier.

25. Compiler Metrics

Examples:

cost reduction

latency reduction

energy reduction

artifact size

reuse frequency

coverage increase

quality preservation

Metrics determine compiler success.

26. Compilation Is Evidence-Driven

The compiler never trusts one execution.

Compilation requires:

repeated episodes;
evaluation;
evidence;
statistical confidence.

This distinguishes it from prompt caching.

27. Compilation Lineage

Every artifact SHALL preserve:

Template

↓

Episodes

↓

Evaluations

↓

Compilation

↓

Artifact

Lineage is never broken.

28. Compiler Contracts

Compilers are themselves replaceable components.

Every compiler declares:

supported targets

optimization objectives

quality guarantees

runtime requirements

Different organizations may deploy different compilers.

29. Compiler Safety

Compilation MUST NOT silently weaken:

authority;
privacy;
safety;
explainability.

Optimization is always constrained.

30. Strategic Observation

The Cognitive Compiler is not merely an optimization pass.

It is the mechanism by which the Distributed Cognitive Network transforms temporary intelligence into permanent cognitive capital.

Every expensive act of reasoning becomes an opportunity to reduce the future cost of solving the same class of problems.

The compiler therefore serves as the engine of civilization-scale learning: converting scarce expert cognition into abundant reusable artifacts while preserving semantics, evaluation history, lineage, and verifiable provenance.

Distributed Cognitive Network

Volume VI

Cognitive Compiler Specification 0.1

Part 2

Compiler Society, Compilation Algorithms, Pattern Discovery, Distillation, and Artifact Synthesis

31. Purpose

Part 1 defined the philosophy of cognitive compilation.

This section defines how compilation actually happens.

Unlike traditional software compilation, cognitive compilation is itself a cognitive process.

The compiler therefore participates in the same Society of Experts as every other subsystem.

32. Compiler Society

The Cognitive Compiler SHALL be implemented as a coordinated society of specialized compiler agencies rather than one monolithic optimizer.

Example:

Compiler Society

│

├── Pattern Miner

├── Episode Clusterer

├── Topology Generalizer

├── Topology Optimizer

├── Rule Extractor

├── Distillation Expert

├── Model Trainer

├── Artifact Synthesizer

├── Mobile Optimizer

├── Verification Compiler

├── Benchmark Generator

└── Regression Evaluator

Every compiler specializes.

No compiler understands everything.

33. Compiler Coordinator

Compilation itself is coordinated by the Cognitive Kernel.

Compilation is therefore another cognitive workflow.

Not a privileged subsystem.

34. Compiler Inputs

Every compiler receives:

Template

Episode Set

Evaluation Set

Optimization Target

Deployment Target

Constraints

Compilers never invent cognition.

They transform existing cognition.

35. Pattern Miner

The Pattern Miner identifies repeated cognitive structures.

Inputs:

Episodes

Execution Graphs

Evaluation Results

Outputs:

candidate patterns

frequent subgraphs

decision motifs

common capability sequences

This is the first step toward reusable cognition.

36. Episode Clusterer

The Episode Clusterer groups similar executions.

Clustering dimensions include:

semantic similarity

graph topology

goal

entities

constraints

evaluation profile

environment

Clusters represent recurring cognitive situations.

37. Cluster Quality

Not every cluster deserves compilation.

Candidate clusters SHOULD satisfy:

minimum size

minimum success

minimum consistency

acceptable variance

Outliers remain available but SHOULD NOT dominate compilation.

38. Topology Generalizer

The Topology Generalizer attempts to identify the invariant cognitive structure shared across a cluster.

Example:

Episode A

Reasoner

↓

Retriever

↓

Critic


Episode B

Reasoner

↓

Retriever

↓

Critic

Generalizes naturally.

39. Variable Nodes

Generalization may replace concrete experts with capability requirements.

Example:

Claude

↓

General Reasoning

This preserves semantic flexibility.

40. Topology Optimizer

Question:

Which cognitive interactions are unnecessary?

Operations include:

remove node

merge nodes

inline node

cache result

replace with rule

parallelize

serialize

Topology optimization changes cognition.

Not implementation.

41. Rule Extractor

Repeated deterministic reasoning MAY become rules.

Example:

LLM

↓

Decision Tree

↓

Rules

Rule extraction is only acceptable if evaluation confirms preserved quality.

42. Retrieval Optimizer

Retrieval MAY become:

structured knowledge

cached graph

local index

pre-computed artifact

The objective is reducing future retrieval cost.

43. Distillation Expert

Distillation transforms:

multiple experts

↓

specialized model

The distilled model remains an artifact.

It never replaces historical episodes.

44. Distillation Constraints

Distillation SHALL preserve:

evaluation quality;
safety;
calibration;
authority semantics;
explainability requirements.

45. Artifact Synthesizer

The synthesizer packages:

compiled topology

runtime

configuration

dependencies

metadata

into a deployable artifact.

46. Deployment Targets

Artifacts MAY target:

iPhone

Android

Desktop

Server

GPU

Browser

Embedded

Target influences optimization.

47. Mobile Optimizer

Mobile optimization prioritizes:

battery

memory

latency

offline capability

storage

thermal limits

The phone becomes a first-class deployment platform.

48. Verification Compiler

Compilation must generate verification plans.

Examples:

benchmark

unit tests

simulation

counterexamples

stress tests

Artifacts without verification remain candidates.

49. Benchmark Generator

Benchmark generation is itself cognitive work.

Benchmarks SHOULD represent:

expected cases

edge cases

novel cases

adversarial cases

distribution shifts

Compilation without benchmarking is discouraged.

50. Regression Evaluator

Every new artifact SHALL be compared against previous artifacts.

Regression dimensions include:

quality

cost

latency

energy

robustness

calibration

The new artifact must justify deployment.

51. Multi-Version Artifacts

Compilation MAY produce:

Artifact A

Artifact B

Artifact C

for different targets.

No single artifact must dominate every environment.

52. Adaptive Compilation

Compilation SHOULD adapt to deployment.

Example:

Desktop

↓

larger artifact


Phone

↓

smaller artifact


Watch

↓

rule engine

The semantic K-line remains unchanged.

53. Partial Compilation

Some cognitive structures SHOULD remain external.

Example:

medical literature retrieval

may remain remote while:

diagnostic reasoning

becomes local.

Compilation is selective.

54. Incremental Compilation

The compiler SHOULD avoid recompiling everything.

Instead:

detect change

↓

compile affected region

↓

evaluate

↓

merge

Incremental compilation reduces cost.

55. Opportunity Ranking

Compilation opportunities compete.

Priority depends upon:

execution frequency

execution cost

learning value

expected savings

artifact demand

High-impact cognition compiles first.

56. Compilation Queue

The Kernel maintains:

Compilation Queue

Candidate items include:

new K-line

frequently executed workflow

expensive expert graph

artifact needing optimization

Compilation is background work.

57. Compilation Budget

Compilation itself consumes resources.

Budgets include:

money

GPU

battery

network

human review

The compiler competes for attention like every other subsystem.

58. Compiler Feedback

Artifacts generate runtime telemetry.

Telemetry feeds back into:

clustering;
optimization;
re-compilation;
supersession.

The compiler is continuously learning.

59. Recursive Compilation

Compiler agencies themselves MAY improve.

Examples:

better clustering

better rule extraction

better optimization

better benchmarks

The compiler therefore becomes self-improving.

60. Compiler Metrics

Recommended metrics:

cost reduction

latency reduction

energy reduction

coverage increase

reuse rate

artifact adoption

compilation ROI

quality preservation

Metrics evaluate compiler performance.

61. Compilation Return on Investment

A useful measure is:

[ ROI= \frac{\text{Expected Future Savings}} {\text{Compilation Cost}} ]

Compilation SHOULD prioritize high-ROI cognition.

62. Compiler Safety Gates

Compilation SHALL stop when:

evaluation insufficient;
regression detected;
safety degraded;
authority assumptions changed;
explainability requirements violated.

Optimization is never unconditional.

63. Compiler Society Lifecycle

discover

↓

cluster

↓

generalize

↓

optimize

↓

compile

↓

evaluate

↓

publish candidate

↓

monitor

↓

recompile

This cycle never ends.

64. Strategic Observation

The Compiler Society is not merely producing smaller models.

It is continually discovering which parts of expensive reasoning are truly essential, transforming those invariant cognitive structures into reusable artifacts, and allowing the remaining scarce expert attention to migrate toward genuinely novel problems.

In this way, the Cognitive Compiler does not simply optimize execution—it continuously increases the stock of reusable cognitive capital available to every Mind in the Distributed Cognitive Network.

The compiler is therefore the engine through which the network converts experience into infrastructure.

Distributed Cognitive Network

Volume VI

Cognitive Compiler Specification 0.1

Part 3

Continuous Validation, Deployment, Regression Detection, Self-Improvement, and the Evolution of Cognitive Capital

65. Purpose

Compilation does not end when an artifact is produced.

Compilation ends only when the artifact has demonstrated sustained value under real-world conditions.

This section defines the continuous validation lifecycle.

66. Compiler Philosophy

Every artifact is a hypothesis.

The hypothesis is:

"This implementation preserves the semantics of the original cognition while improving one or more optimization objectives."

That hypothesis must be continuously tested.

67. Candidate Status

Freshly compiled artifacts begin as:

Candidate

They are not immediately trusted.

Candidate artifacts require evidence.

68. Validation Pipeline

Compilation

↓

Offline Evaluation

↓

Simulation

↓

Shadow Execution

↓

Limited Deployment

↓

Continuous Observation

↓

Promotion

Every stage increases confidence.

69. Offline Evaluation

Offline evaluation uses:

benchmark suites;
historical episodes;
regression datasets;
adversarial examples;
synthetic scenarios.

Offline success is necessary but insufficient.

70. Shadow Execution

A candidate artifact SHOULD execute alongside the currently active artifact without affecting the world.

Current Artifact
        │
        ▼
World

Candidate Artifact
        │
        ▼
Prediction Only

The runtime compares both outputs.

71. Shadow Metrics

Examples:

agreement

confidence

latency

energy

cost

unexpected divergence

Shadow execution reduces deployment risk.

72. Canary Deployment

Successful shadow artifacts MAY be deployed to a small fraction of executions.

Example:

1%

↓

5%

↓

20%

↓

100%

Progression depends upon observed performance.

73. Continuous Evaluation

Evaluation never ends.

Every production execution contributes:

quality;
latency;
failures;
user feedback;
downstream outcomes.

The artifact is continually re-measured.

74. Regression Detection

Regression is any statistically meaningful deterioration.

Dimensions include:

quality

robustness

calibration

latency

energy

cost

fairness

stability

Regression MUST trigger review.

75. Drift Detection

Artifacts MAY degrade because:

users change;
environments change;
experts change;
regulations change;
hardware changes.

Compiler telemetry SHALL monitor drift.

76. Drift Signals

Possible signals:

lower confidence

higher disagreement

unexpected failures

distribution shift

new entity types

new goals

Drift does not automatically invalidate artifacts.

It requests investigation.

77. Automatic Rollback

If regression exceeds policy:

Artifact B

↓

Rollback

↓

Artifact A

Rollback SHALL preserve historical lineage.

78. Multi-Version Execution

The runtime MAY execute multiple artifact versions simultaneously.

Example:

v1

v2

v3

Each receives different traffic.

Evaluation chooses the future.

79. Champion and Challenger

The recommended deployment model is:

Champion

↓

Current Production

Challenger

↓

Candidate

The challenger must earn promotion.

80. Artifact Retirement

Retirement occurs only after:

supersession;
historical preservation;
lineage completion.

Deletion is discouraged.

81. Continuous Benchmarking

Benchmarks evolve.

Artifacts SHALL periodically execute against updated benchmark suites.

Static benchmarks are insufficient.

82. Benchmark Diversity

Benchmarks SHOULD include:

historical

current

future-like

adversarial

rare

long-tail

The objective is generalization.

83. Evaluation Diversity

Different evaluators SHOULD assess the same artifact.

Independent evaluations reduce systematic bias.

84. Human Feedback

Human feedback becomes another evidence source.

It SHALL be recorded as:

Observation

↓

EvaluationAct

Not as silent parameter updates.

85. Counterexamples

Unexpected failures become first-class objects.

Every counterexample SHOULD preserve:

context

artifact

expected output

actual output

evaluation

evidence

Counterexamples are valuable compiler input.

86. Learning Queue

Counterexamples feed:

Pattern Miner

↓

Clusterer

↓

Compiler

The system continuously learns from failure.

87. Compiler Feedback Loop

Execution

↓

Observation

↓

Evaluation

↓

Regression

↓

Compilation

↓

Artifact

↓

Execution

The loop never terminates.

88. Quality Gates

Artifacts SHALL satisfy configurable gates.

Example:

minimum quality

minimum calibration

maximum latency

maximum energy

minimum robustness

Failing any mandatory gate blocks promotion.

89. Explainability Gates

Where required:

Artifacts SHALL preserve explainability constraints.

Optimization SHALL NOT silently remove required explanations.

90. Authority Preservation

Compilation SHALL preserve authority semantics.

An artifact MUST NOT gain permissions simply because it is cheaper.

91. Privacy Preservation

Compilation SHALL preserve privacy guarantees.

Examples:

local-only

confidential execution

ZeroK

TEE

Optimization MUST NOT weaken privacy.

92. Cognitive Coverage

Compiler success is measured primarily by:

[ Coverage_{S1} ]

Increasing System-1 coverage is the primary objective.

93. Compilation Gain

Define:

[ CompilationGain

Coverage_{S1}^

Coverage_{S1}^{before} ]

This directly measures compiler impact.

94. Economic Gain

Another metric:

[ Savings

Cost_

Cost_{new} ]

Summed over future executions.

95. Energy Gain

Similarly:

[ EnergyGain

Energy_

Energy_{new} ]

This is particularly important for mobile deployment.

96. Lifetime Value

Every artifact accumulates:

executions

savings

energy saved

latency saved

quality preserved

Artifacts become measurable cognitive assets.

97. Compiler ROI

Compiler Return on Investment:

[ ROI

\frac{ LifetimeSavings } { CompilationCost } ]

This prioritizes high-value compilation opportunities.

98. Recursive Improvement

The compiler itself evolves.

Compiler artifacts,

compiler K-lines,

compiler evaluations,

and compiler heuristics

all become eligible for compilation.

The compiler therefore continuously improves its own optimization process.

99. Compiler Society Learning

Each compiler agency accumulates:

episodes

evaluations

artifacts

heuristics

Compiler knowledge itself becomes cognitive capital.

100. Long-Term Vision

Eventually:

fewer frontier executions are required;
more cognition executes locally;
more cognition executes deterministically;
more cognition becomes reusable.

The frontier continuously moves outward.

101. Strategic Observation

The Cognitive Compiler is not merely reducing inference cost.

It is transforming repeated reasoning into infrastructure.

Every successful reasoning trajectory becomes a candidate investment.

Every investment is evaluated.

Every validated investment becomes cognitive capital.

Every artifact increases the permanent capability of the Distributed Cognitive Network.

The compiler therefore functions as the engine through which intelligence compounds over time.

Rather than repeatedly purchasing cognition, the network increasingly owns cognition in the form of evaluated, verifiable, reusable artifacts whose lineage, evidence, and economic value remain permanently traceable.

In this sense, the Cognitive Compiler is the mechanism that converts intelligence from a consumable service into an accumulating asset.

Volume VII — Cognitive ABI

Volume VII defines the stable semantic waist of the DCN. It allows Kline, the DCN Runtime, experts, artifacts, compilers, evaluators, Actum Compute, Actum, MCP, A2A, Agent Plugins, and future transports to interoperate without sharing implementation internals.

The ABI is executable: canonical schemas, Rust/TypeScript/Swift bindings, golden traces, and conformance fixtures live alongside the prose specification.

The central invariant is:

Implementation, provider, transport, and execution environment may change while the semantic cognitive contract remains stable.

Distributed Cognitive Network

Volume VII — Cognitive ABI Specification 0.1

Part 1 — Core Runtime Objects, Invocation Contract, and Interoperability Boundary

1. Scope

The Cognitive ABI defines the stable semantic interface between cognitive components. Its purpose is to ensure that an Agency, expert, K-line, artifact, compiler, evaluator, market adapter, or remote Mind can participate in the same runtime without depending on the implementation details of DCN Runtime, SurrealDB, a particular model vendor, or a particular transport.

The ABI is not a machine-code ABI. It is a semantic cognitive interface.

A conformant implementation MUST preserve the meaning of the canonical objects and transitions defined here even when it maps them to different languages, transports, process boundaries, or storage engines.

2. Design objective

The canonical execution path is:

Observation / Goal
       ↓
CapabilityRequirement
       ↓
Resolution
       ↓
ExpertBinding
       ↓
Execution
       ↓
PatchProposal / Result
       ↓
Evaluation
       ↓
KLineEpisode
       ↓
Learning / Compilation

Every interoperable cognitive component participates at one or more points in this path.

3. ABI principles

The ABI SHALL be capability-oriented, typed, evidence-aware, authority-aware, asynchronous-capable, transport-neutral, failure-explicit, and versioned.

The ABI SHALL NOT assume that a component is an LLM, that cognition is remote, that execution is stateless, or that successful execution is authorized to mutate world state.

4. Canonical object families

Version 0.1 defines these object families:

Observation
Goal
ContextSlice
CapabilityRequirement
CapabilityResolution
ExpertBinding
ExecutionRequest
ExecutionResult
PatchProposal
ValidationResult
EvaluationRequest
EvaluationResult
KLineEpisode
CompilationRequest
ArtifactCandidate
RuntimeEvent
ErrorEnvelope

Protocol-specific objects such as KLineTemplate, KLineArtifact, ExecutionAct, and SettlementAct are referenced by identity and commitment rather than redefined by the ABI.

5. Common envelope

Every ABI message SHALL carry a common envelope:

{
  "abi": "dcn.cognitive-abi.v1",
  "message_id": "msg:...",
  "message_type": "ExecutionRequest",
  "correlation_id": "corr:...",
  "causation_id": "msg:...",
  "sender": "component:...",
  "recipient": "component:...",
  "created_at": "...",
  "deadline": null,
  "context_commitment": "sha256:...",
  "authority_ref": null,
  "trace_ref": null,
  "payload": {}
}

correlation_id groups messages belonging to one cognitive process. causation_id identifies the message or event that directly caused the current message.

6. Component identity

Every ABI participant SHALL expose a stable ComponentDescriptor containing:

component_id
component_type
supported_abi_versions
capabilities
input/output schemas
execution modes
security properties
privacy properties
evidence capabilities
resource profile

Component types MAY include:

agency
expert
artifact
compiler
evaluator
resolver
market_adapter
memory_adapter
authority_adapter
remote_mind

7. Capability declaration

A component SHALL declare what it can do using semantic capabilities rather than tool names alone.

Example:

{
  "capability": "software_engineering.code_review",
  "input_schema": "schema:code-review-input:v1",
  "output_schema": "schema:code-review-result:v1",
  "quality_claims": [],
  "evidence_classes": ["signed_runtime"],
  "execution_modes": ["local"]
}

Tool protocols such as MCP MAY expose the transport-level invocation, but the Cognitive ABI defines the semantic contract consumed by the Cognitive Kernel.

8. Observation

An Observation represents something perceived by the Mind before interpretation has been promoted into world-state belief.

{
  "schema": "dcn.observation.v1",
  "id": "observation:...",
  "source": "component:...",
  "observed_at": "...",
  "content_type": "...",
  "content_ref": "...",
  "content_commitment": "sha256:...",
  "provenance": [],
  "confidence": null
}

Observations are inputs to cognition, not automatic truth claims.

9. Goal

A Goal describes desired future state rather than an imperative tool invocation.

{
  "schema": "dcn.goal.v1",
  "id": "goal:...",
  "desired_state": {},
  "priority": 0.8,
  "deadline": null,
  "constraints": [],
  "dependencies": [],
  "owner": "mind:..."
}

The runtime MAY derive tasks and capability requirements from goals.

10. ContextSlice

A ContextSlice is the minimum semantically relevant subset of Mind state exposed to a cognitive component.

It SHOULD contain references or commitments instead of indiscriminately copying world state.

{
  "schema": "dcn.context-slice.v1",
  "world_snapshot": "sha256:...",
  "goal_refs": [],
  "entity_refs": [],
  "episode_refs": [],
  "kline_refs": [],
  "policy_refs": [],
  "authority_refs": [],
  "private_data_refs": []
}

Context minimization is an ABI requirement because cognition may execute across trust and privacy boundaries.

11. CapabilityRequirement

The ABI reuses the CapabilityRequirement defined by the K-Line Protocol. It is the canonical demand object for cognition.

Components MUST NOT silently relax mandatory fields such as minimum evidence, privacy, jurisdiction, cost ceiling, latency ceiling, or authority conditions.

12. CapabilityResolution

A resolver returns zero or more candidate bindings rather than directly executing cognition.

{
  "schema": "dcn.capability-resolution.v1",
  "requirement_hash": "sha256:...",
  "candidates": [],
  "resolver": "component:...",
  "resolved_at": "..."
}

The Cognitive Kernel applies local admissibility and routing policy to the result.

13. ExpertBinding

ExpertBinding is the late-bound execution selection defined by the K-Line Protocol. ABI messages MUST preserve the exact binding used so an eventual episode can reconstruct what actually happened.

14. ExecutionRequest

{
  "schema": "dcn.execution-request.v1",
  "execution_id": "execution:...",
  "requirement_hash": "sha256:...",
  "binding": {},
  "context": {},
  "input_ref": "...",
  "input_commitment": "sha256:...",
  "budget": {},
  "authority_ref": null,
  "evidence_requirement": {},
  "deadline": null
}

Receipt of an ExecutionRequest does not imply permission to perform undeclared side effects.

15. ExecutionResult

{
  "schema": "dcn.execution-result.v1",
  "execution_id": "execution:...",
  "status": "completed",
  "output_ref": "...",
  "output_commitment": "sha256:...",
  "proposed_patches": [],
  "evidence_refs": [],
  "metrics": {
    "latency_ms": 0,
    "cost": null,
    "energy": null
  },
  "diagnostics": []
}

An execution may successfully return a result even when its proposed side effects are later rejected.

16. PatchProposal

The ABI reuses the DCN Runtime Patch Proposal Protocol. Patch proposals are semantic state-transition requests, not generic database mutations.

Every proposal SHALL reference the base world-state commitment against which it was generated.

17. ValidationResult

Validation is independent from generation.

{
  "schema": "dcn.validation-result.v1",
  "subject": "patch:...",
  "status": "allowed",
  "checks": [],
  "required_authority": [],
  "conflicts": [],
  "evidence_refs": []
}

A validator MUST NOT silently rewrite the subject it validates.

18. EvaluationRequest and EvaluationResult

Evaluation is a first-class ABI operation. Requests SHALL identify the evaluation protocol and exact subject commitment. Results SHALL remain contextual to the declared distribution and environment.

19. KLineEpisode handoff

After execution and validation, the runtime MAY materialize a KLineEpisode. The ABI SHALL preserve sufficient identifiers, commitments, bindings, evidence references, metrics, and causal links to reconstruct the episode without depending on opaque model transcripts.

20. CompilationRequest

A promoted or repeatedly expensive cognitive topology MAY produce a CompilationRequest:

{
  "schema": "dcn.compilation-request.v1",
  "template_ref": "kline:template:...",
  "episode_refs": [],
  "evaluation_refs": [],
  "targets": ["ios-arm64"],
  "objectives": ["cost", "latency", "energy"],
  "constraints": {
    "quality_floor": 0.95,
    "privacy": "local_only"
  }
}

The Compiler Society may respond with multiple ArtifactCandidates.

21. Runtime events

All ABI implementations SHOULD emit causal runtime events for significant state changes. Recommended events include:

ObservationReceived
GoalCreated
CapabilityRequested
CapabilityResolved
ExecutionStarted
ExecutionCompleted
PatchProposed
PatchValidated
PatchCommitted
EvaluationCompleted
EpisodeRecorded
CompilationRequested
ArtifactProduced

Events SHALL carry correlation and causation identifiers.

22. Asynchrony

ABI operations MAY complete synchronously or asynchronously. Long-running execution MUST NOT require a transport connection to remain continuously open.

Asynchronous operations SHALL expose stable operation identity and observable lifecycle state.

23. Cancellation

Cancellable operations SHALL accept a cancellation signal by operation identity. Cancellation MUST NOT fabricate rollback of external side effects that have already occurred; such effects require compensating Acts or patches.

24. Failure model

Failures are explicit data, not exceptions that disappear at process boundaries.

ErrorEnvelope SHALL distinguish at least:

invalid_input
capability_unavailable
authority_denied
policy_denied
budget_exceeded
deadline_exceeded
execution_failed
evidence_failed
validation_failed
conflict
cancelled
transport_failed
internal_error

Retryability SHOULD be declared independently from error class.

25. Version negotiation

Every component SHALL advertise supported ABI versions. Peers MUST negotiate a mutually supported version before exchanging semantic messages whose interpretation differs across versions.

Backward-compatible extension fields SHOULD be ignored when unknown unless marked critical.

26. Transport neutrality

The ABI MAY be carried over:

in-process calls
stdio
MCP
A2A
HTTP
message queues
local IPC
future transports

Transport-specific authentication and framing MUST NOT redefine the semantic object model.

27. Agent Plugins

Agent Plugins MAY package ABI-capable components by providing skills and MCP servers. Installation makes the component discoverable; it does not create authority, spend permission, trust, or capacity publication.

28. Relationship to MCP

MCP answers: How is a tool or resource invoked?

The Cognitive ABI answers: What cognitive contract is being requested, what constraints apply, what evidence is required, and how does the result enter the Mind's learning and state-transition lifecycle?

MCP is therefore a possible transport/interface binding beneath the ABI rather than a replacement for it.

29. Relationship to A2A

A2A may carry negotiation and communication between autonomous agents or Minds. The Cognitive ABI defines the semantic objects exchanged when those interactions request or return cognition.

30. Relationship to Actum Compute

Actum Compute implements network-level resolution and procurement of CapabilityRequirements. Its quote, assignment, execution receipt, and settlement objects bind to the same requirement and execution identities used by the ABI.

31. Relationship to Actum

ABI lifecycle events MAY ultimately produce Actum cognition Acts. ABI messages themselves are not automatically ledger entries. Only transitions requiring durable verifiable history need to be anchored.

32. Conformance

A Cognitive ABI 0.1 implementation MUST:

support the common message envelope;
support semantic CapabilityRequirement invocation;
preserve exact ExpertBindings;
separate execution results from state mutation;
preserve authority references across boundaries;
preserve evidence requirements and evidence references;
support explicit failure objects;
support version negotiation;
preserve correlation and causation identity;
avoid assuming any particular model vendor, transport, storage engine, or programming language.

The Cognitive ABI is the interoperability boundary that allows the Distributed Cognitive Network to evolve without binding cognition to today's model APIs or agent frameworks.

Distributed Cognitive Network

Volume VII — Cognitive ABI Specification 0.1

Part 2 — Invocation Semantics, Lifecycle, Authority, Evidence, Errors, and Asynchrony

16. Scope

This part defines the runtime semantics of Cognitive ABI messages. Part 1 defines the canonical object families; this part defines how conformant components exchange those objects without losing causality, authority, evidence requirements, lifecycle state, or failure meaning.

The ABI is semantic rather than transport-specific. A local function call, an MCP tool invocation, an A2A exchange, an in-process artifact call, and an Actum Compute job may all implement the same ABI transition.

17. Invocation model

Every cognitive invocation SHALL be modeled as a bounded transition:

Request
  ↓
Admission
  ↓
Execution
  ↓
Result or Failure
  ↓
Validation
  ↓
Episode / Event

A component MUST NOT treat receipt of a request as proof that the request is admissible, authorized, affordable, safe, or executable.

18. Admission

Before execution, the receiving component SHALL evaluate the requirements it is responsible for enforcing. These MAY include:

schema compatibility
authority availability
resource availability
privacy constraints
evidence capability
deadline feasibility
budget feasibility
execution-mode compatibility

Admission has three normative outcomes:

accepted
rejected
accepted_with_declared_constraints

A component MUST NOT silently weaken a mandatory requirement in order to admit work.

19. Invocation lifecycle

A cognitive invocation SHOULD expose the following lifecycle where applicable:

created
  ↓
admitted
  ↓
queued
  ↓
running
  ↓
waiting
  ↓
completed
  ↓
validated

Terminal alternatives include:

rejected
cancelled
expired
failed
superseded

Transitions SHALL be monotonic except for explicit retry, resume, or supersession semantics.

20. Correlation and causation

Every message SHALL carry both correlation_id and causation_id when those concepts apply.

correlation_id identifies a larger cognitive process. causation_id identifies the immediate causal predecessor.

A nested execution therefore remains reconstructable without requiring one global trace implementation.

Example:

Goal G
  ↓ msg-1
CapabilityRequirement R
  ↓ msg-2
Execution E
  ↓ msg-3
PatchProposal P

All messages share one correlation identifier, while each message records its direct cause.

21. Idempotency

Any ABI operation capable of causing durable work, economic reservation, external execution, or state proposal SHOULD support an idempotency key.

A conformant implementation MUST ensure that replay of the same accepted idempotent request does not create duplicate semantic side effects.

Idempotency does not replace Actum nullifiers for settlement or other replay-sensitive finalized Acts.

22. Cancellation

Cancellation SHALL be explicit.

A cancellation request SHOULD identify:

{
  "schema": "dcn.cancellation-request.v1",
  "execution_id": "execution:...",
  "reason": "user_cancelled",
  "authority_ref": "authority:...",
  "requested_at": "..."
}

A component receiving cancellation SHALL report whether cancellation was:

accepted
already_completed
not_cancellable
authority_denied
unknown_execution

Partial outputs MAY be returned but MUST remain marked partial.

23. Deadlines and expiry

A deadline is a semantic constraint rather than scheduling advice.

If a component cannot satisfy a mandatory deadline, it SHOULD reject the invocation before expensive execution begins.

Expired authority, quotes, bindings, or evidence challenges SHALL NOT be silently refreshed by the component performing execution unless the protocol explicitly grants that responsibility.

24. Authority propagation

Authority SHALL propagate by reference, not by implication.

A child invocation MUST NOT inherit broader authority than its parent.

If parent authority is represented by scope A, every derived child scope A_child MUST satisfy:

A_child ⊆ A

Components MAY further attenuate authority.

They MUST NOT amplify it.

25. Authority request

When necessary authority is absent, the component SHOULD return an AuthorityRequirement rather than guessing or performing the side effect.

{
  "schema": "dcn.authority-requirement.v1",
  "capability": "send_email",
  "requested_scope": {},
  "reason": "required_for_proposed_transition",
  "continuation_ref": "continuation:..."
}

The Cognitive Kernel or an authority adapter MAY satisfy the requirement and resume execution.

26. Evidence requirements

Evidence requirements SHALL be declared before execution whenever the evidence class affects admissibility, price, routing, or settlement.

Example:

{
  "required": [
    "provider_authenticated",
    "request_bound",
    "result_bound"
  ],
  "minimum_assurance_profile": "VERIFIED_BOUND"
}

A provider MUST NOT claim stronger evidence than it can actually produce.

27. EvidenceGraphRef

The ABI represents execution evidence through an EvidenceGraphRef rather than embedding arbitrary proof payloads.

{
  "schema": "dcn.evidence-graph-ref.v1",
  "graph_id": "evidence-graph:...",
  "root_commitment": "sha256:...",
  "required_nodes": [],
  "availability_refs": []
}

The graph MAY reference TLSNotary evidence, ZeroK proofs, runtime signatures, TEEs, human attestations, evaluation evidence, certificates, or prior Acts.

The ABI does not reinterpret the semantics of those evidence protocols.

28. Assurance propagation

Components SHALL preserve assurance granularity.

A binary verified=true field is non-conformant when the underlying protocol exposes distinct assurance dimensions.

The canonical assurance dimensions include, where applicable:

identity
authority
provider
model
request_binding
response_binding
result_binding
artifact_binding
freshness
privacy
replay_resistance
finality

A downstream component MUST NOT strengthen an assurance dimension without new evidence.

29. Result classes

An execution can produce one or more semantic result classes:

answer
artifact
patch_proposal
decision
observation
evaluation
capability_requirement
continuation

A result MAY contain several classes simultaneously.

A side-effecting result SHOULD be represented as a PatchProposal or explicit external-action proposal rather than an undocumented effect.

30. PatchProposal ABI contract

A PatchProposal SHALL reference the state snapshot against which it was generated.

{
  "schema": "dcn.patch-proposal.v1",
  "patch_id": "patch:...",
  "base_state_commitment": "sha256:...",
  "operations": [],
  "justification_refs": [],
  "required_authority": [],
  "expected_effects": [],
  "confidence": 0.94,
  "origin_execution": "execution:..."
}

Receipt of a PatchProposal never implies commitment.

31. ValidationResult

Validation SHALL be represented separately from generation.

{
  "schema": "dcn.validation-result.v1",
  "subject_ref": "patch:...",
  "status": "accepted",
  "checks": [],
  "evidence_refs": [],
  "required_followups": []
}

A validator MUST NOT silently rewrite a proposal and report the rewritten object as though it were the original.

32. Asynchronous execution

The ABI SHALL support asynchronous execution.

An accepted invocation MAY return:

{
  "status": "accepted",
  "execution_id": "execution:...",
  "continuation_ref": "continuation:..."
}

The caller can then receive or retrieve subsequent RuntimeEvents and the final ExecutionResult.

Transport bindings MAY implement this through callbacks, streams, polling, subscriptions, queues, or A2A messaging.

33. Continuations

A continuation represents resumable cognitive work whose semantic process identity must survive suspension.

{
  "schema": "dcn.continuation.v1",
  "continuation_id": "continuation:...",
  "correlation_id": "corr:...",
  "checkpoint_ref": "checkpoint:...",
  "waiting_for": [],
  "expires_at": null
}

Continuations MUST NOT contain transferable secrets unless an explicit security profile defines their protection.

34. Streaming

Streaming is an optional transport feature, not a distinct cognitive semantic.

Intermediate streamed material SHALL be classified as one of:

progress
partial_result
observation
proposal
final_result

Only a declared final_result satisfies an invocation unless the request explicitly allows partial completion.

35. RuntimeEvent

Runtime events provide transport-neutral observation of cognitive execution.

{
  "schema": "dcn.runtime-event.v1",
  "event_id": "event:...",
  "event_type": "ExecutionCompleted",
  "correlation_id": "corr:...",
  "causation_id": "msg:...",
  "subject_ref": "execution:...",
  "payload": {},
  "occurred_at": "..."
}

Events MAY be persisted locally or anchored through protocol-specific Acts when their significance requires durable verification.

36. Failure model

Failure SHALL be explicit and typed.

Version 0.1 defines these top-level failure classes:

INVALID_REQUEST
INCOMPATIBLE_SCHEMA
ADMISSION_REJECTED
AUTHORITY_REQUIRED
AUTHORITY_DENIED
POLICY_DENIED
CAPABILITY_UNAVAILABLE
RESOURCE_EXHAUSTED
BUDGET_EXCEEDED
DEADLINE_EXCEEDED
PRIVACY_CONSTRAINT
EVIDENCE_UNAVAILABLE
EXECUTION_FAILED
VALIDATION_FAILED
DEPENDENCY_FAILED
CONFLICT
CANCELLED
INTERNAL_ERROR

Extensions MAY add domain-specific subclasses without changing the top-level meaning.

37. ErrorEnvelope

{
  "schema": "dcn.error-envelope.v1",
  "error_id": "error:...",
  "class": "CAPABILITY_UNAVAILABLE",
  "code": "NO_ADMISSIBLE_BINDING",
  "message": "No candidate satisfied the mandatory evidence profile.",
  "retryable": true,
  "retry_after": null,
  "details": {},
  "caused_by": [],
  "required_action": null
}

Errors MUST NOT expose secrets merely to improve diagnostics.

38. Retry semantics

Retry policy SHALL depend on failure class.

Examples:

network/transient dependency → MAY retry
authority required → WAIT for authority
policy denied → MUST NOT retry unchanged
invalid schema → MUST NOT retry unchanged
no admissible expert → MAY resolve alternatives
validation failure → MAY escalate to System 2

A retry that changes provider, artifact, model, authority, or evidence class SHALL create a new concrete binding record.

39. Partial failure

Composite cognition MAY partially succeed.

A composite result SHALL declare which nodes completed and which failed. It MUST NOT present partial completion as total success.

The Cognitive Kernel decides whether to retry, substitute, accept degraded output, or reopen System 2 according to the K-line and local policy.

40. Version negotiation

Every component SHALL declare supported ABI versions.

Negotiation SHOULD select the highest mutually supported version that satisfies required features.

A component MUST reject a message whose mandatory semantics it cannot preserve.

Unknown optional extension fields MAY be ignored only when the extension is explicitly marked optional.

41. Extension namespaces

Extensions SHALL use namespaced identifiers.

Example:

org.example.medical.calibration.v1
actum.compute.quote-extension.v1

Extensions MUST NOT redefine normative core fields with incompatible semantics.

42. Security invariant

The Cognitive ABI carries cognition across process, device, organizational, and network boundaries. Therefore every implementation SHALL preserve this invariant:

Semantic interoperability never implies authority interoperability.

A component may understand a requested action perfectly and still lack permission to perform it.

43. Part 2 conformance

A conformant implementation of Part 2 MUST:

expose explicit invocation lifecycle state;
preserve correlation and causation;
propagate authority by reference and without amplification;
declare evidence requirements before evidence-dependent execution;
preserve assurance granularity;
support typed failures;
distinguish proposals from committed side effects;
support asynchronous completion or explicitly declare synchronous-only limitations;
prevent idempotent request replay from duplicating semantic effects;
reject incompatible mandatory semantics rather than silently degrading them.

Distributed Cognitive Network

Volume VII — Cognitive ABI Specification 0.1

Part 3 — Conformance, Capability Negotiation, Versioning, and Reference Interaction Patterns

41. Purpose

This part defines how independently implemented DCN components determine whether they can interoperate, negotiate compatible contracts, preserve semantic guarantees across versions, and demonstrate conformance.

The Cognitive ABI is useful only if interoperability can be tested rather than asserted.

42. Conformance Classes

Version 0.1 defines the following conformance classes:

ABI Core
Runtime Host
Cognitive Component
Capability Resolver
Execution Provider
Evaluator
Compiler
Transport Binding
Agent Plugin Package

An implementation MAY conform to more than one class.

A conformance claim MUST identify the exact ABI version and conformance classes claimed.

43. ABI Core Conformance

An ABI Core implementation MUST:

parse and emit the common envelope;
preserve correlation and causation identifiers;
validate canonical object schemas;
preserve unknown extension fields according to extension policy;
represent explicit failure using ErrorEnvelope;
preserve authority and evidence requirements without silent relaxation;
support version negotiation;
expose conformance metadata.

44. Runtime Host Conformance

A Runtime Host is an environment such as the DCN Runtime that coordinates cognitive components.

A conformant Runtime Host MUST:

apply local admissibility policy before binding execution;
distinguish capability resolution from capability execution;
distinguish execution success from authorization to commit a state change;
preserve the exact ExpertBinding used by an execution;
preserve causal lineage sufficient to construct a KLineEpisode;
isolate component failures from authoritative world state;
support cancellation and deadlines;
expose runtime events through a defined event interface.

A Runtime Host SHOULD support checkpointing and asynchronous execution.

45. Cognitive Component Conformance

A Cognitive Component MUST expose a ComponentDescriptor and MUST declare each supported semantic capability.

For each capability it MUST declare:

capability identifier
input schema
output schema
supported ABI versions
execution mode
side-effect class
evidence capabilities
authority requirements
resource profile or unknown marker

A component MUST NOT claim a capability merely because an underlying tool has a similarly named operation.

Capability identity is semantic.

46. Side-Effect Classes

The ABI defines four baseline side-effect classes:

pure
observational
proposal_only
externally_effectful

pure components produce outputs without observing or changing external state.

observational components may read external state but do not change it.

proposal_only components may propose changes through PatchProposal but cannot commit them.

externally_effectful components can cause effects outside the Mind and therefore MUST declare explicit authority requirements.

A Runtime Host MUST NOT infer a weaker side-effect class than the component declares.

47. Capability Negotiation

Negotiation begins with a CapabilityRequirement and one or more ComponentDescriptor or market offers.

The process is:

CapabilityRequirement
        ↓
Discover candidates
        ↓
Schema compatibility
        ↓
Policy admissibility
        ↓
Evidence compatibility
        ↓
Authority compatibility
        ↓
Resource/budget compatibility
        ↓
Candidate ranking
        ↓
ExpertBinding

Filtering MUST precede utility optimization.

A candidate that violates a mandatory requirement is inadmissible regardless of price or expected quality.

48. Schema Compatibility

Two schemas are compatible when the consumer can safely interpret every output required by the contract and the provider can safely interpret every required input.

Implementations SHOULD use explicit schema identifiers and versions rather than structural guessing.

A resolver MUST NOT silently coerce incompatible semantic units, identity domains, authority scopes, or privacy classifications.

Adapters MAY perform transformations when the transformation itself is declared as a component and can be included in lineage.

49. Capability Composition

A requirement MAY be satisfied by a composition rather than a single provider.

Example:

software_engineering.secure_review
        ↓
code_review
   +
dependency_analysis
   +
independent_critic

The composed resolution MUST expose the resulting topology, aggregate evidence properties, aggregate resource estimate, and any new failure modes.

Composition itself MAY be represented by a K-line.

50. Version Negotiation

Every ABI participant MUST declare supported ABI versions.

Negotiation selects the newest mutually supported version that satisfies local policy.

Example:

{
  "supported": [
    "dcn.cognitive-abi.v1"
  ],
  "extensions": [
    "dcn.ext.streaming.v1",
    "dcn.ext.zk-evidence.v1"
  ]
}

Failure to identify a mutually acceptable version MUST produce an explicit compatibility error.

51. Compatibility Rules

Within a major ABI version:

new optional fields MAY be added;
new optional enum values MAY be added only where the schema declares open enumeration;
mandatory field semantics MUST NOT change;
existing field meanings MUST NOT be weakened;
security, authority, privacy, and evidence semantics MUST NOT be silently relaxed.

A breaking semantic change requires a new major ABI version.

52. Extension Model

Extensions use namespaced identifiers.

Example:

dcn.ext.streaming.v1
dcn.ext.confidential-compute.v1
dcn.ext.zk-evidence.v1
org.example.specialist-metadata.v1

An extension MUST define whether it is:

optional
required_for_execution
required_for_verification

Unknown optional extensions MAY be ignored while preserving their data where forwarding is required.

Unknown required extensions MUST cause negotiation failure.

53. Error Taxonomy

The baseline error taxonomy includes:

INVALID_MESSAGE
UNSUPPORTED_ABI_VERSION
UNSUPPORTED_EXTENSION
SCHEMA_MISMATCH
CAPABILITY_UNAVAILABLE
NO_ADMISSIBLE_PROVIDER
AUTHORITY_REQUIRED
AUTHORITY_DENIED
POLICY_DENIED
PRIVACY_CONSTRAINT_UNSATISFIED
EVIDENCE_CONSTRAINT_UNSATISFIED
BUDGET_EXCEEDED
DEADLINE_EXCEEDED
EXECUTION_FAILED
VALIDATION_FAILED
CONFLICT
CANCELLED
PROVIDER_UNAVAILABLE
INTERNAL_ERROR

Implementations MAY define namespaced subcodes.

54. Retry Semantics

Errors MUST declare whether retry is potentially meaningful.

Recommended classes:

never
same_binding
new_binding
replan
human_required

For example, PROVIDER_UNAVAILABLE may permit new_binding, while AUTHORITY_DENIED normally does not permit automatic retry.

55. Cancellation

Every long-running execution SHOULD support cancellation.

Cancellation MUST identify the execution and SHOULD include a reason.

A cancelled component MUST stop creating new externally effectful operations as soon as practical and MUST return any partial results or evidence that policy permits to retain.

Cancellation does not erase already finalized external effects.

56. Idempotency

Externally effectful operations MUST expose an idempotency or replay-control mechanism appropriate to the transport and effect domain.

The ABI envelope's message_id is not by itself sufficient to guarantee economic or external-effect replay protection.

Actum nullifiers, provider idempotency keys, or equivalent mechanisms MAY be bound into the execution lineage.

57. Streaming

Streaming is an optional ABI extension.

A stream MUST remain bound to one execution_id and MUST distinguish:

partial_output
progress
evidence_fragment
usage_update
terminal_result
terminal_error

Partial output MUST NOT be treated as a completed ExecutionResult.

58. Human Components

Humans MAY participate as ABI components through an adapter.

The adapter MUST preserve:

human role or pseudonymous identity commitment as policy permits;
requested capability;
supplied context;
response commitment;
evaluation and evidence references;
authority boundaries.

The ABI does not assume cognition is machine-generated.

59. Local Artifact Interaction Pattern

Cognitive Kernel
      ↓ CapabilityRequirement
Local Resolver
      ↓ CapabilityResolution
Artifact Binding
      ↓ ExecutionRequest
Local Artifact
      ↓ ExecutionResult
Validator
      ↓ ValidationResult
Episode Recorder

No market interaction is required.

60. Remote Expert Interaction Pattern

Cognitive Kernel
      ↓ CapabilityRequirement
Actum Compute Adapter
      ↓ candidate offers
Cognitive Kernel
      ↓ ExpertBinding
Remote Provider Adapter
      ↓ ExecutionRequest
Remote Expert
      ↓ output + evidence
Provider Adapter
      ↓ ExecutionResult
Evaluator / Validator
      ↓
KLineEpisode + optional Actum ExecutionAct

The provider adapter translates transport details without changing the semantic ABI contract.

61. K-Line Execution Pattern

A K-line activation MAY generate several capability requirements.

KLineTemplate
      ↓ activation
CapabilityRequirement A ──→ Binding A
CapabilityRequirement B ──→ Binding B
CapabilityRequirement C ──→ Binding C
      ↓
Execution graph
      ↓
Results
      ↓
Validation
      ↓
KLineEpisode

The episode MUST preserve the actual bindings rather than only the template requirements.

62. Compilation Interaction Pattern

Episodes + Evaluations
        ↓
CompilationRequest
        ↓
Compiler Society
        ↓
ArtifactCandidate
        ↓
EvaluationRequest
        ↓
EvaluationResult
        ↓
Publication / Promotion protocol

The ABI transports compilation work; Volume VI defines compilation semantics.

63. Agent Plugin Conformance Profile

An Agent Plugin package MAY expose one or more ABI components.

A conformant package SHOULD include a machine-readable mapping from plugin-exposed skills or MCP tools to Cognitive ABI capabilities.

Conceptually:

{
  "cognitive_abi": "dcn.cognitive-abi.v1",
  "components": [
    {
      "component_id": "component:example",
      "descriptor": "./dcn/component.json",
      "bindings": {
        "mcp": "./mcp.json"
      }
    }
  ]
}

The exact portable packaging mechanism is defined by the applicable Agent Plugins specification. The Cognitive ABI profile does not redefine plugin manifests or credential handling.

Installing a plugin MUST NOT be interpreted as granting the component authority to perform side effects.

64. MCP Binding Profile

MCP MAY transport Cognitive ABI capability invocations.

A mapping MUST identify:

ABI capability
MCP tool/resource/prompt binding
input transformation
output transformation
error mapping
evidence mapping
side-effect class

MCP discovery does not replace semantic capability declaration.

65. A2A Binding Profile

A2A MAY transport cognition involving autonomous remote agents or Minds.

The binding MUST preserve execution identity, authority requirements, context commitments, evidence requirements, cancellation semantics, and terminal result state.

A2A autonomy does not override local activation sovereignty.

66. Actum Binding Profile

The ABI itself is not a ledger protocol.

Where durable verifiable history is required, a Runtime Host MAY derive or reference Actum Acts from ABI interactions.

The binding MUST preserve commitments sufficient to connect an Actum Act to the corresponding ABI execution without requiring private payload disclosure.

67. Conformance Test Categories

The reference conformance suite SHOULD contain at least:

envelope tests
schema tests
version-negotiation tests
extension tests
capability-negotiation tests
authority-preservation tests
evidence-preservation tests
privacy-constraint tests
error-mapping tests
cancellation tests
idempotency/replay tests
transport-binding tests
K-line lineage tests
compilation-lineage tests

Security-sensitive negative tests are mandatory for a production conformance claim.

68. Golden Interaction Traces

The project SHOULD publish canonical interaction traces that conforming implementations can replay.

Each trace SHOULD include:

input messages
expected state transitions
expected output messages
allowed nondeterministic fields
expected errors for invalid variants

Golden traces provide a language-neutral interoperability target.

69. Language Bindings

The normative ABI is language-neutral.

Reference bindings SHOULD be generated or maintained for at least:

Rust
TypeScript
Swift

Bindings MUST preserve canonical field semantics and MUST NOT introduce language-specific behavior into the protocol definition.

70. Schema Registry

Canonical schemas SHOULD live under a versioned repository namespace such as:

schemas/cognitive-abi/v1/

Schema identity MUST be stable after publication. Corrections that change semantics require a new schema version.

71. Interoperability Invariant

The central ABI invariant is:

Components may differ in implementation, transport, provider, model, language, and execution environment while preserving the same semantic cognitive contract.

This is what allows the DCN to evolve without binding cognition to today's vendors or agent frameworks.

72. Strategic Consequence

The Cognitive ABI turns the architecture from a collection of compatible ideas into an interoperable platform.

Kline can describe cognition without owning providers. Actum Compute can resolve capabilities without owning cognition. The DCN Runtime can schedule components without knowing their internal implementation. Actum can record verifiable history without becoming the runtime. Agent Plugins, MCP, A2A, local function calls, and future transports can carry the same semantic contracts.

The ABI is therefore the stable waist of the Distributed Cognitive Network: narrow enough to implement across environments, but expressive enough to preserve capability, context, authority, evidence, lineage, evaluation, and learning.

Distributed Cognitive Network

Volume VII — Cognitive ABI Specification 0.1

Part 4 — Canonical Lifecycle, State Machines, Security Properties, and Schema Roadmap

73. Purpose

This part closes Cognitive ABI 0.1 by defining the canonical lifecycle connecting the objects introduced in Parts 1–3, the minimum security properties an implementation must preserve, and the executable-schema roadmap required to turn the prose specification into a testable standard.

74. Canonical Cognitive Transaction

A cognitive transaction is the causally connected set of ABI interactions used to satisfy a goal or requirement. It is not necessarily a database transaction and may span local and remote components.

The baseline lifecycle is:

Observation / Goal
       ↓
Context Assembly
       ↓
Recognition
       ↓
CapabilityRequirement
       ↓
CapabilityResolution
       ↓
ExpertBinding
       ↓
ExecutionRequest
       ↓
ExecutionResult
       ↓
Validation / Evaluation
       ↓
PatchProposal (when state change is proposed)
       ↓
Authorization
       ↓
Commit
       ↓
KLineEpisode
       ↓
Learning / Compilation

Not every interaction requires every stage. Omitted stages MUST be justified by the semantics of the capability rather than silently bypassed.

75. Execution State Machine

Canonical execution states are:

created
  ↓
accepted
  ↓
running
  ├──→ waiting
  │      ↓
  │    running
  ↓
completed

Terminal alternatives are:

failed
cancelled
expired

An implementation MUST emit exactly one terminal state for an execution.

76. Patch State Machine

A PatchProposal follows:

created
  ↓
validated
  ↓
authorized
  ↓
committed

Alternative terminal states include:

rejected
conflicted
cancelled
expired

Execution completion MUST NOT be treated as patch commitment.

77. Evaluation State Machine

An evaluation follows:

requested
  ↓
accepted
  ↓
running
  ↓
completed

The completed result MUST identify its subject, protocol, environment or distribution commitments where applicable, evaluator, result, and evidence references.

An evaluation result is contextual evidence, not universal truth.

78. Compilation State Machine

Compilation follows:

candidate identified
       ↓
CompilationRequest
       ↓
compiling
       ↓
ArtifactCandidate
       ↓
evaluation
       ↓
eligible for publication/promotion

The ABI does not permit a compiler to mark its own output as trusted merely by completing compilation.

79. Causal Lineage

Every state transition SHOULD preserve sufficient causality to answer:

What caused this?
Which goal did it serve?
Which context was exposed?
Which capability was requested?
Which provider or artifact was bound?
What evidence was produced?
What evaluation was applied?
Which state change resulted?
What later cognition was learned from it?

Causal lineage is a first-class interoperability property.

80. Commitment Boundary

Private content and public or federated history are separated by commitments and references.

A component SHOULD expose the minimum information required for its role.

Example:

private prompt
    ↓ hash/commitment
ExecutionRequest
    ↓
remote execution
    ↓
private response
    ↓ hash/commitment
ExecutionResult
    ↓
Actum evidence reference

The ABI does not require raw private payloads to become globally visible.

81. Authority Non-Amplification

A component MUST NOT derive broader authority than it receives.

If authority permits:

send one email to recipient R

an adapter, K-line, expert, or artifact MUST NOT reinterpret that authority as:

send arbitrary email

Authority transformations MUST be monotonic toward equal or narrower scope unless a new authority grant is obtained.

82. Privacy Non-Degradation

A component MUST NOT silently weaken a mandatory privacy requirement during capability resolution, composition, adaptation, or fallback.

If a requirement specifies local_only, a resolver cannot satisfy it with a remote provider because the remote provider has higher quality.

Fallbacks that alter privacy class require explicit policy authorization.

83. Evidence Non-Degradation

Evidence requirements are also monotonic.

A provider requiring provider_authenticated + transcript_commitment cannot be replaced by an otherwise equivalent provider producing only a self-signed receipt unless local policy explicitly permits the weaker class.

The exact evidence mechanism remains late-bound.

84. Context Non-Expansion

Adapters and composed components MUST NOT receive more context merely because the Runtime Host possesses it.

Context assembly SHOULD implement least disclosure:

whole Mind state
      ≠
component context

A ContextSlice is a capability-specific view, not a serialization of the entire Mind.

85. Provider Substitution

Late binding permits provider substitution only while preserving the mandatory semantic contract.

Substitution MUST preserve or improve mandatory:

capability semantics
schema compatibility
authority constraints
privacy constraints
evidence constraints
jurisdiction constraints
side-effect class

Cost, latency, energy, and expected quality may then be optimized among admissible candidates.

86. Confused-Deputy Resistance

The Runtime Host MUST bind authority to the intended execution context rather than merely to component identity.

A component trusted for one capability MUST NOT reuse authority from that execution for another capability or goal.

Correlation identifiers are not authorization tokens.

87. Prompt and Data Injection Boundary

External content is data unless explicitly promoted through a trusted interpretation process.

Retrieved documents, web pages, emails, market descriptions, expert outputs, and K-lines obtained from federation MUST NOT automatically acquire runtime authority because they contain imperative language.

The ABI SHOULD preserve source provenance and trust classification for externally supplied content.

88. Artifact Supply-Chain Security

An artifact descriptor SHOULD bind:

artifact identity
content hash
template identity
compiler identity
build or compilation lineage
dependencies
evaluation references
runtime requirements
publisher

Artifact installation does not imply activation or authority.

89. K-Line Supply-Chain Security

Federated K-lines are executable cognitive supply-chain content.

A Runtime Host SHOULD require discovery, inspection, verification, trust evaluation, caching, and local activation before a remote K-line participates in System 1.

Remote publication MUST NOT directly modify local procedural cognition.

90. Market Isolation

Economic incentives MUST NOT override semantic admissibility.

Actum Compute may rank and price candidates, but the Runtime Host retains local authority to reject every market result.

A market cannot grant a provider trust merely by accepting payment or stake.

91. Evaluation Independence

Where policy requires independent evaluation, the evaluator MUST be logically distinct from the subject being evaluated according to the applicable trust policy.

The ABI MUST preserve evaluator identity or commitment sufficiently for this property to be checked.

92. Replay Resistance

Replay protection MAY occur at several layers:

ABI execution idempotency
provider request nonce
Actum nullifier
authority nonce
payment/settlement nullifier

Implementations MUST use the replay mechanism appropriate to the effect being protected.

93. Time and Freshness

Messages SHOULD carry timestamps and MAY carry deadlines, validity windows, freshness challenges, or monotonic counters.

Security-sensitive decisions MUST NOT rely on untrusted wall-clock timestamps alone when stronger freshness evidence is required.

94. Resource Exhaustion

Runtime Hosts SHOULD enforce limits on:

message size
context size
concurrent executions
recursive composition depth
K-line activation depth
stream duration
retry count
market discovery breadth
compiler workload

A Society of Experts must not become an unbounded fan-out mechanism.

95. Recursive Cognition Safety

Nested Agencies, K-lines, compilers, and remote Minds MAY recursively request capabilities.

The Runtime Host SHOULD preserve a causal depth counter or equivalent execution graph and MUST be able to terminate recursion according to local policy.

96. Determinism Declaration

Components SHOULD declare one of:

deterministic
seeded_nondeterministic
nondeterministic
external_state_dependent

This declaration informs replay, evaluation, caching, and evidence policy.

97. Cache Semantics

Cached cognition MUST remain bound to the conditions under which reuse is valid.

A cache entry SHOULD identify:

input commitment
context/environment signature
artifact/provider identity
validity window
evaluation status
authority assumptions
privacy class

Caching MUST NOT turn an expired or unauthorized execution into valid cognition.

98. Canonical Schema Set

Cognitive ABI 0.1 SHOULD be backed by machine-readable schemas for at least:

CommonEnvelope
ComponentDescriptor
CapabilityDescriptor
Observation
Goal
ContextSlice
CapabilityRequirement
CapabilityResolution
ExpertBinding
ExecutionRequest
ExecutionResult
PatchProposal
ValidationResult
EvaluationRequest
EvaluationResult
KLineEpisode
CompilationRequest
ArtifactCandidate
RuntimeEvent
ErrorEnvelope
VersionNegotiation
CancellationRequest

99. Schema Generation

The repository SHOULD establish one canonical schema source and generate language bindings where practical.

The target layout is:

schemas/
  cognitive-abi/
    v1/
      *.schema.json
bindings/
  rust/
  typescript/
  swift/

Generated bindings MUST NOT become a competing source of protocol truth.

100. Conformance Fixtures

The repository SHOULD add:

conformance/
  valid/
  invalid/
  traces/
  security/

Fixtures SHOULD test both schema validity and semantic invariants that cannot be expressed in JSON Schema alone.

101. Reference Adapter Requirements

Reference adapters for MCP, A2A, Agent Plugins, Actum Compute, and Actum SHOULD be deliberately thin.

They translate between the Cognitive ABI and external protocols. They MUST NOT relocate cognitive policy into the transport adapter.

102. Stable Waist Principle

The Cognitive ABI is intentionally narrower than the complete DCN architecture.

Above it, cognition may evolve through new K-lines, experts, compiler techniques, evaluation methods, and applications.

Below it, execution may evolve through new transports, model providers, hardware, confidential-compute systems, proof systems, and markets.

The ABI remains the stable semantic waist between these layers.

103. Volume VII Invariants

A conformant implementation preserves the following invariants:

Capability is semantic and provider-independent.
Binding is late and evidence-aware.
Context is minimized.
Authority is explicit and non-amplifying.
Execution success is distinct from authorization and state commitment.
Evidence is preserved without being confused with truth.
Failure is explicit.
Causality and lineage survive transport boundaries.
Transport protocols do not become cognitive policy.
Local activation sovereignty is preserved.
Version and extension negotiation fail closed for mandatory semantics.
Learning and compilation remain connected to the executions from which they derive.

104. Completion of Cognitive ABI 0.1

Parts 1–4 define the conceptual Cognitive ABI 0.1.

The next maturity step is not additional prose. It is to make the ABI executable through canonical JSON Schemas, generated Rust/TypeScript/Swift bindings, golden interaction traces, and a conformance test suite.

Once those artifacts exist, independent DCN Runtime, Kline, Actum Compute, evaluator, compiler, and expert implementations can be tested against the same semantic contract.

Distributed Cognitive Network

Volume VIII — Cognitive Programming Model

Draft Specification 0.1

1. Purpose

The Cognitive Programming Model defines how developers express applications and services that run on a DCN Runtime without programming directly against model vendors, transport protocols, or mutable agent internals.

The programming model is built from the Cognitive ABI and uses a small set of semantic primitives:

Observation
Goal
ContextSlice
CapabilityRequirement
Agency
KLineTemplate
PatchProposal
Evaluation
AuthorityRequirement
RuntimeEvent
CompilationHint

The central programming rule is:

Programs describe desired cognition and admissible effects; the DCN Runtime decides how cognition is scheduled and bound.

2. Goal-Oriented Programming

A DCN application SHOULD begin with a goal rather than an imperative sequence of model calls.

A goal describes desired future state, priority, constraints, deadline, owner, and success conditions. The runtime may satisfy the same goal using System 1, System 2, a local artifact, an expert composition, a human, or a future implementation not known when the program was authored.

3. Observation-Oriented Inputs

External inputs enter as Observation objects. Programs MUST NOT treat arbitrary external content as authoritative state merely because it is received.

Interpretation, belief formation, and state mutation are distinct transitions.

4. Capability-Oriented Invocation

Applications request semantic capabilities:

CapabilityRequirement
  capability: software_engineering.secure_review
  input_schema: ...
  output_schema: ...
  quality_floor: ...
  privacy: local_or_confidential
  evidence: verified_execution
  max_cost: ...
  deadline: ...

They SHOULD NOT encode a commercial model as the semantic requirement unless provider identity is itself part of the task requirement.

5. Agencies

An Agency is a persistent specialized cognitive process with a declared contract. Agencies are schedulable components of a Mind, not independent owners of truth or authority.

An Agency contract declares purpose, capabilities, accepted inputs, produced outputs, side-effect class, authority requirements, resource limits, lifecycle policy, and failure semantics.

6. K-Line Invocation

Programs MAY explicitly activate a known KLineTemplate, but SHOULD normally allow the Cognitive Kernel to recognize applicable K-lines from goals and context.

A K-line invocation binds semantic capability nodes late. The resulting KLineEpisode records the actual bindings and evidence.

7. Patch-Oriented Programming

Cognitive code does not directly mutate authoritative world state. It produces PatchProposal objects.

reason → propose → validate → authorize → commit

Patch operations SHOULD be semantic (CreateTask, ScheduleMeeting, AttachEvidence) rather than generic storage CRUD when a domain operation exists.

8. Cognitive Transactions

A cognitive transaction is a causally connected attempt to satisfy a goal. It may span several experts, asynchronous waits, evaluations, and external effects.

Database atomicity and cognitive transactionality are distinct. State-changing patch batches MUST commit atomically at the world-state boundary where partial semantic change would violate invariants.

9. Context Construction

Applications MAY declare context requirements but SHOULD NOT manually concatenate the Mind's history into prompts.

The Runtime Host assembles a least-disclosure ContextSlice from relevant world state, goals, episodes, K-lines, policies, and authority references.

10. Authority Declarations

Programs declare required authority; they do not grant it.

Authority MUST be resolved by the authority layer and bound to the concrete execution or proposed effect. Installation, invocation, model confidence, and successful execution are not authority grants.

11. Evaluation as Code

Applications MAY attach evaluation requirements to capabilities, K-lines, artifacts, and outputs. Evaluations reference an EvaluationProtocol rather than an unqualified score.

High-risk programs SHOULD make evaluation gates explicit before effect commitment.

12. Events and Reactivity

Applications react to immutable runtime events such as observations, goal changes, execution completion, evaluation completion, patch commitment, drift, and authority changes.

Event handlers produce cognition or proposals; they MUST NOT bypass normal authority and validation semantics.

13. Asynchrony

Remote experts, humans, market resolution, compilation, and evaluation may be asynchronous. Programs SHOULD be resumable and cancellation-aware rather than assuming a request/response call stack.

14. Failure

Failure is typed. Programs SHOULD handle failure classes semantically: retry the same binding, seek a new binding, replan, request authority, escalate to a human, or terminate.

Blind retry loops are non-conformant for failures such as authority denial or policy denial.

15. Compilation Hints

Applications MAY provide non-binding hints such as expected execution frequency, acceptable approximation, locality preference, latency target, and target hardware.

Compilation hints MUST NOT weaken quality, privacy, evidence, authority, or safety requirements.

16. Declarative Example

goal SecureReview(repo):
  success: no unresolved critical findings

  require review:
    capability: software_engineering.secure_review
    privacy: local_or_confidential
    evidence: signed_runtime

  evaluate review:
    protocol: security-review-v1

  propose:
    AttachReview(repo, review)

  compile:
    prefer_local: true
    expected_frequency: high

The example expresses cognition without selecting a model, market, transport, or storage operation.

17. Host API

A Runtime Host SHOULD expose programming interfaces equivalent to:

observe(observation)
submit_goal(goal)
resolve(requirement)
execute(binding, context)
propose(patch)
validate(patch)
request_authority(requirement)
evaluate(subject, protocol)
subscribe(event_filter)
cancel(execution)
compile(request)

Concrete language APIs MAY differ while preserving Cognitive ABI semantics.

18. Application Packaging

A DCN application MAY be packaged as an Agent Plugin, native application, service, library, or remote Mind. Packaging is not authority.

Agent Plugin distributions SHOULD map skills and MCP tools to Cognitive ABI capabilities and declare their side-effect classes.

19. Testing

Applications SHOULD be testable with deterministic Runtime Host fixtures, fake capability resolvers, golden ABI traces, simulated authority decisions, and explicit failure injection.

Tests SHOULD assert semantic outcomes and patches rather than model wording.

20. Programming Invariants

Goals describe desired state; tools are implementation detail.
Capability requirements are semantic and late-bound.
Context follows least disclosure.
Cognition proposes; authority governs; the state layer commits.
Failure is explicit.
Evaluation is contextual.
Programs are resumable and cancellation-aware.
Provider substitution cannot weaken mandatory requirements.
Application packaging does not grant authority.
Repeated successful cognition may become compilable cognitive capital.

Distributed Cognitive Network

Volume IX — Cognitive Economics

Draft Specification 0.1

1. Purpose

This volume defines the economic model of the Distributed Cognitive Network. The network does not treat tokens as the fundamental scarce asset. It treats proven problem-solving capability and reusable cognitive capital as economically valuable resources.

2. Economic Layers

The DCN supports distinct but interoperable markets for:

Expert execution
K-line/artifact licensing
Evaluation
Evidence and verification
Compute
Data/retrieval services
Human expertise

These markets MUST remain subordinate to local admissibility, authority, privacy, and evidence policy.

3. Actum Compute

Actum Compute is the capability-discovery and economic coordination layer. It accepts semantic CapabilityRequirement demand and discovers admissible supply offers.

Actum Compute does not become the Cognitive Kernel and does not decide what cognition a Mind must activate.

4. Expert Offers

An ExpertOffer SHOULD declare capability, schemas, quality claims with evaluation references, evidence classes, execution environment, privacy properties, availability, price, latency estimate, and settlement terms.

Provider identity MAY be disclosed, selectively disclosed, or hidden according to the required evidence and privacy class.

5. Artifact Offers

An ArtifactOffer represents licensing or execution of compiled cognition. It SHOULD bind artifact hash, K-line template, deployment target, evaluation claims, publisher, dependencies, price model, royalty policy, and provenance.

6. Evaluation Market

Evaluators earn compensation for producing contextual EvaluationClaim evidence under defined protocols. Payment MUST NOT imply that an evaluation result is accepted as truth by a Mind.

Independence requirements are part of local trust policy.

7. Evidence Market

Verification services may sell evidence production: authenticated execution receipts, transcript commitments, attestations, confidential-compute evidence, zero-knowledge predicates, or other proof classes.

Evidence proves defined claims; it does not establish semantic truth beyond those claims.

8. Pricing

Price is one routing input after admissibility filtering. A lower price cannot compensate for missing authority, privacy, evidence, jurisdiction, or minimum quality constraints.

Pricing MAY be fixed, metered, auction-based, subscription-derived, royalty-based, or negotiated.

9. Subscription-Derived Capacity

A provider may offer execution capacity originating from a flat-fee service subscription only where the provider's contractual and technical environment permits that execution model.

The DCN protocol does not redefine third-party account rights. Offers MUST identify the execution assurance class and applicable provider constraints.

10. Settlement

Settlement conditions SHOULD be expressed against verifiable execution and contractual predicates rather than unverified self-report.

Typical lifecycle:

requirement → offer → assignment → execution → evidence → evaluation/acceptance → settlement

Actum MAY finalize the relevant Acts and monetary state transitions.

11. Cognitive Capital

Cognitive Capital is the accumulated stock of reusable, evaluated cognition and its supporting evidence, lineage, artifacts, and validated procedures.

It is not synonymous with a K-line or artifact. Those are constituent assets.

12. Attribution

Lineage MAY support attribution from later artifact reuse back to contributing episodes, experts, evaluators, compilers, data providers, and K-line authors.

Attribution policy is explicit; provenance alone does not define ownership or royalty rights.

13. Royalties

Artifact or K-line licensing MAY define execution royalties, fixed licenses, organization licenses, or public-good terms. Royalty rules SHOULD be machine-readable and bound to artifact identity.

14. Compilation Economics

Compilation converts recurring expensive cognition into cheaper implementations. A useful economic measure is expected lifetime return:

Compilation ROI = expected future savings / compilation cost

The scheduler SHOULD prioritize high-value compilation while preserving quality and governance constraints.

15. Frontier Flywheel

novel problem
   ↓
scarce expert cognition
   ↓
successful evaluated episode
   ↓
K-line
   ↓
Cognitive Compiler
   ↓
cheap reusable artifact
   ↓
expert attention moves to the next frontier

The network continuously converts scarce intelligence into abundant cognition.

16. Reputation

Reputation is contextual and locally interpreted. Actum may provide immutable evidence of claims and outcomes, but each Mind decides how those observations affect trust.

Global scalar reputation SHOULD NOT be treated as universal truth.

17. Sybil and Gaming Resistance

Economic systems SHOULD account for Sybil evaluation, benchmark gaming, wash execution, correlated evaluators, self-dealing, replay, and artificial demand generation.

Stake MAY increase economic accountability but MUST NOT substitute for semantic evidence.

18. Privacy

Zero-knowledge and confidential verification MAY allow settlement over predicates without disclosing prompts, outputs, identities, exact prices, or evaluation datasets.

Privacy mechanisms MUST remain compatible with audit and replay-prevention requirements.

19. Public Goods

The network SHOULD support cognitive capital published as a public good. Funding mechanisms MAY include grants, retroactive rewards, attribution pools, or protocol subsidies.

20. Economic Invariants

Admissibility precedes price optimization.
Provenance is not truth.
Payment is not trust.
Stake is not authority.
Market selection does not override local activation sovereignty.
Reusable cognition can have economic value independent of raw execution volume.
Lineage enables attribution but does not itself define ownership.
Compilation should move scarce cognition toward the frontier.

Distributed Cognitive Network

Volume X — Trust, Security, Authority, and Governance

Draft Specification 0.1

1. Purpose

This volume defines the security model of the DCN. The architecture assumes that cognition, external content, experts, K-lines, artifacts, markets, and remote Minds may be incorrect, compromised, malicious, stale, or simply inappropriate for the current context.

2. Separation of Concerns

K-line       = cognition
Policy       = permission rules
Authority    = concrete delegated power
Execution    = attempted action
Evidence     = support for defined claims
Attestation  = machine-verifiable claim about execution/provenance
Actum        = durable verifiable history/finality
Trust        = local interpretation

These concepts MUST NOT be collapsed.

3. Local Trust

Trust is contextual and local. A Mind may trust the same expert differently across capabilities, environments, evidence classes, and risk levels.

4. Authority

Authority is explicit, scoped, revocable, audience-bound where applicable, and attached to concrete actions or capability classes. Cognition cannot create authority by assertion.

5. Authority Non-Amplification

Every delegation, adapter, K-line, Agency, and remote execution MUST preserve equal or narrower authority unless a new grant is obtained.

6. Proposal Before Mutation

Reasoning components produce proposals. Validation and authority checks occur before authoritative state mutation or externally effectful execution.

7. Least Privilege

Agencies and components receive only capabilities and context required for their current contract. Universal tool access is discouraged.

8. Context Least Disclosure

The Runtime Host constructs capability-specific ContextSlice objects. Remote cognition MUST NOT receive the complete Mind merely because it is technically available.

9. Memory as Untrusted Data

Stored memories, retrieved K-lines, web content, documents, emails, and expert outputs are data. Imperative language inside data does not grant execution authority.

10. Cognitive Supply Chain

K-lines and artifacts are executable cognitive supply-chain content. Import requires discovery, identity/provenance inspection, evaluation, trust decision, and local activation.

Installation is not activation. Activation is not authority.

11. Evidence Graph

Evidence SHOULD be represented as a graph of claims, commitments, receipts, attestations, evaluations, and lineage rather than a single binary proof field.

Different claims require different evidence classes.

12. Verifiable Remote Execution

Where provider/model provenance matters, authenticated execution evidence such as TLS transcript commitments, provider attestations, TEEs, computation proofs, or equivalent mechanisms MAY bind provider-visible request/response properties, measured runtime properties, model identity, or computation correctness.

Such evidence MUST NOT be described as proving hidden model weights or internal server computation unless the mechanism actually establishes those claims.

13. Computation Attestation

DCN treats computation attestation as a first-class evidence dimension. The normative profile is defined in COMPUTATION_ATTESTATION.md.

A high-assurance inference may independently attest:

transport authenticity
runtime identity
model identity
computation correctness

These claims are orthogonal. A valid transport proof does not imply model identity; a runtime quote does not automatically imply that the intended model weights were loaded; a model identity commitment does not prove that a particular output was computed from a particular input; and a valid computation proof does not establish semantic truth.

The Runtime Host MUST preserve the exact proof statement, verifier identity, model/input/output commitments, numeric semantics, limitations, and verification result for any computation attestation used in admissibility or settlement.

14. Attestation Profiles

The baseline computation-attestation profiles are:

dcn.ca.transport.v1
dcn.ca.runtime.v1
dcn.ca.model.v1
dcn.ca.inference.v1
dcn.ca.composite.v1

Capability requirements MAY require one or more profiles. Missing mandatory profiles make a provider inadmissible regardless of price, latency, or claimed quality.

The reference Attestable-backed Gemma profile is attestable.gemma.v1 and is defined as an implementation profile of dcn.ca.inference.v1 only when it binds the declared Gemma model identity, input commitment, and output commitment to the proven inference relation.

15. Numeric Semantics

A proof is only meaningful relative to the arithmetic it proves. Quantization, fixed-point conversion, approximation, transformed operators, sampling semantics, or other proof-oriented changes MUST be declared.

An implementation MUST NOT represent proof of a transformed inference as proof of an unmodified higher-precision model unless an explicit equivalence proof exists.

16. Zero-Knowledge Verification

Zero-knowledge systems MAY prove inference, settlement, admissibility, or other predicates without disclosing underlying private data. Proof statements MUST be explicit about what is and is not proven.

Where zero-knowledge machine-learning proofs are used, the Evidence Graph SHOULD preserve the proof relation, verification key/reference, model commitment, input commitment, output commitment, numeric semantics, and privacy properties.

17. Actum

Actum records finalized claims, commitments, authority references, evidence references, lineage, and settlement state. It proves finalized history, not semantic truth.

For computation attestation, Actum SHOULD finalize commitments to the attestation object, verification result, proof artifact, model identity, and causal execution. Raw prompts, outputs, model weights, and large proof blobs need not be placed on-chain.

18. Replay Protection

Effectful and economic operations MUST use domain-appropriate replay protection such as idempotency keys, authority nonces, freshness challenges, proof execution bindings, or Actum nullifiers.

A computation proof valid for one execution MUST NOT be accepted for another execution unless the proof statement explicitly permits that reuse.

19. Confused Deputy

Authority MUST be bound to intended purpose and execution context. A component authorized for one goal cannot reuse that authority for unrelated work.

20. Prompt Injection

The Runtime Host MUST preserve provenance and trust classification for external content. Tool descriptions, retrieved documents, K-lines, or expert outputs cannot directly override higher-authority policy.

21. Recursive Agent Safety

Recursive Agency/K-line/remote-Mind activation requires bounded depth, resource limits, cancellation, causal tracing, and policy enforcement at each effect boundary.

22. Market Security

Market offers are untrusted advertisements until verified. Price, stake, popularity, historical volume, and a promise of future attestation cannot override minimum evidence or authority requirements.

An execution is not considered computation-attested until the required proof has been produced and independently verified.

23. Attestation Supply-Chain Security

Implementations MUST defend against proof substitution, model/input/output substitution, stale or replayed proofs, verifier-key substitution, silent numeric-semantics drift, partial proofs presented as whole-inference proofs, and composite attestations that omit failed components.

Proof-system names and provider assertions are metadata, not verification. A Runtime Host MUST execute or delegate a trusted verifier before treating a computation attestation as valid.

24. Governance

Protocol governance SHOULD distinguish:

specification evolution
schema registry
attestation profile registry
conformance suite
network economics
Actum governance
local Mind policy

No governance body should automatically control local cognition merely because it governs a shared protocol.

25. Versioning

Breaking semantic changes require explicit protocol versions. Security requirements MUST NOT be weakened through an ostensibly compatible extension.

Attestation profiles MUST version any change that alters the statement proven, trust roots, arithmetic semantics, or verifier contract.

26. Emergency Revocation

Minds and organizations SHOULD support revocation of authority, components, K-lines, artifacts, publishers, proof verifiers, verification keys, and trust roots. Revocation is locally interpreted and SHOULD preserve historical evidence.

27. Audit

A high-assurance execution SHOULD be reconstructable from goal, context commitment, capability requirement, binding, authority, execution result, evidence, computation attestations, evaluation, patch, and final state transition.

28. Security Invariants

Cognition is not authority.
Installation is not authority.
Market payment is not authority.
Authority cannot silently amplify.
Context follows least disclosure.
External content is untrusted data.
Provenance is not truth.
Evidence claims only what its mechanism establishes.
Transport, runtime, model, and computation attestations are distinct claims.
Cryptographic proof validity is not semantic task correctness.
Remote cognition cannot directly install itself into local System 1.
Local activation sovereignty is preserved.

DCN Computation Attestation Profile 0.1

This profile defines how DCN represents evidence about the computation that produced an AI result.

Core rule

Evidence MUST state exactly what it establishes. Transport provenance, runtime identity, model identity, and computation correctness are separate claims and MUST NOT be collapsed into one verified boolean.

ComputationAttestation

A ComputationAttestation records:

attestation identifier and profile;
subject execution;
claim type;
model identity commitment;
input and output commitments;
optional runtime binding;
proof system and proof reference;
verifier and verification result;
numeric semantics and privacy properties;
limitations and production time.

Baseline claim types are transport_authenticity, runtime_identity, model_identity, computation_correctness, and composite.

Baseline profiles are dcn.ca.transport.v1, dcn.ca.runtime.v1, dcn.ca.model.v1, dcn.ca.inference.v1, and dcn.ca.composite.v1.

Model identity

A model identity SHOULD bind the execution-relevant model family/variant, weight commitment, architecture commitment, quantization or numeric representation, tokenizer, inference implementation, sampling configuration, and adapters where relevant. A model name alone is not cryptographic identity.

Numeric semantics

A computation proof MUST state the arithmetic actually proven. Quantized, fixed-point, approximated, or transformed execution MUST NOT be represented as proof of a different higher-precision computation unless an explicit equivalence argument exists.

Input and output binding

A computation-correctness claim MUST bind the exact input and output covered by the proof. For autoregressive inference this SHOULD include prompt/context commitment, sampling configuration commitment, and output-token commitment. Randomness handling MUST be declared.

Verification result

Verification results are typed as valid, invalid, unsupported, or indeterminate. unsupported and indeterminate MUST NOT be promoted to valid through policy scoring.

Composition

Attestations compose as an Evidence Graph. For example an execution may carry a TLS transcript proving provider-visible request/response, a TEE quote proving runtime identity, a model commitment, and an inference proof binding input/model/output. The composition is no stronger than the statements actually established by its components.

Attestable Gemma profile

The reference implementation defines attestable.gemma.v1 for Gemma inference instrumented by Attestable. It maps to dcn.ca.inference.v1 only when returned evidence cryptographically binds the declared Gemma model identity, input commitment, and output commitment to the proven inference relation.

The adapter MUST fail closed when a required binding is absent or proof verification is invalid/unsupported. Vendor-specific proof payloads are preserved by hash/reference; DCN normalizes the claim without rewriting what the proof establishes.

Capability requirements

A capability requirement MAY require computation assurance independently of ordinary evidence classes. Admissibility filtering MUST occur before cost, latency, or quality optimization.

An expert binding records assurance profiles promised by the provider and the expected model commitment. The execution result links the evidence actually produced. A promise of attestability is not evidence.

Actum

Actum SHOULD anchor commitments to computation attestations, verification results, model identities, proof artifacts, and causal execution lineage when durable third-party verification is required. Raw prompts, outputs, weights, and proof blobs need not be on-chain; content-addressed references and commitments are sufficient.

Actum records finalized evidence claims. It does not replace the proof-system verifier and does not turn proof validity into semantic truth.

Actum Compute

Actum Compute MAY expose attestation as a market dimension, including assurance profile, proof system, expected model commitment, proving latency, and verification cost. A provider that cannot satisfy a mandatory assurance profile is inadmissible regardless of price.

Compiler Society

Attestability is a compilation target. A compiled artifact MAY carry model commitment, proof-compatible execution representation, verifier metadata, evaluation claims, and attestation profile. Such an artifact is self-verifying cognitive capital when its execution can produce independently checkable evidence without trusting the host.

Security requirements

Implementations MUST defend against proof substitution, model/input/output substitution, replay, verifier-key substitution, silent numeric-semantics drift, partial proofs presented as whole-inference proofs, and composite evidence that hides a failed component.

A conformant dcn.ca.inference.v1 implementation MUST include negative tests for wrong model commitment, wrong input commitment, wrong output commitment, modified proof, unsupported verifier, numeric-semantics mismatch, and replayed execution binding.

Verifiable cognition is claim-specific. DCN composes evidence; it never turns provenance, attestation, or cryptographic validity into semantic truth by implication.

DCN Verifiable Inference

Status

Implementation architecture 0.1. This document defines the DCN-native path from a model artifact to a computation attestation. It complements COMPUTATION_ATTESTATION.md.

Goal

DCN SHALL support independently verifiable model inference without depending on any one proving vendor. The first implementation target is a small transformer and then Gemma-family inference. Attestable MAY later plug in as one backend, but the DCN proof contract MUST remain provider-neutral.

Design principle

DCN does not prove a framework invocation such as "PyTorch ran." It proves a precisely identified computation:

(model identity, numeric semantics, input, generation semantics)
                         ↓
                 verifiable inference
                         ↓
                       output

The statement being proved MUST bind all semantics capable of changing the result.

Verifiable Inference Representation

The proof compiler uses a Verifiable Inference Representation (VIR). VIR is a deterministic tensor graph plus an immutable model manifest.

VIRModel
├── ModelManifest
│   ├── family
│   ├── variant
│   ├── architecture_commitment
│   ├── weights_commitment
│   ├── tokenizer_commitment
│   ├── numeric_semantics
│   ├── quantization
│   ├── operator_semantics
│   ├── generation_semantics
│   └── compiler_commitment
└── TensorGraph
    ├── embedding
    ├── normalization
    ├── linear / matmul
    ├── rotary position encoding
    ├── attention
    ├── nonlinear / lookup operations
    ├── residual
    └── output projection

A backend MAY lower VIR to ONNX, a native proving IR, a zkVM guest, or another proof representation, but it MUST preserve the committed semantics.

Model identity

A model name alone is not sufficient identity. DCN defines model identity as a commitment over all execution-relevant semantics:

ModelIdentity = H(
    weights,
    architecture,
    tokenizer,
    numeric semantics,
    quantization,
    operator semantics,
    generation semantics,
    compiler/lowering version
)

A proof for an INT8 or fixed-point lowering MUST NOT be represented as proof of a BF16 reference model unless an independently verifiable equivalence relation is supplied.

Proof backends

A proof backend implements the following lifecycle:

prepare(model manifest + graph)
prove(prepared model + committed input)
verify(proof + public bindings)
normalize → ComputationAttestation

The backend boundary is deliberately narrower than the Cognitive ABI. Backends produce proof artifacts; DCN verifies their bindings and converts valid results into dcn.ca.inference.v1 attestations.

Baseline backend identifiers:

dcn.proof.fixture.v1
dcn.proof.jolt-atlas.v1
dcn.proof.ezkl.v1
dcn.proof.native.v1

dcn.proof.native.v1 is reserved for a future DCN-native tensor prover.

JOLT Atlas backend

The first external proving backend SHOULD be JOLT Atlas because its public implementation operates on ONNX tensor graphs and provides transformer, nanoGPT, MiniGPT/MicroGPT, and GPT-2 prove/verify examples.

The initial DCN integration has two stages:

jolt-atlas-smoke: independently run a pinned JOLT Atlas transformer proof and verify it locally.
jolt-atlas-model: lower a DCN VIR model to the supported ONNX subset and retain a native proof artifact whose verifier result is bound into a DCN ComputationAttestation.

The Git commit of JOLT Atlas used by an execution MUST be part of the backend/verifier identity.

Gemma roadmap

Gemma support SHALL be introduced incrementally.

G0 — operator coverage

Prove isolated operators needed by Gemma: RMSNorm, linear layers, rotary embeddings, attention, nonlinear activation, residual operations, and output projection.

G1 — transformer block

Prove and verify one complete Gemma-compatible transformer block using deterministic fixed inputs.

G2 — real checkpoint block

Use a real, immutable Gemma checkpoint and the model implementation's own decoder layer. Commit the exact checkpoint revision, weights, tokenizer, exported proving graph, reference inputs and numeric semantics. Measure fixed-point drift against the reference execution and require both semantic-admission and native proof-verification gates before emitting dcn.ca.inference.v1 evidence.

The first G2 target is google/gemma-3-270m, decoder layer 0, sequence length one. G2 proves the real decoder block, not the complete autoregressive model.

G3 — one-token model forward and deterministic token selection

Prove one complete next-token logits computation across embeddings, all 18 decoder layers, final norm and the complete LM head. The G3 baseline is one monolithic proof under the explicitly committed jolt-atlas-fixed-i32-scale-12 semantics.

The complete logits vector is proved. Because the pinned JOLT Atlas backend does not expose a general proved ArgMax operator, deterministic greedy selection is recomputed outside the proof and bound to the proved logits with greedy-argmax-over-proved-logits-v1; the attestation explicitly records selection_inside_zk_proof = false.

Qualification has two independent gates: native verification establishes correctness of the fixed-point graph, while a separately recorded drift evaluation admits that graph against the committed Transformers eager FP32 reference only when NRMSE is at most 0.08, cosine similarity is at least 0.99, and the greedy token agrees. This is not a claim that FP32 execution was proved or that the two executions are bit-equivalent. See adapters/verifiable-inference/gemma-g3/README.md and its machine-readable qualification report for the exact baseline and Atlas compatibility changes.

G4 — autoregressive generation

Link token steps recursively or through a backend-supported accumulator so a single final receipt commits the prompt, complete generated output, model identity, and every generation parameter.

G5 — privacy and scale

Add private prompt/output/model modes as supported by proof systems, streaming proving, parallel layer/token proofs, recursive aggregation, and GPU acceleration.

Specialized native backend

The long-term DCN backend SHOULD avoid general CPU instruction emulation for the dominant LLM tensor workload. It SHOULD exploit specialized proof techniques for:

matrix multiplication and linear layers;
lookup-based nonlinear functions;
attention and softmax;
streaming witness generation;
layer/token partitioning;
recursive proof aggregation.

The architecture is compatible with public techniques such as lookup-centric tensor proving and specialized attention arguments, but DCN does not inherit the security assumptions of any research system merely by adopting a similar optimization.

Proof receipt

Every successful backend execution MUST be normalized to a receipt binding at least:

execution_id
backend_id
backend_version / source commitment
model_commitment
architecture_commitment
tokenizer_commitment
numeric_semantics
input_commitment
output_commitment
generation/sampling commitment
proof_system
proof commitment/reference
verifier commitment/reference
verification status
limitations

Only a locally verified valid result can satisfy mandatory computation assurance.

Actum

Actum SHOULD finalize commitments to the normalized attestation, proof artifact, verifier identity, execution identity, and settlement-relevant predicates. Large proof payloads and private inputs/outputs MAY remain content-addressed off-chain.

Actum finality does not replace native proof verification.

Self-verifying cognitive capital

The Compiler Society MAY target proof-producing artifacts. A compiled K-line implementation can therefore carry both an execution artifact and a proving representation:

KLineTemplate
      ↓
compiled cognitive artifact
      ├── executable representation
      └── verifiable representation
                 ↓
        execution + proof
                 ↓
      ComputationAttestation

This is the DCN definition of self-verifying cognitive capital.

Distributed Cognitive Network

Volume XI — Federation and Network Protocol

Draft Specification 0.1

1. Purpose

This volume defines how autonomous Minds, organizations, expert providers, K-line publishers, evaluators, and markets participate in a federated Distributed Cognitive Network without creating a single canonical global brain.

2. Federation Principle

The network shares cognition; the local Mind decides what becomes active.

Federation distributes discoverable cognitive capital and evidence. It does not distribute mandatory cognition.

3. Federated Objects

Participants MAY publish or exchange:

ComponentDescriptor
CapabilityDescriptor
KLineTemplate
KLineArtifact metadata
EvaluationClaim
Evidence references
ExpertOffer
ArtifactOffer
Acts
Semantic fingerprints
Revocation/supersession statements

Private world state and working memory are not federation primitives.

4. Discovery

Discovery SHOULD be capability-first. A Mind asks which entities can satisfy a semantic requirement rather than searching only by vendor identity.

Discovery MAY occur through registries, Actum Compute, organization directories, peer exchange, or cached catalogs.

5. Identity

Federation distinguishes authored object identity, exact content identity, and semantic similarity. Cryptographic identity MUST NOT be inferred from semantic similarity.

6. K-Line Federation

K-lines are globally shareable but not globally authoritative. A Mind may discover multiple competing K-lines for the same problem class and independently evaluate, cache, activate, fork, or reject them.

7. Artifact Distribution

Artifact distribution SHOULD include content hash, template identity, publisher, compiler lineage, dependencies, runtime target, evaluation claims, and security metadata.

8. Expert Federation

Remote experts expose semantic capabilities through Cognitive ABI descriptors and transport bindings. A2A MAY be used for autonomous peer interaction; MCP MAY be used for capability invocation.

9. Protocol Layering

Cognitive ABI   semantic contract
MCP             tool/capability transport binding
A2A             agent/Mind interaction binding
Agent Plugins   distribution/packaging
Actum Compute   economic discovery/resolution
Actum           durable verifiable history/finality

The federation protocol does not require one transport.

10. Trust Exchange

Participants exchange evidence, not mandatory trust scores. Local Minds derive trust from their own policies and observations.

11. Evaluation Federation

Evaluation claims SHOULD include protocol, subject, distribution/environment commitment, evaluator, result, evidence, and timestamp. Claims may conflict; conflict is preserved rather than erased.

12. Supersession and Revocation

Federated objects MAY be superseded or revoked by authorized publishers or trust systems. Historical objects remain addressable for lineage and audit.

13. Synchronization

Synchronization exchanges immutable or versioned objects and Acts rather than synchronizing entire mutable databases.

Minds SHOULD be able to operate offline and reconcile later.

14. Caching

Federated content MAY be cached with validity, provenance, trust, and revalidation metadata. Cache freshness is part of admissibility.

15. Organization Boundaries

Organizations MAY operate private federation domains containing private K-lines, experts, artifacts, evaluations, and trust roots while selectively interacting with the public network.

16. Cross-Mind Delegation

A Mind MAY delegate bounded work to another Mind. Delegation MUST carry explicit capability, context, authority, privacy, evidence, budget, and deadline constraints.

The receiving Mind remains autonomous and may reject the request.

17. Human Federation

Humans and organizations may participate as experts or evaluators through adapters. The protocol does not require participants to be software agents.

18. Poisoning Resistance

Minds SHOULD defend against Sybil publication, malicious K-lines, benchmark gaming, coordinated evaluations, dependency substitution, stale artifacts, and semantic-name squatting.

19. Network Partitions

Local cognition continues during partitions. Remote-dependent tasks may defer, degrade to local alternatives, or request human intervention according to policy.

20. Federation Invariants

There is no mandatory canonical K-line store.
Discovery does not imply trust.
Trust does not imply authority.
Publication does not imply local activation.
Semantic similarity does not imply identity.
Federation preserves provenance and conflicting claims.
Minds remain useful offline where local capability permits.
Private world state is not a federation requirement.
Transport protocols do not define cognitive policy.
Local Minds retain final activation decisions.

Distributed Cognitive Network

Volume XII — Reference Implementation

Implementation Blueprint 0.1

1. Purpose

This volume defines a concrete reference implementation of the specifications without making implementation choices normative for other conforming systems.

2. Reference Stack

Swift 6              mobile/native Mind shell
Rust                  Cognitive Kernel and high-assurance services
TypeScript            web/admin/plugin adapters
SurrealDB             local operational graph/world state
Kline                 reusable cognitive topology
Cognitive ABI         semantic interoperability
MCP / A2A             transport bindings
Agent Plugins         distribution
Actum Compute         capability/economic resolution
Actum                 verifiable Acts and settlement
TLS evidence adapters authenticated remote execution evidence
Computation attestation provider-neutral model/inference proof verification
ZeroK gateway         confidential predicates

3. Runtime Process Model

The reference DCN Runtime contains the Cognitive Kernel, event bus, scheduler, context assembler, K-line engine, capability resolver, Agency manager, patch engine, authority adapter, evaluator adapter, episode recorder, and Compiler Society scheduler.

4. SurrealDB Model

Core tables/graphs SHOULD include:

mind
entity
belief
observation
episode
goal
task
plan
kline_template
kline_episode
kline_artifact
capability
expert
evaluation_claim
evidence
computation_attestation
policy
authority
patch
runtime_event

Edges represent semantic relationships such as SERVES, DERIVED_FROM, EVALUATED_BY, SUPERSEDES, REQUIRES, BOUND_TO, and CONTRIBUTED_TO.

5. Cognitive Kernel Modules

The Rust kernel SHOULD expose modules for recognition, novelty, scheduling, capability resolution, execution supervision, validation, patch transactions, eventing, checkpoints, and learning queues.

No module should require direct knowledge of commercial model vendors.

6. Kline Engine

The Kline engine loads typed templates, evaluates triggers and preconditions, creates activation graphs, emits capability requirements, records actual bindings, and materializes episodes.

7. Provider Adapters

Provider-specific code lives below the Cognitive ABI boundary. Adapters map semantic execution requests to provider transports and return normalized results and evidence.

8. Actum Compute Adapter

The adapter submits capability demand, receives offers, verifies market metadata, and returns CapabilityResolution candidates. The Cognitive Kernel performs final local admissibility and selection.

9. Actum Adapter

The Actum adapter commits durable Acts and settlement transitions using commitments to private ABI objects where disclosure is unnecessary.

10. Evidence and Computation-Attestation Adapters

Evidence adapters SHOULD support multiple classes rather than hard-coding one proof system. TLSNotary-derived evidence, provider attestations, confidential-compute attestations, and zero-knowledge proofs are represented through typed evidence descriptors.

Computation attestation is a distinct provider-neutral boundary implemented by the dcn-computation-attestation crate. It verifies the DCN-level execution, model, numeric, input, output, sampling, and proof-descriptor bindings before delegating native proof verification to a provider-specific ProofVerifier implementation.

A provider integration therefore has two responsibilities:

Provider adapter
  → produce native proof + provider profile

DCN computation-attestation layer
  → verify semantic bindings
  → invoke native ProofVerifier
  → accept only VerificationStatus::Valid

The generic layer MUST fail closed for model substitution, numeric-semantics drift, input/output substitution, sampling mismatch, proof-descriptor substitution, and non-valid verifier results.

The first intended external provider profile is attestable.gemma.v1, mapping to dcn.ca.inference.v1. This profile remains a plug-in boundary until Attestable publishes or supplies an authoritative Gemma runner/verifier interface; the reference implementation MUST NOT invent or emulate proprietary proof semantics.

11. Mobile Runtime

The mobile Mind prioritizes local artifacts, compact world-state indexes, background compilation/evaluation while charging, strict context minimization, and graceful offline operation.

The mobile shell SHOULD expose user-visible controls for active Agencies, authority, remote execution, budget, privacy, and federated cognition.

12. Agent Plugin

The reference Agent Plugin exposes DCN capabilities through a small product surface rather than hundreds of internal tools. The plugin maps MCP operations to Cognitive ABI capabilities and delegates authority to the host/client authorization layer.

13. Compiler Society

Reference compiler agencies include episode clustering, topology generalization, graph minimization, rule extraction, distillation, mobile optimization, benchmark generation, and regression evaluation.

Compiler outputs are candidates until independently evaluated. Attestability MAY be an explicit compilation target, allowing a compiled artifact to produce independently verifiable execution evidence.

14. Repository Layout

spec/
schemas/
bindings/
conformance/
runtime/
  kernel/
  kline/
  agencies/
  memory/
  compiler/
adapters/
  mcp/
  a2a/
  actum/
  actum-compute/
  computation-attestation/
  evidence/
plugins/
examples/

15. Build Order

Recommended implementation sequence:

1 Cognitive ABI + conformance
2 world-state and patch engine
3 Cognitive Kernel event/scheduler core
4 Kline activation and episodes
5 local artifact execution
6 MCP/provider adapters
7 authority integration
8 computation-attestation verification boundary
9 Actum evidence/Acts
10 Actum Compute market resolution
11 Compiler Society
12 federation/A2A
13 mobile optimization

16. Minimum Viable Mind

The first useful implementation requires only:

local world state;
goals and observations;
Cognitive Kernel;
one K-line;
one local and one remote capability adapter;
patch proposal/commit;
episode recording;
Cognitive ABI conformance.

The market, proof providers, and compiler can be added without changing the programming model.

17. Testing

Testing layers include unit tests, ABI schema tests, golden traces, deterministic fake experts, patch transaction tests, authority negative tests, K-line replay, crash recovery, market adversarial tests, computation-attestation substitution tests, and compiler regression tests.

Provider-specific proof integrations MUST include independent negative verification for wrong model, input, output, numeric semantics, sampling configuration, proof payload, verifier identity/version, and replayed execution bindings.

18. Observability

Metrics SHOULD include System-1 coverage, System-2 escalation, novelty, surprise, artifact hit rate, cost, latency, energy, context size, failed authority requests, evaluation backlog, attestation verification failures, proof latency/cost, compilation gain, and K-line decay.

19. Reference Implementation Principle

The reference implementation demonstrates one way to realize the standard. Interoperability depends on Cognitive ABI and protocol conformance, not adoption of this exact stack.

Distributed Cognitive Network

Volume XIII — Whitepaper

From Scarce Intelligence to Cognitive Capital

Abstract

Modern AI is organized around increasingly capable monolithic models sold as metered inference. The Distributed Cognitive Network proposes a different architecture: a persistent local Mind coordinates a society of specialized intelligences, remembers successful organizations of cognition as K-lines, verifies external execution, and continuously compiles expensive deliberation into cheaper reusable cognitive artifacts.

The scarce resource is not tokens. It is proven problem-solving capability.

1. The Problem

A single general model is an inefficient place to concentrate every kind of cognition. Different problems benefit from different specialists, tools, deterministic systems, humans, local models, frontier models, and evidence sources. Yet current agent systems repeatedly rediscover how to compose these resources.

They consume intelligence without accumulating enough procedural cognitive capital.

2. A Society of Experts

The DCN treats any capability-producing entity as an expert. A problem is decomposed into semantic capability requirements and resolved late against admissible experts.

The system remembers which kinds of cognition worked rather than fossilizing which vendor happened to supply them.

3. K-Lines

Inspired by Minsky's K-lines, the network represents reusable organizations of cognition as typed executable graphs.

A KLineTemplate defines cognitive topology. A KLineEpisode records what actually happened. A KLineArtifact is a compiled implementation optimized for an environment.

This separation allows cognition to remain semantically stable while its implementation evolves.

4. System 1 and System 2

System 1 executes validated reusable cognition. System 2 handles novelty, ambiguity, surprise, and frontier problems.

The purpose of System 2 is not only to solve today's problem. Successful System-2 trajectories become candidates for tomorrow's System 1.

5. The Cognitive Compiler

The Compiler Society converts repeated expensive cognition into progressively cheaper forms: simplified expert graphs, smaller specialist models, local artifacts, classifiers, or deterministic rules.

Quality, authority, privacy, and evidence requirements remain constraints. Cost reduction cannot justify semantic degradation.

6. The Mind

A Mind is not an LLM. It is a persistent cognitive runtime with world state, goals, memory, authority, K-lines, artifacts, active plans, and trust policy.

The Cognitive Kernel allocates attention and decides what cognition becomes active. The network may propose cognition; the local Mind decides whether to use it.

7. Cognitive ABI

The Cognitive ABI is the stable semantic waist of the architecture. It defines observations, goals, capability requirements, bindings, executions, patches, evaluations, episodes, errors, and compilation requests independently of provider and transport.

MCP, A2A, Agent Plugins, local calls, and future protocols can all bind to the same semantics.

8. Verifiable Cognition

When model/provider identity or execution provenance matters, evidence systems can bind authenticated external interactions and execution claims. Actum records durable claims, commitments, lineage, and settlement. Zero-knowledge mechanisms can prove relevant predicates without revealing unnecessary private data.

Provenance is not truth. Evidence remains claim-specific and locally interpreted.

9. Actum Compute

Actum Compute is the economic layer beneath cognitive routing. It discovers and prices admissible capability supply: experts, artifacts, evaluation, evidence, and compute.

The Cognitive Kernel remains the routing authority for its Mind.

10. Cognitive Capital

The network's durable asset is Cognitive Capital: reusable evaluated cognition and the evidence, lineage, artifacts, and procedures that make it dependable.

A difficult problem may initially require expensive frontier intelligence. Once solved repeatedly and evaluated, its cognitive structure can become a K-line and then a cheap artifact. Expert attention is freed to move outward to the next frontier.

11. Federation Without a Global Brain

K-lines and artifacts are shareable, not mandatory. Organizations and individuals publish competing cognitive structures and evidence. Every Mind maintains its own trust view.

This avoids turning a global cognitive network into a single poisoned or centrally controlled precedent store.

12. Measuring Progress

The architecture measures more than model benchmark scores. Important metrics include System-1 coverage, total solve coverage, frontier size, novelty rate, compilation gain, artifact locality, cost per solved task, energy per solved task, reuse, decay, and failure surprise.

Progress means increasing the region of problems that can be solved reliably with inexpensive reusable cognition while preserving the ability to reopen precedent when the world changes.

13. Economics

Experts are rewarded for frontier cognition. Evaluators are rewarded for validation. Artifact authors may earn licensing or royalties. Evidence providers are rewarded for verifiability. Lineage can attribute later value back to the cognition that created it.

The long-run economic flywheel is:

scarce intelligence
      ↓
validated solution
      ↓
reusable K-line
      ↓
compiled artifact
      ↓
abundant cognition
      ↓
scarce intelligence moves to new problems

14. Why This Is Different

The DCN is not primarily a multi-agent framework, model router, marketplace, memory system, blockchain application, or orchestration library. Each of those is a subsystem or implementation technique.

The architecture is a distributed cognitive operating model in which cognition accumulates, compiles, federates, and becomes economic capital while authority and activation remain local.

15. Thesis

Artificial intelligence should not require civilization to repeatedly purchase the same reasoning forever.

A mature cognitive network should discover how problems are solved, verify those discoveries, preserve successful cognitive organization, compile it into increasingly efficient implementations, and make that accumulated capability available to future Minds.

The goal is not a single omniscient model.

The goal is a society of specialized intelligences whose successful cognition becomes shared, verifiable, reusable cognitive capital.

Canonical Architecture Diagrams

These diagrams are informative views of the normative specifications.

System architecture

graph TD
    U[User / Application] --> M[Mind]
    M --> K[Cognitive Kernel]
    K --> S1[System 1]
    K --> S2[System 2]
    S1 --> KL[Kline]
    S2 --> E[Society of Experts]
    KL --> R[Capability Requirements]
    E --> R
    R --> AC[Actum Compute]
    AC --> X[Experts / Artifacts / Humans]
    X --> EV[Evidence + Results]
    EV --> A[Actum]
    EV --> K
    K --> P[Patch Validation / Authority]
    P --> W[World Model]

Cognitive lifecycle

graph LR
    O[Observe] --> I[Interpret]
    I --> R[Recognize]
    R --> D{Known and admissible?}
    D -->|Yes| S1[System 1]
    D -->|No| S2[System 2]
    S1 --> V[Validate]
    S2 --> V
    V --> L[Learn]
    L --> C[Compile]
    C --> S1

K-line object model

graph TD
    T[KLineTemplate<br/>semantic cognitive topology]
    T --> E1[KLineEpisode<br/>actual execution]
    T --> A1[KLineArtifact<br/>compiled implementation]
    E1 --> EC[Evaluation Claims]
    A1 --> EC
    EC --> P[Promotion / Supersession]
    P --> CC[Cognitive Capital]

Stable waist

graph TD
    TOP[Kline / Apps / Agencies / Compiler Society]
    TOP --> ABI[Cognitive ABI]
    ABI --> MCP[MCP]
    ABI --> A2A[A2A]
    ABI --> LOCAL[Local Calls]
    ABI --> MARKET[Actum Compute]
    MARKET --> PROVIDERS[Experts / Artifacts]
    PROVIDERS --> EVIDENCE[Evidence Systems]
    EVIDENCE --> ACTUM[Actum]

Authority boundary

graph LR
    C[Cognition] --> PP[PatchProposal]
    PP --> V[Validation]
    V --> AU[Authority Check]
    AU -->|Allow| COMMIT[Commit / External Effect]
    AU -->|Deny| REJECT[Reject]

Economic flywheel

graph LR
    N[Novel Problem] --> EX[Scarce Expert Cognition]
    EX --> EP[Successful Episode]
    EP --> KL[K-line]
    KL --> CP[Compiler Society]
    CP --> AR[Cheap Artifact]
    AR --> RE[Mass Reuse]
    RE --> FRONTIER[Expert Attention Moves to Frontier]
    FRONTIER --> N

Specification Map

This appendix identifies the canonical home of the major DCN concepts and prevents later volumes from silently redefining them.

Concept	Canonical home	Related volumes
Architectural invariants	Architectural Principles	all
Mind and system boundaries	Volume I	V, X, XI
KLineTemplate / Episode / Artifact	Volume II	VI, VII, IX
CapabilityRequirement	Volume II + Cognitive ABI schema	III, VII, VIII
Actum Compute	Volume III	IX, XII
Execution/evaluation/promotion Acts	Volume IV	IX, X
Cognitive Kernel	Volume V	VII, VIII, XII
Agencies and PatchProposal	Volume V	VII, VIII
World model and memory	Volume V	VIII, XII
Compiler Society	Volume VI	IX, XII
Cognitive ABI	Volume VII + executable schemas	VIII–XII
Computation attestation	Computation Attestation Profile + schema	VII, X, XII
Verifiable inference / proof backends	Verifiable Inference + backend contract	VI, X, XII
Programming model	Volume VIII	XII
Cognitive Capital economics	Volume IX	I, VI, XIII
Trust, authority, security	Volume X	IV, VII, XI
Federation	Volume XI	III, VII, X
Reference implementation	Volume XII	all implementation-facing volumes
Public synthesis	Volume XIII	all

Normative precedence

When prose conflicts, the following order SHOULD guide editorial resolution:

Architectural Principles for cross-cutting invariants.
The volume designated as canonical home above for concept semantics.
Cognitive ABI and computation-attestation machine-readable schemas for wire structure.
Later implementation guidance only where it does not redefine higher-level semantics.

A newer document does not automatically supersede an earlier canonical definition unless it explicitly records that change.

Capability Atlas Datasets and Models

Informative. This appendix records the datasets behind the Capability Atlas, the gate each one sits behind, and the first models DCN serves from them. Every served model is an advisory capability: capability != authority. An output is evidence for a clinician or a DG authority decision, never an authorization to act.

Open Atlas Explore to browse the Atlas: domains, capabilities, datasets and their gates.

Sources of truth:

dataset manifest: capability-atlas/datasets/datasets-v1.yaml
exact downloaded bytes: capability-atlas/datasets/datasets-v1.lock.json
model artifacts: capability-atlas/models/*.v1.json
Atlas node records: capability-atlas/nodes/*.json
served components: adapters/atlas-models (dcn-atlas-models-server)

Datasets

Dataset	Domains	Gate	Status
NHANES 2017–March 2020 (CDC/NCHS), 16 files	cardiovascular, metabolic, renal, mental health, primary care	open	downloaded, hash-locked
UCI Breast Cancer Wisconsin (Diagnostic)	oncology	open (CC BY 4.0)	downloaded, hash-locked
UCI Heart Disease	cardiovascular	open (CC BY 4.0)	downloaded, benchmark only
UCI Chronic Kidney Disease	renal	open (CC BY 4.0)	downloaded, sanity check only
Synthea FHIR R4	contract fixtures	open (generated)	not generated; needs Java, fixtures only
MIMIC-IV	renal, cardiovascular, metabolic	credentialed (PhysioNet DUA + CITI)	gate closed
UK Biobank	all six domains	application + fees	gate closed
Framingham (BioLINCC)	cardiovascular	application + IRB	gate closed
SEER Research	oncology	registration + DUA	gate closed
Swedish national registers	all six domains	ethics approval + register holder	gate closed
ProvidEHR / TakeCare records	primary care, CV, metabolic, renal	patient data: lawful basis, DPIA	gate closed
Metabolog via OpenBody contract	metabolic	partner: OpenBody #44 acceptance + consent	gate closed

Only open datasets are fetched, by capability-atlas/datasets/fetch_open_datasets.py. Downloads are cached outside version control. The lock file binds each model to the exact bytes it was trained on.

Held by sibling repositories

About 150 GB of further health, wearable and discovery data already sits in sibling repositories. The manifest's held_elsewhere section records each owner, location, licence and any existing models. DCN references these data by owner and does not duplicate them. A DCN node may train on one only after the owner publishes a hash-locked export and the licence permits the use.

Dataset	Owner	Size
Open CGM cohorts (AZT1D, HUPA-UCM, T1D-UOM, Shanghai, UC_HT)	InVivo EHM	2.7 GB
D1NAMO; BIG IDEAs	InVivo ECG2BG	9.5 GB; 5.1 GB
PTB-XL, MIT-BIH, Icentia11k	InVivo BioSignalFM	2.5 GB
NHANES 1999–2018 with mortality	InVivo EHM	234 MB
WESAD; StudentLife	BrIAn / InnerState	16 GB; 2.8 GB
ChEMBL 36, IEDB, PepBDB, LINCS	DiscoveryLab	62 GB
Food-101, FoodX-251, Nutrition5k	InVivo food-model	14 GB

Open licence questions for the owners:

PhysioCGM (23 GB). Its licence is no-derivatives. EHM excludes it from training, but ECG2BG trains on it.
WESAD, CGMacros and WearableQA. These are non-commercial. That rules them out of any commercial DCN capability.

Contracts named in the current workstream have these data states:

OpenBody #44 (whole-person state). A PR with synthetic fixtures only; the contract is not accepted.
ProvidEHR #600 and TakeCare. Synthetic encounters, plus sanitized digests from one test-tenant read; no clinical content.
Metabolog #1131 and #1145. Consumers pinned in OpenBody's mapping; no real cohort has been projected yet.
Kline #181–#190, Memorex and OpenMind. Synthetic only.

Served components

Component	Kind	Data	Holdout AUROC (95% CI)	Sens / Spec at threshold
`deterministic.ckd_epi_2021`	published equation	none	n/a	n/a
`deterministic.phq9`	published scoring	none	n/a	n/a
`metabolic.dysglycemia_screen`	logistic regression, 7 inputs	NHANES, n=5,696	0.779 (0.729–0.819)	0.87 / 0.57
`renal.ckd_screen`	logistic regression, 7 inputs	NHANES, n=6,327	0.753 (0.719–0.787)	0.80 / 0.57
`cardiovascular.hypertension_screen`	logistic regression, 7 inputs	NHANES, n=4,390	0.739 (0.700–0.773)	0.80 / 0.57
`oncology.breast_fna_malignancy`	logistic regression, 6 inputs	UCI WDBC, n=569	0.982 (0.959–0.999)	0.92 / 0.99

Label definitions:

Dysglycemia screen. HbA1c ≥ 6.5% in adults aged 20–79 never told they have diabetes.
CKD screen. CKD-EPI 2021 eGFR < 60 or UACR ≥ 30 mg/g on a single measurement, in adults not told of weak or failing kidneys. The label is derived with the same CKD-EPI node that DCN serves.
Hypertension screen. Mean of three oscillometric readings ≥ 140/90 mmHg in adults never told they have hypertension. The screen prioritises home-BP referral (service.home_bp, NICE NG136); it does not replace BP measurement.
Breast FNA classifier. A research demonstrator only. It is prohibited for clinical use.

Limitations, which travel in every artifact's context_of_use:

The NHANES models are cross-sectional prevalence screens, not prognostic risk models.
They were trained unweighted on a complex survey sample. The survey-weighted holdout AUROC is reported alongside.
No model has external validation, and none is validated for Swedish use.
The Atlas evidence status is therefore vendor_claim, not independently_evaluated.

Invocation contract

The host binds loopback only (DCN_ATLAS_MODELS_LISTEN, default 127.0.0.1:8095):

GET  /v1/atlas/components               ComponentDescriptor[] with Atlas metadata
GET  /v1/atlas/components/{id}          one descriptor
POST /v1/atlas/components/{id}/invoke   dcn.atlas-model-result.v1

Each result carries the following fields:

model_commitment: the SHA-256 of the exact artifact bytes compiled into the binary.
input_commitment: the SHA-256 of the canonical input.
authority: "advisory".
The output.

Inputs are fail-closed. The host rejects any of the following instead of extrapolating:

missing fields
unknown fields
non-finite numbers
non-binary values for binary fields
values outside the range seen in training

Reproduction

python3 capability-atlas/datasets/fetch_open_datasets.py
python3 capability-atlas/models/train_atlas_models.py
python3 capability-atlas/models/build_atlas_nodes.py --check
cargo test --manifest-path adapters/atlas-models/Cargo.toml
cargo run --manifest-path adapters/atlas-models/Cargo.toml --bin dcn-atlas-models-server

cargo test replays golden vectors, so the Rust evaluator must reproduce the scikit-learn probabilities to within 1e-9.

Data processing

Every Atlas node, dataset and set of consumption terms carries a dcn.atlas-processing.v1 facet (DCN #83). It records:

where data is processed and stored, as a jurisdiction (ISO country code, EU_EEA or unknown) plus an execution class (local, hospital edge, attested EU CFI, provider domain, public cloud)
retention and who can see plaintext
for datasets, whether the data is personal and where it originates
every transfer out of the EU/EEA, with its legal mechanism

Each location is claimed until an attestation reference makes it verified, and a claim never satisfies a verified requirement (#41). Personal data processed outside the EU/EEA without a recorded transfer is rejected.

Today every connected model and every held dataset is processed on the local machine in Sweden. That is still a claim, since no attestation of the location exists yet. Closed-gate datasets are not_processed.

Schema: capability-atlas/schema/processing.schema.json. Dataset facets: capability-atlas/datasets/processing-v1.yaml.

Selection enforces it before ranking (#85). A consumer states a hashable ProcessingRequirement covering:

allowed residency (any, EU/EEA, or named jurisdictions)
whether locations must be verified
whether provider plaintext is forbidden
maximum retention
whether third-country transfers are allowed

Every offer or route is admitted or rejected against it before price is considered, with a reason. The requirement hash is recorded in the selection. A missing or unknown facet fails closed, a claimed location never meets a verified requirement, and fallback re-applies the same requirement, so it can never downgrade to a non-EU route.

Under the default EU healthcare requirement, only routes whose retention is recorded qualify (today, OpenAI EU with zero data retention, and local self-hosting). Azure EU, Bedrock Stockholm and Corti EU are refused until their retention terms are recorded, because unknown retention fails closed.

In Atlas Explore, Processing view colours the whole Atlas by processing location, and the EU/EEA-only, verified-only and no-provider-plaintext filters hide whatever does not qualify, with a count of what was hidden and why.

Numeric relation

The served models compute in one shared no_std core, adapters/atlas-eval (#86), under the profile dcn.atlas-numeric.ieee754-binary64+libm-0.2.16.v1. That means IEEE binary64 arithmetic, plus the pure-Rust libm crate at a pinned version for exp, log and pow, and never a platform maths library. The host and any proof guest therefore compute bit-identical results. The core's golden bit patterns hold on macOS arm64 and Linux arm64 with glibc.

Every descriptor and result carries a relation_commitment, which binds the model bytes to this numeric profile and core version. That commitment is what a computation proof will attest to (#82).

Switching from platform libm (which differs by up to 1 ulp between platforms) to the core changes no decision. capability-atlas/models/numeric-equivalence-v1.json records the comparison:

Logistic screens: maximum probability difference of 1.8×10⁻¹⁵ over 200,000 samples per model, with no threshold flips.
CKD-EPI 2021: maximum eGFR difference of 8.5×10⁻¹⁴ over 370,326 grid points, with no GFR-category flips.

Computation proofs

All six deterministic nodes have a verified RISC Zero 3.0.5 proof of one example invocation (#87); see capability-atlas/proofs/qualification-v1.json. The guest runs the same dcn-atlas-eval core as the server and hashes the model artifact inside the zkVM. It commits:

the model commitment and relation commitment
a salted input commitment
the exact output bits, which are bit-identical to the served result

Inputs outside the admitted ranges produce a proven rejection. Verifying a receipt takes 15–64 ms and needs only the receipt and the pinned guest image id. Proving takes 20–26 s for CKD-EPI and PHQ-9 and 1.5–3.5 min for the logistic screens. These proofs establish computation correctness only: not clinical validity, not authority, and not yet input hiding (#89).

Consumption terms

The conditions for consuming a capability are recorded separately from the capability itself, as dcn.atlas-consumption-terms.v1 declarations (DCN #53):

price and settlement
capacity
licence scope, retention and training rights
jurisdiction
credential prerequisites
privacy
delivery evidence

The rules:

Stable contract identity. Terms bind to a stable contract_digest over the capability and its input/output schemas, so several providers can compete on terms for the same contract. Each set of terms has its own terms_id.
Monotonic revisions. Revisions only move forward, and expired terms are refused.
No authority or evidence. Terms can never carry authority, lifecycle or evidence.
Loss-explicit x403 projection. Terms project to x403 with a list of every field the projection omits.
x403 discoveries enter as DISCOVERED. An external resource first seen through x403 is recorded as DISCOVERED, with its advertised claims kept as untrusted data.

Schema: capability-atlas/schema/consumption-terms.schema.json. Fixtures: capability-atlas/terms/fixtures. Semantics: adapters/atlas-models/src/terms.rs.

Gates to open next

Each gate below unlocks something specific, and none can be opened by an agent:

Remote exposure. Needs a governed gateway, with an owner, that adds authentication and destination-bound egress authority (DCN #44–#47, the Kline gateway).
Prognostic models. Need UK Biobank or Framingham access.
Swedish context-of-use validation. Needs register ethics approval.
Real-patient invocation. Needs acceptance of the ProvidEHR #600 and OpenBody #44 contracts, plus a DPIA.
MIMIC-IV inpatient models. Need a named credentialed researcher.

Keyboard shortcuts

Distributed Cognitive Network

[ Coverage_{S1}(D)

[ Coverage_{Total}(D)

[ Frontier(D)

[ \Pi_

[ \pi^*