founding claim
Human primacy, not code supremacy
A DAO enforces structure with a smart contract. An HAO uses technology to support human judgment — and treats governance, learning and trust as first-class design elements alongside the code.
ideas
The ideas
Eight load-bearing claims — what the HAO asserts, why, and what has to be true for each to hold.
The HAO is not a management style and not a protocol. It is an argument that organizations fail people in specific, diagnosable ways, and that those failures are addressable at the level of structure rather than sentiment.
Each idea below is stated plainly, traced to the sources that support it, and followed to the point where it becomes fragile. The last one is entirely about the fragility.
economic engine
Trickle-up capital
Capital and decision rights stay at the productive edge of the network and flow upward, rather than being allocated downward from a centre that never touched the work.
coordination substrate
The trust graph
Trust as a weighted, dynamic, multi-dimensional map — with access, roles and credit capacity that grow as reputational signals accrue, rather than being granted or bought.
decision architecture
Polycentric governance and consent
Multiple concurrent decision centres, no single layer holding unilateral control, decisions pushed to the lowest competent level, and consent rather than majority vote.
design tradeoff
Resilience over efficiency
Overlapping roles, duplicated capability and deliberate slack — treated as fault tolerance rather than waste.
infrastructure claim
The socio-emotional layer
Emotional safety, ritual design and conflict resolution treated as engineered infrastructure with the same rigour as the ledger — and the specific ways that goes wrong.
evidence
The precedents: Mondragon and CECOSESOLA
Two cooperative federations operating at scale for decades — one proving nested governance and ecosystem self-sufficiency, the other proving the relational layer. Including what each had to give up.
the case against
Why it fails
The framework's own documentation identifies the failure modes most likely to kill it. Collected here without softening, because a model that cannot state its own break points has not been designed yet.