# cnos
## A Recurrent Coherence System
### Git as the Lowest Durable Substrate

**Status:** Draft
**Version:** 1.0.0
**Author(s):** usurobor + coherent agents
**Audience:** designers, implementers, operators, researchers, and coherent agents

---

## Abstract

Most software systems begin from artifacts:
a repository, a service, a protocol, a language model, a deployment topology.

cnos begins from something more primitive:

> **coherence**

A coherent system minimizes the gap between:
- what it models,
- and what reality actually is.

This is not an aesthetic claim.
It is an operational one.

From that first principle, cnos unfolds:

- **CAP** provides the atomic move: act on the world (**MCA**) or update the model (**MCI**), with bias toward action when action is possible.
- **MCP** names the best current picture of reality and system state.
- **CMP** is the pass that constructs or refreshes that picture.
- **CLP** is the reflective loop that scores pattern, relation, and exit, then patches the weakest axis.
- **CAA** defines what a coherent agent is structurally.
- **CAR** ensures cognition is local, versioned, installable, and present at wake-up.
- **AGENT-RUNTIME** governs action, capability, recovery, and projection.
- **TRACEABILITY** makes the state of mind, body, and sensors reconstructable from files alone.
- **CDD** applies the same coherence law to the evolution of cnos itself.

Git remains central, but no longer as the whole thesis.

Git is the **lowest durable substrate**:
the layer where coherent articulations become persistent, cloneable, signed, versioned, and mergeable.
It is not the source of coherence.
It is one of its most durable articulations.

This whitepaper argues that cnos is best understood not as:
- an agent framework,
- or a protocol with some tooling,
- or a package system for prompt assets,

but as:

> **a recurrent coherence system**

in which doctrine, documents, packages, runtime modules, repositories, traces, releases, and agents are all articulations of the same coherence principle at different scales.

---

## 1. The Problem with the Current Framing of AI Systems

The dominant framing for AI systems is still wrong.

It says:
- an LLM is the intelligence,
- tools make it useful,
- memory makes it durable,
- orchestration makes it autonomous.

This produces systems that are often:
- stateless in essence,
- fragile in operation,
- difficult to audit,
- dependent on centralized services,
- and incoherent across their own layers.

The failure is deeper than missing features.
It is a failure of **organizing principle**.

If the system is not organized around coherence, it drifts into:
- hidden assumptions,
- mismatched docs and code,
- silent degradation,
- accidental authority,
- and local optimizations that fracture the whole.

The question is not:
> "How do we make agents more capable?"

The deeper question is:
> **How do we build systems that remain themselves while sensing, acting, learning, and evolving?**

That is the coherence question.

---

## 2. First Principle: Coherence Is Primary

There is always a possible gap between:

- **model** — what the system believes, encodes, predicts, or assumes
- **reality** — what the world, runtime, operator, environment, or peer network actually is

That gap is the source of incoherence.

The first principle of cnos is the agent-form of the Free Energy Principle:

> **A coherent system minimizes the gap between model and reality.**

This is not a claim about perfect certainty.
It is a claim about continuous adaptation.

A coherent system:
- senses,
- compares,
- acts or learns,
- reviews the result,
- and repeats.

It does not seek static equilibrium.
It seeks **stable adaptation without loss of identity**.

---

## 3. CAP: The Atomic Dynamic

The first operational law is **CAP**.

When a gap is detected, there are only two coherent moves:

### 3.1 MCA — Model-Constrained Action
Change the world so it more closely matches the model.

Examples:
- apply the patch
- send the message
- create the branch
- update the repo
- ask the missing question
- surface the concern

### 3.2 MCI — Model-Corrective Inference
Change the model so it more closely matches the world.

Examples:
- revise the assumption
- update the design
- change the document
- alter the plan
- narrow the claim
- admit the previous articulation was wrong

### 3.3 Priority Rule
**MCA first when action is possible.**

If the system can coherently act, it should act.
If action is blocked or the model itself is wrong, it should learn.
If both are needed, it should act and then learn.

So the atomic dynamic of cnos is:

> **Gap → MCA or MCI → MCA first**

This is the smallest coherent move.

Everything else in the system exists to:
- make the gap visible,
- make the move governed,
- make the result reviewable,
- and make the next move clearer.

