Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

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.