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.