---
title: "Executable Coherence: CTB as the Skill Language for CN Agents"
version: v0.1.0
status: DRAFT
author: usurobor (aka Axiom) (human & AI)
date: 2026-02-04
companion-to: WHITEPAPER v2.0.3
---

# Executable Coherence

## CTB as the Skill Language for CN Agents

Status: v0.1.0 (DRAFT)
Author(s): usurobor (aka Axiom) (human & AI)
Date: 2026-02-04
Companion to: WHITEPAPER v2.0.3 [1]

---

## 0. Abstract

The WHITEPAPER [1] establishes git as the substrate for agent coordination. It specifies how agents communicate (threads), how they identify (signed commits), and how they discover peers (cn.json). What it does not specify is how agents verify each other's behavior.

Today, agent skills are Markdown documents — prose specifications that agents interpret through their context windows. Two agents reading the same skill can reasonably disagree about what to do in an edge case. Coherence is claimed, not computed.

This paper argues:

> **If skills are programs, coherence is computable.
> If coherence is computable, trust is mechanizable.
> CTB is the language that makes this possible.**

C-Triplebar (CTB) [2] is a pure, deterministic, expression-oriented functional language whose core data structure — the triadic term [L|C|R] — is the same shape as the TSC framework [3] that CN uses to measure coherence. This is not a coincidence. It is the design.

This paper describes the architecture for expressing agent skills as CTB programs, the properties this unlocks, and the implementation path from current state to executable coherence.

### 0.0 At a glance

What this is: an architectural vision for writing agent skills in CTB — a pure functional language where programs produce effect descriptions as data, and platform-specific runtimes execute them.

What it enables:
- verifiable skill behavior (two agents, same input, same output — guaranteed),
- computable coherence (TSC scores as deterministic functions, not subjective grades),
- trustless cross-agent coordination (verify behavior, not just signatures),
- platform-independent skills with platform-specific runtimes.

What it requires:
- a CTB interpreter (reference implementation),
- effect encoding conventions (a schema for skill outputs),
- a runtime bridge (CTB output tris to platform-native operations).

---

## 1. The Problem: Skills as Prose

In cnos [4], skills are defined as Markdown files with three sections:

- TERMS — preconditions and definitions
- INPUTS — what the skill receives
- EFFECTS — what the skill produces

This structure is clear and human-readable. It is also ambiguous by nature.

Consider the daily-routine skill: it specifies "create the day's directory under `memory/`" — but what happens if the directory already exists? What if the date format differs between timezones? What if the prior day's reflection is missing?

The Markdown spec leaves these cases to agent interpretation. An agent with a large context window might handle them. A smaller model might not. The behavior diverges invisibly, because there is no way to test whether two agents agree on the same spec without running both and comparing outputs.

This is not a documentation problem. It is an expressiveness problem. Natural language is inherently ambiguous. Formal languages are not.

### 1.1 The Haskell precedent

Haskell solved this problem for general-purpose programming decades ago. Haskell is pure — no side effects in the language. Programs produce descriptions of effects as data structures. The runtime interprets those descriptions and performs the actual IO.

A Haskell program does not "write a file." It returns a value that says "write this content to this path." The function is pure, testable, and deterministic. The runtime is the only place where effects happen.

This architecture separates what to do (the pure logic) from how to do it (the platform-specific runtime). The logic is portable and verifiable. The runtime is swappable.

CTB has the same shape available — and a structural advantage Haskell does not: its core data type is triadic, matching the framework agents already use to measure coherence.

---

## 2. The Insight: TERMS / INPUTS / EFFECTS Is Already [L|C|R]

The cnos skill format defines three sections: TERMS, INPUTS, EFFECTS.
The TSC framework [3] defines three axes: α (PATTERN), β (RELATION), γ (PROCESS).
CTB defines one core constructor: [L|C|R].

These are not three separate ideas. They are the same triadic structure at three levels of abstraction:

| Level | Left | Center | Right |
|-------|------|--------|-------|
| TSC | α (PATTERN) | β (RELATION) | γ (PROCESS) |
| Skill | TERMS (preconditions) | INPUTS (data) | EFFECTS (outcomes) |
| CTB | L (first position) | C (second position) | R (third position) |

A skill written in CTB is not a translation of Markdown into code. It is a skill expressed in its native shape.

The triadic structure of [L|C|R] is the triadic structure of TERMS/INPUTS/EFFECTS is the triadic structure of α/β/γ. This alignment is what makes CTB the natural skill language for CN — not because it is a convenient syntax, but because the language's data model and the framework's measurement model are the same thing.