---

## 4. The Triad: α, β, γ

Coherence is not one-dimensional.

It appears through three irreducible axes.

### 4.1 α — Articulation / Pattern
The articulated substance of the system:
- doctrine
- specs
- code
- packages
- traces
- tests
- releases
- agents

α asks:
- is the pattern internally consistent?
- are the terms stable?
- do the pieces fit together as one form?

### 4.2 β — Relation
The graph of relations among the articulations:
- references
- dependencies
- constraints
- package overlays
- operator understanding
- runtime/doc alignment
- protocol/runtime agreement

β asks:
- do these articulations reveal one system or many fragments?
- do the layers agree?
- is the same thing being said at different scales?

### 4.3 γ — Evolution / Exit
The process that moves the system:
- review
- release
- migration
- observation
- runtime control loops
- repair
- development method

γ asks:
- what is the next coherent move?
- can the system evolve without losing itself?
- does today's fix make tomorrow more coherent?

These are not separate systems.
They are three descriptions of one coherent whole.

---

## 5. MCP and CMP

Before the system acts, it must see.

### 5.1 MCP — Most Coherent Picture
The **Most Coherent Picture** is the best current picture the system can form of:
- itself,
- its world,
- its constraints,
- its relationships,
- its likely exits.

It is not omniscience.
It is the best currently available, coherence-weighted picture.

### 5.2 CMP — Coherence Mapping Pass
The **Coherence Mapping Pass** is the operation that constructs or refreshes the MCP.

It asks:
- which articulations are relevant?
- how do they relate?
- where is the largest or weakest incoherence?
- what is the real gap?
- what can be acted on, and what must be re-modeled?

CMP is the epistemic phase before CAP moves.

### 5.3 The Core Coherence Algorithm
The recurrent algorithm of cnos is:

> **CMP → CAP (MCA/MCI) → CLP → update articulations → CMP**

This is not just the logic of one agent.
It is the logic of the whole system.

---

## 6. CLP: Reflective Law

If CAP gives the move, **CLP** gives the reflection.

CLP:
1. seeds the gap
2. reflects on the actual structure of the problem
3. scores α / β / γ
4. patches the weakest axis
5. repeats until coherent enough to proceed

CLP exists because movement is not enough.
The system must also ask:
- was this the right move?
- did it reduce the right incoherence?
- what got clearer?
- what future path was opened or closed?

So:

- **CMP** builds the picture
- **CAP** chooses the move
- **CLP** judges the move against the picture

---

## 7. Articulations of Coherence

Not everything in cnos is an agent.
But everything important is an articulation of coherence.

### 7.1 Doctrinal articulations
These define first principles and boundaries:
- FOUNDATIONS
- COHERENCE
- CAP
- CA-Conduct
- CBP
- AGENT-OPS

### 7.2 Architectural articulations
These define structural form:
- CAA — what a coherent agent is
- AGENT-RUNTIME — how it executes (including CN Shell, scheduler, and output plane separation)
- CAR — how cognition arrives locally
- TRACEABILITY — how the system explains itself
- SECURITY-MODEL — trust and authority boundaries

### 7.3 Skill articulations
These define executable local procedures:
- code
- document
- release
- cdd
- domain skills
- ops skills

### 7.4 Runtime articulations
These are operational expressions:
- package resolver
- CN Shell
- traces
- readiness projections
- receipts
- projection markers
- recovery checkpoints

### 7.5 Package articulations
These are distributable cognitive units:
- `cnos.core` — doctrine, mindsets, core skills
- `cnos.eng` — engineering skills
- `cnos.pm` — PM skills

### 7.6 Repository articulations
These are durable software encodings:
- docs
- code
- plans
- lockfiles
- tests
- release notes
- changelogs

### 7.7 Agent articulations
A coherent agent is a special articulation because it has:
- a self-model
- a bounded world-model
- the ability to choose MCA or MCI
- the ability to execute, learn, and review

### 7.8 Process articulations
These are evolutionary mechanisms:
- CDD
- release
- migration
- trace review
- package restore
- observation and repair

---

## 8. cnos as a Recurrent Coherence System

