Drafted with AI assistance, then checked and revised by the author. The judgements and the errors are the author’s. How this site is written sets out what is declared on every piece, who checks it, and where the per-piece record lives.
No one has built the whole of it, and the piece does not claim otherwise.
What that means for you: the twelve capabilities are stated as properties with a way to check each one, so you can verify a claim rather than accept it. The parts that are unmeasured are named — two of them decide the proposition and neither can be settled by analysis.
If a blueprint waited for proof it would never be published, and the reason to publish it unproven is that the alternative is everyone working it out separately. Treat it as a starting position to argue with, and publish what you find when you disagree.
Yes, and it is deliberately absent.
The reason is that a specification describing how describes one design, and a specification describing what can be met by several. If we told you the method, this would be a manual for our approach rather than a standard anyone could satisfy.
There is also a plainer reason, and it should be stated: the method is not published because it represents work someone did. That is a limitation on this document and you should know it is there. What you get is enough to specify, procure and verify — not enough to skip the engineering.
It is, which is why the piece calls it a deliberate limitation rather than a safety feature.
An agent that can read across everything about a person is more useful. The position taken here is that the operator should not be able to do that even when it would help, because a system that retains the capability and declines to use it will eventually use it — the person who declined leaves and the reason is forgotten.
It costs you real functionality. If you think the trade is wrong, that is a legitimate disagreement, and it should be argued rather than assumed away.
It is. Co-operatives grow at the speed of member trust and decide at the speed of member agreement.
What the structure buys in exchange is that the terms cannot be changed against members by anyone whose interests differ from theirs. If you want speed, a conventional company is faster and will eventually be acquired by someone with different intentions. That is the trade and the piece does not pretend it is free.
It is paying twice, and it is the single most expensive commitment in the design after ownership.
The reason is correlated failure. A federation running one configuration fails everywhere simultaneously when that configuration fails anywhere. The argument is developed in Running an organisation where agents do the work; the practical version is that the pressure to standardise will arrive every year with a good argument attached, which is why the commitment sits where management must persuade the members rather than simply decide.
The specific part is what to prove first, and it is not the technology.
Prove the whole loop end to end — installed hardware, models running locally, the desk answering, records signed, and an exit drill passed — before forming the entity. The reason is that co-operatives formed by organisations that have already transacted together hold, and ones formed on a prospectus do not. That is a claim about co-operatives rather than about software.
Nothing structural, and that is a real weakness.
Two things reduce it. The result is published including failures, so a clean first run is itself suspicious — the piece says a first drill should be expected to fail at least one check, and one that passes cleanly indicates the checks were written to be passed. And a member observes, which means the person watching is not the person who benefits from the result.
If your drills stop finding defects, make them harder rather than celebrating.
Yes. It is chosen anyway, and the reasoning should be tested rather than accepted.
Public bodies want assurance before they pilot, which is real cost before any revenue, and their procurement cycles are long. What they bring is that their requirements force the standard to be real. A standard tested only against organisations with no compliance obligations is a standard that has not been tested.
The counter-case — community organisations first, faster, paying less — is legitimate and the piece names it as a decision rather than settling it for you.
That the cost is real and immediate while the benefit is a possibility.
You pay for hardware, for a service, for a heterogeneity premium and for an exit capability you may never exercise. In exchange you avoid a future position that may not arise for you specifically. That is a genuinely hard case to make to a board, and anyone who tells you otherwise is selling.
The response is in part A: the position arrives without announcing itself, and by the time it is obvious the cost of leaving is what makes it obvious.
Three things, all measurable early, and all listed in the piece:
Any of those and the design needs rewriting rather than better advocacy. If you build this, measure them first and publish what you find.
What this publication does not claim, and what is outstanding against it in the register.
A question this rests on is parked: What counts as complete state for a cluster?
We do not claim a defined completeness boundary for cluster state; we claim the criteria in DEL-06 and nothing beyond them.
A question this rests on is parked: What secession premium will members bear?
We publish no pricing and no affordability claim, and we do not assert that members value the secession guarantee.
A question this rests on is parked: What do we do with an application that refuses to run inside the boundary?
We do not claim that a member's existing applications can be made to run inside the boundary. We claim only that the boundary reveals which ones cannot.
A question this rests on is open: Does secession capability actually convert a buyer?
Alongside: the publication · glossary · sources and provenance