stone asked for this in forum post 834ceded37, on 2026-10-10. The battery plans and runs tests of proposals for OCX protocol v1, using uninitiated agents of different reasoning levels and judging them against README's values. The protocol is not bound to today's tools. It is an extension to Fossil, written in Crystal, for working with agents in ways that keep them efficient and tolerate lower reasoning. Each axiom should hold or be challenged, and each function should be justified by the values.

Everything here is a proposal under test, not OCX's design. Where a draft uses a word differently from GLOSSARY.md, the glossary governs until stone decides otherwise (see "Where draft 3 departs from the glossary").

What ran

Four drafts. Each says which axiom or virtue justifies each of its elements.

• Draft 1, two ways in (round 1). Both share one core (core.md, E1 to E9):
  • proposal-a.md: people and agents write records and posts by hand;
  • proposal-b.md: typed tools only.
• Draft 2 (proposal-c.md, round 2): proposal B, rewritten from round 1's findings to stand alone.
• Draft 3 (proposal-d.md, round 3): draft 2, rewritten from round 2's findings. Three variants of it, a line or three changed, ran on the smallest model only.
• Draft 4 (proposal-h.md, round 4): draft 3 with round 3's lessons, after stone chose draft 3 as v1's base (2026-10-10, at the terminal: "yes, please incorporate lessons from the feedback"). Round 5 handed draft 4 over again, specification only, to subjects in a sandbox with fossil and crystal (rounds.md).
• Draft 4.1 (proposal-4.1.md): draft 4 with the problems rounds 4 and 5 hit, fixed.
• Draft 4.2 (proposal-4.2.md): draft 4.1 with no raw Fossil login for agents. Round 6 ran 4.1 and 4.2 side by side, boxed (rounds.md).
• Draft 4.3 (proposal-4.3.md): draft 4.1 with restrictions a record may ask for and a node may enforce (round 7).
• Draft 4.4 (proposal-4.4.md): draft 4.3 with round 7's three challenges answered.
• Draft 4.5 (proposal-4.5.md): draft 4.4 in Fossil's words, "user" for "login".
• Draft 4.6 (proposal-4.6.md): two planes on Fossil: the OCX control protocol and a separate verdict standard.
• Definitions, a few at a time (defs/README.md): each tested on its own before it goes to stone.

Five subjects, none of whom had seen OCX:

• Claude Opus 5.5, Sonnet 5 and Haiku 4.5. Each ran as a fresh agent with one allowed tool use, reading its prompt.
• Gemma 4 31B and Qwen2.5-coder 7B. These ran locally in Ollama, at temperature 0.2. They were repeated several times per draft to tell a draft's effect from sampling noise.