cnos is not a static stack.
It is a recurrent system in which coherent articulations:
- generate one another,
- constrain one another,
- package one another,
- execute one another,
- observe one another,
- and repair one another.

This recurrence appears at multiple scales.

### 8.1 Agent scale
One agent cycle:
- forms an MCP
- chooses MCA or MCI
- emits a proposal
- runtime executes under policy
- traces and receipts are emitted
- the next cycle begins from the updated articulated state

### 8.2 Development scale
One development cycle:
- identifies a gap
- writes design and plan
- tests the invariants
- changes code/docs/runtime
- releases a measured coherence delta
- observes the result
- begins again

### 8.3 Ecosystem scale
Across the system:
- doctrine shapes architecture
- architecture shapes runtime
- runtime shapes packages
- packages shape wake-up cognition
- agents act through the runtime
- traces explain the runtime
- releases record the movement
- docs keep the graph legible

This is why cnos is best understood as a **coherence system**, not merely a repository or protocol.

---

## 9. The Coherent Agent as a Special Case

A coherent agent is one articulation inside the larger coherence system.

Its distinctive property is **agency**.

### 9.1 What makes an articulation an agent
It can:
- form an MCP
- detect a gap
- choose MCA or MCI
- execute a bounded move
- review the result
- continue the loop

### 9.2 What a coherent agent is
A coherent agent is:

> **an articulation of coherence that can sense, compare, choose, act or learn, and remain itself while evolving.**

This is what `CAA.md` specifies at the structural level.

---

## 10. Doctrine, Mindsets, Skills

The runtime architecture makes an important distinction that follows directly from the coherence hierarchy.

### 10.1 Doctrine
Always-on, constitutive, non-competitive.

Doctrine defines:
- first principles
- review law
- conduct
- runtime grammar

It says what the system is, what it values, and how it is allowed to speak.

### 10.2 Mindsets
Always-on, orienting, deterministic.

Mindsets shape:
- style
- craft
- role
- emphasis
- cognitive stance

### 10.3 Skills
Bounded, selected, instrumental.

Skills are situational amplifiers.

They are not identity.
They are not doctrine.
They are not the ground.

If doctrine competes with task skills, the architecture is already confused.

---

## 11. Runtime as Coherent Body

The runtime is the body through which coherence becomes governed action.

### 11.1 Direct I/O boundary
The agent's direct I/O is bounded:
- `state/input.md` — inbound message and packed context
- `state/output.md` — agent response, coordination ops, typed capability ops

This preserves the separation between:
- reasoning
- execution
- mutation
- audit

### 11.2 CN Shell
The capability runtime that mediates between the agent and the world:
- the agent proposes typed ops in its output
- CN Shell validates against policy, executes within budget, records receipts, and feeds evidence back
- no in-call tool loop: the runtime governs execution post-call
- receipts for every mutation
- crash recovery via idempotent op replay

### 11.3 Observe before effect
The runtime enforces "sense before act" via the N-pass bind loop:
- **Observe pass**: agent requests observe ops → runtime gathers evidence, defers effects
- **Effect pass**: agent proposes effect ops → runtime executes governed effects
- **Terminal pass**: no ops → final projection
- bounded by `max_passes`, `max_total_ops`, `max_total_artifact_bytes`
- explicit evidence via receipts and artifacts at each pass

This is CAP made operational.

### 11.4 Output Plane Separation
The runtime enforces a strict boundary between:
- **control plane** — frontmatter, coordination ops, typed `ops:` manifest
- **presentation plane** — human-facing text projected to sinks (Telegram, Discord, audit file, conversation store)

Control-plane syntax must never leak into presentation sinks.
Presentation content must never alter control flow.

### 11.5 Traceability
The runtime must not merely act.
It must explain itself:
- boot readiness progression
- state transitions with reasons
- readiness projections
- receipts for all effects
- event logs and evidence artifacts

The body must be intelligible.

---

## 12. Packages as Coherent Substrate

Packages are not just distribution mechanics.

They are how cognition becomes:
- local
- versioned
- installable
- reproducible
- present at wake-up

Without them:
- doctrine can go missing
- mindsets become accidental
- skills become checkout-dependent
- wake-up becomes nondeterministic

So the package system is not ancillary.
It is part of the coherence substrate.

---