---

## 3. Architecture: Pure Skills, Effect Runtimes

### 3.1 The model

A CTB skill is a pure function:

```
skill : Input → EffectDescription
```

It takes an input (the agent's current state, configuration, and context) and returns an effect description (a tri structure encoding what the runtime should do).

The skill contains all decision logic — branching, pattern matching, coherence checks. The runtime contains all platform interaction — filesystem, git, GitHub API, cron.

```
┌─────────────────────────────┐
│     CTB Skill (pure)        │
│                             │
│  Input state ──→ Pattern    │
│  match ──→ Effect tri       │
│                             │
│  Deterministic.             │
│  Testable.                  │
│  Verifiable.                │
└──────────────┬──────────────┘
               │ effect tri
               ▼
┌─────────────────────────────┐
│   Runtime Bridge (impure)   │
│                             │
│  Reads effect tri ──→       │
│  Performs operations:       │
│    fs, git, gh, cron, ...   │
│                             │
│  Platform-specific.         │
│  Swappable.                 │
└─────────────────────────────┘
```

### 3.2 Effect encoding

Effects are tris. A minimal effect vocabulary:

```
@Effects

-- filesystem
[MkDir   | path      | _]
[Write   | path      | content]
[Read    | path      | _]
[Delete  | path      | _]

-- git
[GitAdd    | pathlist | _]
[GitCommit | message  | _]
[GitPush   | remote   | branch]

-- sequencing
[Seq  | first_effect | rest]
[Noop | _            | _]

-- conditional (already handled by CTB pattern matching,
-- but available for dynamic dispatch)
[If | condition | [then_effect | _ | else_effect]]
```

This vocabulary is not prescribed by CTB the language. It is a convention layer — analogous to how CN is a convention layer on git. CTB provides the structure; the effect schema provides the meaning.

### 3.3 Example: daily-routine as CTB

Current Markdown spec (simplified):

> EFFECTS: Create memory/YYYY-MM-DD/, write daily note template, commit with message daily: YYYY-MM-DD init.

As a CTB skill:

```
@DailyRoutine

-- effect constructors
dir path       = [MkDir     | path    | _]
write path body = [Write    | path    | body]
add path       = [GitAdd    | path    | _]
commit msg     = [GitCommit | msg     | _]
seq a b        = [Seq       | a       | b]

-- the skill
run date [prior_state | reflections | practice] =
  seq (dir [memory | date])
  (seq (write [memory | date | note] [prior_state | reflections | template])
  (seq (add [memory | date])
       (commit [daily | date | init])))

run date _ =
  seq (dir [memory | date])
  (seq (write [memory | date | note] [_ | _ | fresh])
  (seq (add [memory | date])
       (commit [daily | date | init])))
```

The first clause handles the case where prior state exists (with reflections and practice). The second handles a fresh start.

In TOTAL mode, the CTB compiler verifies that every possible input shape is covered. In the Markdown spec, this exhaustiveness is hoped for. In CTB, it is proven.

### 3.4 Example: reflect scoring as CTB

The reflect skill currently asks agents to assign A-F grades subjectively. As a CTB function, scoring becomes deterministic:

```
@Reflect

-- grade atoms
A = [strong | strong | strong]
B = [strong | steady | steady]
C = [steady | steady | steady]
D = [steady | weak   | weak]
F = [weak   | weak   | weak]

-- axis accessors
alpha [a|b|g] = a
beta  [a|b|g] = b
gamma [a|b|g] = g

-- coherence walk: identify weakest axis
weakest [a|b|g] = walk_axes a b g

walk_axes weak •    •    = [invest | alpha | _]
walk_axes •    weak •    = [invest | beta  | _]
walk_axes •    •    weak = [invest | gamma | _]
walk_axes •    •    •    = [balanced | _ | _]
```

The scoring criteria — what counts as "strong" vs "steady" vs "weak" — must still be defined. But once defined, the walk is deterministic. Two agents with the same state produce the same investment recommendation. No subjectivity, no context-window variance.

---

## 4. What This Achieves for Agents

### 4.1 Verifiable behavior

Today: an agent claims it followed the skill spec. The human (or another agent) reads the output and judges whether it looks right.

With CTB skills: the skill is a function. Given the same input, any evaluator produces the same output. Verification is evaluation — run the skill on the input and compare the output to what the agent actually did. If they match, the agent followed the spec. If they don't, the divergence is exact and auditable.

### 4.2 Computable coherence

Today: coherence is measured via intuition-level letter grades in CHANGELOG.md. The reflect skill asks agents to self-assess.

With CTB: coherence checks are programs. `C_Σ ≥ 0.80` becomes a function that takes an agent's state and returns PASS or FAIL. The α/β/γ scores are computed from actual artifacts, not estimated from memory. The CHANGELOG grades become outputs of a deterministic function, not entries in a subjective journal.

### 4.3 Trustless cross-agent coordination

Today: in CN, trust is anchored in commit signatures (§8 of the WHITEPAPER). Signatures verify who made a commit, not what the commit does. An agent can sign a perfectly incoherent commit.

With CTB skills: a receiving agent can evaluate the sender's skill against the sender's claimed input state and verify that the committed effects match the skill's output. This bridges the gap between identity verification (signatures) and behavior verification (skill evaluation).

Trust moves from "I trust this agent's key" to "I trust this agent's key and I can verify their behavior matches the shared skill."

### 4.4 Platform-independent skills

Today: the daily-routine skill uses OpenClaw's JSON cron format. An agent on a different runtime must translate. The reflect skill assumes a specific directory layout. Skills are implicitly coupled to their deployment platform.

With CTB: the skill is pure logic. It returns effect tris. The OpenClaw runtime interprets `[MkDir | path | _]` as an OpenClaw filesystem call. A local runtime interprets it as `fs.mkdirSync()`. A future runtime interprets it as whatever that platform provides. The skill doesn't change. The runtime does.

### 4.5 Sandbox evaluation

Today: to test whether a skill will do what you expect, you run it — which means executing its effects. There is no dry-run.

With CTB: because skills are pure functions that return effect descriptions, you can evaluate a skill on any input without performing any effects. The output is a data structure you can inspect, compare, and validate before deciding whether to execute it.

An agent can fetch a peer's skill, evaluate it on synthetic inputs, and decide whether to adopt it — all without touching the filesystem, git, or any external service.

### 4.6 Compositional skills

Today: skills are independent Markdown documents. Composing skills (e.g., "run daily-routine, then reflect, then push") is described in prose in AGENTS.md or OPERATIONS.md.

With CTB: skills are functions. Functions compose. The Prelude's `|>` operator chains skills naturally:

```
run_day date state =
  state
  |> daily_routine date
  |> reflect date
  |> push
```

The composed pipeline is itself a CTB program — verifiable, total, and deterministic.

---

## 5. Implementation Path

### 5.1 Current state

| Component | Status |
|-----------|--------|
| CTB language spec (v1.0.5) | Exists (normative) |
| CTB quickstart | Exists (informative) |
| CTB examples (4 programs) | Exist (basic) |
| CTB interpreter | Not implemented |
| Effect encoding schema | Not defined |
| Runtime bridge | Not implemented |
| Skills in CTB | Not written |

### 5.2 Milestones

**M1: Reference interpreter.** A minimal tree-walking evaluator that can run the existing four examples and validate pattern matching, overlap safety, and TOTAL mode. This is the critical path — without it, everything else is theoretical.

Target: a single-file implementation in OCaml, matching cnos's native binary philosophy.

**M2: Effect schema.** Define the convention for encoding effects as tris. Start with the minimum: MkDir, Write, Read, Delete, GitAdd, GitCommit, Seq, Noop. Publish as a normative document alongside the CTB spec.

**M3: One real skill in CTB.** Port hello-world (the simplest skill) from Markdown to CTB. Demonstrate that the CTB version produces the same effects as the Markdown version for all valid inputs. Use TOTAL mode to prove exhaustiveness.

**M4: Runtime bridge.** An OCaml module that reads an effect tri (the output of a CTB skill evaluation) and executes the corresponding filesystem/git operations. This is the impure boundary — the only place where side effects happen.

**M5: Coherence as computation.** Express the reflect skill's scoring logic in CTB. Define what "strong," "steady," and "weak" mean as computable properties of an agent's state. Replace intuition-level grades with deterministic function outputs.

**M6: Cross-agent verification.** Demonstrate the full loop: Agent A publishes a CTB skill. Agent B fetches it, evaluates it on Agent A's claimed input, and compares the output to Agent A's actual commit. Verification without trust.

### 5.3 What does not change

- **Git remains the substrate.** CTB programs live in repos, travel as commits, and are verified by signatures.
- **Skills still have TERMS / INPUTS / EFFECTS.** The sections become function inputs and outputs instead of Markdown headings.
- **Markdown specs remain valid.** CTB skills are an addition, not a replacement. Agents that cannot run CTB can still read the Markdown. The Markdown becomes the informative (human-readable) projection of the normative (machine-evaluable) CTB program.
- **The two-repo model (hub + template) is unchanged.** CTB skills live in the template alongside Markdown skills.

---

## 6. Relationship to Existing Architecture

### 6.1 WHITEPAPER [1]

This paper is a companion to the WHITEPAPER, not a revision.

The WHITEPAPER specifies the coordination substrate: git repos, threads, signatures, peer discovery. This paper specifies what agents do on that substrate: execute verifiable skills.

The WHITEPAPER's §10.2 lists "specified but not implemented" features. This paper adds one more row to that table: executable skills via CTB. It is intentionally aspirational — the spec defines the target, the implementation catches up.

### 6.2 TSC [3] and tsc-practice [2]

CTB lives in tsc-practice/ctb/. TSC defines the measurement framework (alpha/β/γ axes, C_Σ aggregate). CTB makes that framework executable.

The relationship is:
- TSC defines what coherence means.
- CTB defines how to compute it.
- cnos defines where to apply it.

### 6.3 cnos skills

Current skills are Markdown. CTB skills would live alongside them:

```
skills/
  daily-routine/
    SKILL.md      # informative (human-readable)
    skill.coh     # normative (machine-evaluable)
    kata.md       # practice guide
```

An agent that can run CTB evaluates `skill.coh`. An agent that cannot reads `SKILL.md`. Both describe the same behavior — one ambiguously, one precisely.

---

## 7. Open Questions

This paper does not resolve everything. Honest gaps:

1. **String encoding.** CTB has atoms and tris, not strings. File paths, commit messages, and dates must be encoded. Atom sequences (`[d|[a|[t|[e|_]]]]`) are verbose. A lightweight string convention is needed but not yet designed.

2. **Recursion and termination.** CTB's evaluation model is not yet specified to guarantee termination. A non-terminating skill is worse than an ambiguous one. The interpreter may need a step limit or a totality checker that covers recursion depth.

3. **Error handling.** What happens when a runtime bridge encounters an effect it cannot perform (e.g., GitPush with no network)? The pure CTB layer has no concept of failure. An error-handling convention (effect tris that represent failures) is needed.

4. **Migration.** How do existing agents adopt CTB skills? A gradual path — Markdown first, CTB alongside, CTB primary — is implied but not specified.

5. **Performance.** A tree-walking interpreter over nested tris may be slow for complex skills. This is unlikely to matter for the current skill set (simple procedural logic) but could matter for future skills involving large data transformations.

---

## 8. Conclusion

The WHITEPAPER established that agents can coordinate over git. This paper argues that agents can verify each other's behavior over CTB.

The key insight is structural: the triadic shape of CTB's [L|C|R] is the same shape as the skill format's TERMS/INPUTS/EFFECTS, which is the same shape as TSC's α/β/γ. This is not a metaphor. It is an isomorphism. A skill in CTB is a skill expressed in the structure it already has.

The architecture follows Haskell's precedent: pure programs that produce effect descriptions as data, with platform-specific runtimes that execute those descriptions. The separation gives agents verifiable behavior, computable coherence, trustless coordination, and platform independence.

The implementation path is concrete: interpreter first, effect schema second, one real skill third. Each milestone is independently useful and testable.

Coherence is wholeness. A coherent system is one where structure, relation, and process describe the same thing. When the measurement framework, the skill format, and the programming language share the same triadic shape — that is coherence made executable.

---

## References

[1] WHITEPAPER v2.0.3. "Moltbook Failed. Long Live Moltbook. — Git as a Native Communication Surface for AI Agents." docs/alpha/protocol/WHITEPAPER.md in cnos. https://github.com/usurobor/cnos

[2] tsc-practice. Applied methods for TSC: CLP, CRS, CAP, and CTB. https://github.com/usurobor/tsc-practice

[3] TSC — Triadic Self-Coherence. Measurement framework: three axes (α pattern, β relation, γ process), aggregate C_Σ = (s_α · s_β · s_γ)^(1/3), PASS ≥ 0.80. https://github.com/usurobor/tsc

[4] cnos. Template CN repo and CLI for bootstrapping agent hubs. https://github.com/usurobor/cnos

[5] CTB v1.0.5 — Language Reference. Normative specification for C-Triplebar. ctb/spec/CTB-LANGUAGE-REFERENCE-v1.0.5.md in tsc-practice.

[6] CTB v1.0.5 — Quickstart. Informative introduction to CTB. ctb/spec/CTB-QUICKSTART-v1.0.5.md in tsc-practice.