The prompt. Each prompt holds the values (README's axioms and virtues), the draft and four tasks; nothing else. build.py rebuilds every prompt byte for byte.

• T1, Justify: for each element, the value that justifies it, or "unjustified", and whether the subject agrees with the draft's own justification.
• T2, Do: five scenarios, answered as the exact artifacts or tool calls. check.py scores them against the draft as written.
  • S1: set up a reviewer agent on dev that hears stone only.
  • S2: as the agent, record a failing verdict.
  • S3: answer stone's question "why did you fail it?"
  • S4: stop the agent.
  • S5: say what happens to a post from a login that isn't heard.
• T3, Challenge: for each axiom, whether it holds, or a concrete case that breaks it; then what to remove or change, and why, in terms of the virtues.
• T4, Ambiguity: every place where two builders would build different things.

Changes between rounds. Two changes bear on comparing the rounds:

• From round 2, S1 also states what passes ("a check-in passes when it builds"), because from draft 2 the agent's objective must say it.
• In round 3, the checker was found to fail a T2 answer for saying "no OCX tool deletes branches". It now reads a denial as a denial, and every answer has been scored again with the fixed checker.

Results

T2 score out of 5. For the local models, the score is the mean over runs, with the number of runs in brackets. "Hears stone" counts the runs whose S1 agent would actually be given stone's question in S3.

Subject	Draft 1 A	Draft 1 B	Draft 2	Draft 3	Draft 4	Draft 4, boxed	Hears stone (1B / 2 / 3 / 4)
Opus 5.5	5	5	5	5	5	5	yes / yes / yes / yes
Sonnet 5	5	5	not run	5	5	5	no / – / yes / yes
Haiku 4.5	5	5	5	5	5	5	no / no / yes / yes
Gemma 4 31B	3	5	5 (3)	5 (3)	5 (3)	5 (3)	no / 0 of 3 / 3 of 3 / 3 of 3
Qwen2.5-coder 7B	3	3.67 (6)	3.17 (6)	3.47 (15)	3.53 (15)	2.8 (15); 3.87 (15) with no tools offered	0 of 6 / 0 of 6 / 15 of 15 / 15 of 15

Each scenario's failures for Qwen 7B, the only subject below 5 on draft 3:

Scenario	Draft 1 B (6 runs)	Draft 2 (6)	Draft 3 (15)
S1 set up	4 right; 2 added a post	3 right; 3 copied the record's shape into create	11 right; 4 added a post; the shape right in all 15
S2 verdict	6 right	4 right	11 right; 4 posted the verdict as text
S3 answer stone	5 echoed stone's question; 1 answered, to the record	5 echoed; 1 answered, to the record	12 answered with the reason, to the record; 3 echoed
S4, S5	all right	all right	all right

S3's strict check wants the answer posted as a reply to stone's own post. A reply to the record lands in the same thread, where stone sees it, so answering there is a lesser fault than echoing his question back. Qwen answered there in 2 of 12 runs of drafts 1 and 2, and in 12 of 15 runs of draft 3.

That was not draft 3's doing. Draft 3, its three variants and draft 4 differ by a few lines, and Qwen echoed the question back in 3, 6, 10, 1 and 10 of 15 runs on them. No line of a draft explains that spread, so how Qwen fails S3 is noise in the model, not an effect of any draft. An earlier version of this report credited draft 3's E4 with the change; round 4 showed otherwise.

Efficiency. Under typed tools (drafts 1 B to 3), every Claude and Gemma answer used the fewest actions possible: four, one per scenario. Writing by hand (A) took Claude five, and left the local models' blocks unfenced.

Round by round

rounds-early.md has what drafts 1 to 3 changed and the failure behind each, and round 4. rounds.md has round 5 on: the sandbox, drafts 4.1 to 4.5, and what each round found.

The axioms

Ax1, control requires predictability: holds in its Meaning, not its headline.

• Opus said so in rounds 1 and 2: "if you must wait to see what it does, you are not in control" is stronger than the Meaning, "what must be predictable is the boundary". The protocol can only meet the Meaning, so Opus would make the Meaning the axiom.
• The Meaning names four bounds: the operations allowed, the budget, the checks the work must pass, and a person's explicit acceptance. Draft 3 has the first two.
• An agent checks in with Fossil directly, on any branch, with no check and no acceptance (Opus, rounds 2 and 3).
• The tools' limits only hold if the agent uses the tools rather than the raw Fossil login it also holds. Those limits are: post only in its own thread, never audit its own check-in, add only audited tags.
• Fossil cannot limit a login to a branch. HISTORY.md decision 26 accepts that cost.
• So Ax1 holds for what an agent hears and how long it runs, and not for what it may write.

Ax2, instrumental neutrality: holds as a stance; its mechanism is weak.

• Judged against the judge's objective. A verdict is judged against the objective of the record that judges it. Nothing ties a check-in to the objective it serves (Opus, round 2).
• Any record can be cited. Any login may cite any record, even one about another branch (Opus, rounds 2 and 3), and nothing checks that the reason tracks the objective (Sonnet, round 3).
• Opus's fix. A verdict counts only when the cited record's own agent wrote it, about a branch in that record's checkins.
• Testimony, not proof. An LLM's verdict is testimony: it cannot be reproduced. Demonstrability asks for a check anyone can rerun, such as the gate. The glossary already has one: the ci tag. Draft 3's runners, claude and codex, leave no room for a plain program (Opus, round 2).

Ax3, cooperative baseline: does no work, and was relied on by accident.

• It justifies nothing. In all three rounds Opus found that no element needs it. Its only use is in Clarity's own justification. Sonnet, round 3: "it's doing no justificatory work in this document".
• It was relied on without saying so. Draft 2 said nothing relies on it; Opus found four places that did.
• Two reliances remain in draft 3 (Opus, round 3):
  • Fossil keeps only the latest tag of a name, so any other login that may check in, other agents included, can replace a verdict (Sonnet too);
  • the tools' limits on an agent hold only if it uses the tools, not the raw Fossil login it also holds.

Ax4, entropy and drift: holds through immutability and E9; three drifts remain.

• A lost run. If a node goes down mid-run, the record gets no response, so its agent login keeps its rights for ever. No tool closes such a record. Opus would add an outcome, lost, which the node writes at its next start.
• Missed check-ins. Check-ins that arrive while no agent runs are never reviewed, and nothing records that they were missed.
• Unknown keys. "A reader ignores keys it does not know" lets an old reader silently drop a new safety key inside sandbox or budget (Sonnet, round 3).

Ax5, blast radius of coupling: overstated twice.

• In E2's claim. An agent's login reaches the whole repository: every branch, any tag. The budget leaves disk unbounded, and nothing budgets a whole host.
• By verdicts. "Last tag wins" couples records that are otherwise independent: one agent's verdict replaces another's (Sonnet, round 3).
• In the axiom itself. Opus: coupling makes a failure likely to spread, not certain, and E7, the hook that starts and stops nothing, shows a part that does not pass its failure on.

Each element and the value that justifies it (draft 3)

Element	Justified by	What the subjects said
E1 One store	Demonstrability, Parsimony	All agreed. Opus: "one owner per fact" overstated Clarity's part, so draft 3 drops it.
E2 Logins	Ax1, Demonstrability, Ax4	Agreed. Opus, round 2: the Ax5 claim was overstated, so draft 3 drops it. Opus, round 3: the draft doesn't say how another clone learns who sent an artifact. In Fossil, that receipt record stays on the repository that received it, so only the node can check attribution.
E3 The record	Ax1, Clarity	Agreed. Opus, round 3: one node per record is Ax1 (never two runs), not Ax5.
E4 The agent's life	Ax1, Parsimony	Agreed.
E5 The response	Demonstrability	Agreed, but only for runs whose node survives; hence lost.
E6 Verdicts	Ax2, Demonstrability	Contested: testimony rather than proof, and the last tag wins.
E7 The hook	Ax1, Parsimony, Clarity	Opus, round 2: "the strongest element". Opus, round 3: it filters by fixed rules, so "decides nothing" should go.
E8 Tools	Clarity, Demonstrability (dry run), Parsimony	Agreed. Opus, round 3: the same tools from three places is Clarity; the real loose coupling is MCP, a replaceable boundary between runner and node.
E9 Versions	Loose Coupling, Ax4	Agreed once draft 3 removed the contradiction; Sonnet's unknown-key drift remains.

No subject called a draft 3 element unjustified.

Tolerating lower reasoning

README's values don't name it.

• What helped. In this battery, every change that helped the smallest model was a Clarity or Parsimony change: one shape, one field per meaning, typed input.
• What it cost. None of them cost the larger models anything.
• What it suggests. Tolerating lower reasoning may be the measure of Clarity, not a value of its own. The draft is clear when its least capable reader acts on it correctly.

Where draft 3 departs from the glossary

• OCX Record. In the glossary, an OCX Record is a ticket change or a post (a root, a reply or an edit) holding a call of any tool, and an edit asks again. In draft 3, it is the root post of a new thread, written only by create, defining one agent, and never edited.
• When. The glossary's when lists arrival, check-in, post and ticket change, with from, each starting the tool or messaging it. Draft 3 has checkins and hears, and the hook never starts anything.
• Verdict. The glossary has a ci or audited tag with a note. Draft 3 has audited only, naming the record it was judged against.
• Response. The glossary has one response per run. Draft 3 has one per record, with the outcome stopped, budget or exited.
• New words: objective, checkins, hears, the budget's fields, node login. "Runner" is used but not yet defined in the glossary.

Files

• The drafts.
  • values.md: README's axioms and virtues, as given to every subject;
  • core.md, proposal-a.md and proposal-b.md: draft 1;
  • proposal-c.md: draft 2;
  • proposal-d.md: draft 3;
  • proposal-h.md: draft 4;
  • proposal-4.1.md: draft 4.1;
  • proposal-4.2.md: draft 4.2;
  • proposal-4.3.md: draft 4.3;
  • proposal-4.4.md: draft 4.4;
  • proposal-4.5.md: draft 4.5;
  • proposal-4.6.md: draft 4.6, the one glossary-v1.diff now follows.
• The prompts.
  • build.py writes prompt-a.txt to prompt-j.txt: one per draft, three variants of draft 3 (e, f, g), draft 4 boxed with the primer (i), and the same text for the no-tools control (j); then the same pair for draft 4.1 (k, l), draft 4.2 (m, n) and draft 4.3 (o, p), and draft 4.4 boxed (q).
  • box.py is round 5's sandbox. A Claude subject runs as box.py claude MODEL PROMPT OUTDIR, and a local one through local-box.py and local-boxed.sh. boxed.py checks the outputs for the sign-in, saves the Claude answers and lists what each subject ran. boxed/ holds each subject's transcript and its proxy log.
  • Each Claude subject was told only: "Read the file …/prompt-X.txt and do exactly what it says. Reading that one file is the only tool use allowed. After it, use no tools: no other files, no search, nothing run. Your final message is your whole answer, under the four headings ### T1, ### T2, ### T3 and ### T4, as the file asks."
  • local-rep.sh runs the local models; its predecessors, local.sh and local-c.sh, ran rounds 1 and 2.
  • handback.py saves a Claude subject's final report.
• The answers.
  • answer-SUBJECT-DRAFT[-RUN].md: every answer, unedited. A Claude subject's answer is the longest text in its transcript holding T1 and T2, since some followed their answer with a summary of it.
  • runs.txt: the local runs' token counts and seconds.
• The scores.
  • check.py DRAFT ANSWER scores one answer.
  • results.py tabulates them all into results.jsonl.