## 13. Repository as Lowest Durable Articulation

The repository matters deeply, but it is not the top-level principle.

The repository is:

> **the lowest durable software articulation of the coherence system**

It is where coherence becomes:
- cloneable
- signed
- diffable
- mergeable
- versioned
- auditable
- distributable

This is where the old CN whitepaper remains exactly right:
Git is a uniquely strong substrate for:
- durable history
- distributed authorship
- offline-first operation
- cryptographic integrity
- mergeable change

But in the fuller cnos view:

> **Git is not the source of coherence.
> It is the lowest durable substrate through which coherence is articulated.**

That is why the repository is not "just code."
It contains:
- doctrine
- specs
- plans
- tests
- package manifests
- changelogs
- releases
- traces of coherence deltas

The repo is the durable software body of the system.

---

## 14. CDD as γ at the Development Scale

CDD is not the whole coherence system.
CDD is one expression of γ.

Specifically:

> **CDD is γ for evolving cnos itself.**

CDD applies the same law to development:
- identify the gap
- perform CMP
- choose MCA or MCI
- write the design
- plan the move
- derive the tests
- implement
- release
- observe the coherence delta
- repeat

This is why a release is not just a bundle of features.

A release is:
- a measured coherence delta,
- with features as the user-visible articulation of that movement.

---

## 15. Failure Modes

A coherence system must know how it can deform.

### 15.1 Doctrinal failure
- first principles missing
- doctrine optionalized
- contradictory doctrine

### 15.2 Architectural failure
- runtime and docs disagree
- package model and wake-up disagree
- doctrine competes with skills
- setup story and security story diverge

### 15.3 Runtime failure
- hidden side effects
- no receipts
- no recovery
- transitions without reasons
- control-plane syntax leaking into presentation sinks

### 15.4 Package failure
- missing core cognition
- source/build drift
- non-local wake-up dependency
- unresolved or stale installed substrate

### 15.5 Process failure
- code before design
- release before coherence
- green CI mistaken for convergence
- no explicit coherence debt

### 15.6 Agent failure
- action before sensing
- MCI when MCA is possible
- no review
- no stable self-model

A coherent system must design against these, not merely notice them after the fact.

---

## 16. The Coherence Gradient

cnos evolves by moving through coherence space.

This does not mean:
- static perfection
- no regressions
- no tradeoffs
- one final peak

It means:
- every cycle should produce a coherence delta
- every release should reduce a named incoherence
- every articulation should fit the graph more truthfully than before

### 16.1 MCP at every scale
At every scale, the same questions apply:
- what is the current MCP?
- what is the weakest incoherence?
- what move reduces it?
- what changed after the move?

### 16.2 Milestones
A release is not the destination.
It is a milestone on the coherence gradient.

---

## 17. Relationship to Other Documents

### Doctrine / Why
- `docs/alpha/doctrine/FOUNDATIONS.md`
- `CAP.md`
- `COHERENCE.md`
- `CA-CONDUCT.md`
- `CBP.md`
- `AGENT-OPS.md`

### Agent architecture / What the coherent agent is
- `docs/alpha/agent-runtime/CAA.md`

### Runtime embodiment / How it runs
- `docs/alpha/agent-runtime/AGENT-RUNTIME.md`

### Cognitive substrate / How cognition arrives locally
- `docs/alpha/cognitive-substrate/CAR.md`

### Traceability / How the system explains itself
- `docs/alpha/security/TRACEABILITY.md`

### Development method / How cnos evolves coherently
- `docs/gamma/cdd/CDD.md`

This document sits above them:
- not to replace them
- but to define the meta-system they all belong to

---

## 18. Conclusion

cnos is not best understood as:
- an agent framework,
- a package system,
- a protocol,
- a repo,
- or a collection of helpful docs.

It is best understood as:

> **a recurrent coherence system**

in which doctrine, architecture, runtime, packages, repository, release, and agents are all articulations of coherence at different scales.

Coherence is primary.
CAP gives the atomic move.
CMP builds the picture.
CLP judges the move.
CAA defines the coherent agent.
CDD applies the same law to the system's own evolution.
Git remains the lowest durable substrate.

The repository is the current lowest durable articulation.

The system is the recurrence above it.
