Eight constraints that survive whether the project succeeds or not.
These are not aspirations. They are the constraints every project in this suite has to honour even after it has shipped. They make adoption, audit, and fork all cheap; they make capture expensive.
Deploy by manifest
The manifest is the source of truth; URLs are transport. The same artifact can be served from anywhere as long as the manifest binds its hash.
Verify by hash
Refuse to install bytes that don’t match the manifest’s sha256. No exceptions, no override, no “close enough”.
Evidence on disk
Dashboards and operators must be able to rebuild full state from local files alone. If the dashboard is gone, the receipts still tell the story.
Replicate via Radicle, not a forge
Source, issues, patches, and backlog all replicate through Radicle gossip. No central forge holds the canonical view.
Forkable playbooks, not hosted services
The output of every project is patterns, runbooks, and protocol documents that other communities can fork and run. Hosted instances are a convenience, not a dependency.
BDD as the contract
Each project keeps its backlog and acceptance criteria as BDD scenarios in .feature files. There is no separate ticket system to drift out of sync with the spec.
Secrets out-of-band
.secrets/ locally, /etc/ on servers. Manifests never carry secrets; pipelines never embed them.
Refusal by default
Ambiguous bytes, mismatched hashes, missing evidence, expired allowlists — all fail closed. The default outcome of uncertainty is “do nothing”, not “try and hope”.
The decentralization litmus test
These eight rules exist to keep the suite passing a stricter test: Bitcoin-grade decentralization. A protocol that can credibly run without its original authors should hit each of the following marks — not as slogans, but as testable contracts.
| Mark | What it means in this suite |
|---|---|
| no premine | No project ships with reserved authority, reserved tokens, or reserved capacity that a community joining later cannot also earn. |
| no roadmap | Each project advances via versioned protocol changes the network can adopt or reject. Direction is not promised on behalf of strangers. |
| no issuer | No single party can grant or revoke participation. Identity is keys, not accounts. Seed operators do not gatekeep the spec. |
| no censorship | Any compliant peer can replicate, build, deploy, and verify. The bytes are content-addressed; the protocols are documented; the playbooks are forkable. |
Who decides what
Decentralization isn’t just about nodes and keys; it’s about who decides. The suite makes the “who decides” question concrete:
- What ships: whoever can merge to the canonical Radicle ref.
- What counts as built: whoever holds the PMCI signing key.
- What counts as deployed: whoever writes the canonical PMCD release manifest.
- What replicates: any peer with the allowlisted key on the seed.
Each of those is a small, defined, replaceable surface — not an implicit dependency on a hosted provider that can change its terms at will.