Skip to content
Solidarity Commons Protocol

Audience Structure

Context

Section titled “Context”

The docs need to serve readers who are learning the solidarity or purpose economy, readers who operate cooperative institutions, and readers who already understand the civic context and want technical depth. A technical/nontechnical split is too blunt. It hides operators, integrators, compliance reviewers, researchers, funders, and contributors.

The research base points in two directions. Diataxis says documentation should be organized around reader needs. GOV.UK user-needs guidance says non-user opinions should be treated as assumptions to test. At the same time, the project spans stable institutional and technical domains: cooperative identity, fiscal sponsorship, community land trusts, Holochain validation, ValueFlows, Holochain Resource-Event-Agent (hREA), legal records, and accounting boundaries.

Dialectic

Section titled “Dialectic”

The reader-route position argued that docs should meet people in their own problem language first. A fiscal host should not have to translate an approval workflow into a treasury aggregate before the docs make sense. This position preserved institutional plurality.

The domain-map position argued that docs are governance for contested concepts. If fiscal sponsorship, land stewardship, cooperative governance, Holochain validation, and economic flows are retold separately for every audience, the canonical concepts will drift.

Both positions exposed a failure. Reader routes fail when they become separate persona silos. Domain maps fail when they ask every reader to enter through the builder’s ontology.

Decision

Section titled “Decision”

Use a two-layer information architecture. Reader routes are entry trailheads:

  • Learn the Context
  • Apply It in Practice
  • Understand the Technical System
  • Build on Holochain
  • Integrate or Govern Boundaries
  • Evaluate or Fund
  • Contribute

Canonical domain pages are the durable spine. They hold institutional concepts, software architecture, protocol vocabulary, risk boundaries, diagrams, decision records, and reference inventories. Reader-route pages should link into those canonical pages instead of restating them.

Consequences

Section titled “Consequences”
  • The audience page becomes a route map, not a permanent persona taxonomy.
  • Future domain pages should include a small “who uses this” note, then keep the canonical explanation in one place.
  • New docs should name a primary reader route and a Diataxis page type before drafting.
  • Claims about institutions, law, accounting, protocols, external tools, or software behavior need real sources.
  • Pilcrow remains the prose gate. Source-sensitive pages need an explicit source-review pass.

Sources Checked

Section titled “Sources Checked”