Koord software

Koòrd, the software

A web interface for working on a problem with several language models under Koòrdinated Thinking: the versioned specification at the centre, the decision log as a first-class structure, and several distinct interlocutors converging on one shared document under a human operator's guidance.

Not yet built. app/ is the place it will occupy. Nothing there is stubbed to look further along than it is.

Why a tool at all

Each of the four principles holds today only by the operator's discipline, because the interfaces were designed for single conversations. The decision log lives in a hand-maintained file. Open points are lost if nobody writes them down. Distilling a specification, tracking its changes and splitting it into sub-specifications are manual operations. A table of interlocutors — distinct by role and, where it matters, by model — means orchestrating several conversations by hand and keeping their roles apart.

That management effort is bearable on one project and treacherous across many. A tool that takes the method as its native form turns a demanding practice into an ordinary way of working. That, and not another container for conversations, is what justifies building it.

What the method demands of it

Requirements, not aspirations: each descends directly from a principle.

From the method	What the application must do
The specification is the primary artefact, additive and versioned	The document, not the conversation, is the central object. No version deletes its predecessor
Decisions are numbered and carry their rationale	A first-class structure, citable by identifier. Superseding is tracked; nothing is deleted
Open points	Explicit entries alongside closed decisions, which never block the rest of the work
Two phases: drafting and application	The application phase reads the specification read-only; discrepancies escalate to the drafter rather than being resolved locally
Glossary, references, change log	Anchors that live in the document, not in a conversation's context
Distillation and partitioning	A condensed view produced on demand; splitting into linked sub-specifications
Two levels of plurality	Distinct personas and models from different vendors and architectures on the same problem
Small models downstream	A well-specified task must be executable by a modest, locally-run model

The last one is the economic argument, and it runs against the grain of the field: a good specification turns downstream work into a structured task, and structured tasks are where small models are adequate. The aim is to minimise the share of work that needs large, costly models in production, and to leave the clear, well-specified tasks the method produces to local ones — cheap, runnable in-house, and easier on the data they touch.

Runtime

A single Docker container. Decided 2026-08-09.

Openness, and its limit

The software is published fully open source under Apache 2.0: use, modification, forking and commercial use are free under the licence. Nothing about the code is held back.

What is not published is the product specification and the internal design documents. The product's value rests on their confidentiality, not on restrictions over the code — which is why the code can be given away without hesitation. That material is not in the repository and will not be added to it; the .gitignore refuses its known filename patterns as a second line of defence, the first being not to put it there.

There is a symmetry worth noticing: a project whose method says the specification is the primary artefact publishes the product and keeps the specification. The method is what is being given away here — the document, in full, under CC BY 4.0. The specification of one particular product built with it is not.