Why founder-led, for now
TWIRX is founder-led during Genesis because accountability requires a real decision-maker. There is currently one maintainer. A governance structure that pretended otherwise would be theatre, and theatre is the failure mode this project is least able to afford.
That stewardship is constrained rather than absolute. The protocol assets — the specifications, canonical schemas, conformance vectors, trust models, semantic kernel, reference implementations, registry metadata, governance and treasury records — are held for the commons. No donor, maintainer, company, model provider, cloud provider, or chain purchases ownership of them.
Governance should become more distributed when there is a real contributor and maintainer community to distribute it to. Not before. Simulated decentralisation before a community exists concentrates power while claiming the opposite.
The practical difference
Founder-led means the founder decides. Constitution-bound means the founder has published, in advance and in public, the things they have agreed not to decide — and the record of every material decision, including the alternatives rejected and the conditions under which it would be reversed.
The authority order
When two project artefacts disagree, this ordering settles it. It exists because documentation drifts faster than code, and code drifts faster than a specification.
- Normative schema and specification NormativeThe CDDL wire schemas and the specification text. These define the protocol.
- Conformance vectors NormativeCommitted positive and negative inputs with expected outcomes. Released vectors are immutable.
- Gate evidence report NormativeWhat was actually executed, on which host, with which result. The authority for any implementation-status claim.
- Implementation code ExplanatoryWhat the current implementation happens to do. Not the definition of correct.
- Architecture decision records ExplanatoryWhy a choice was made, what was rejected, and how it could be reversed.
- Explanatory documentation ExplanatoryThis website and the technical documentation. Helpful, never authoritative.
- Roadmap and research ExplanatoryDirection. Carries no commitment that anything will be built.
This is why every technical page here carries an implementation-status label, and why the proof page quotes the evidence report rather than paraphrasing it.
The founding laws
Twelve commitments from the Charter. An amendment requires a public change record explaining why it strengthens or preserves the mission. No amendment may privatise the protocol, retroactively conceal treasury activity, or convert financial sponsorship into ownership of technical truth.
| # | Law | What it forbids in practice |
|---|---|---|
| 1 | Source-statement fidelity | Publishing a canonical result that cannot identify what an origin represented and how it was derived. |
| 2 | Native meaning first | Normalisation that erases the source-native statement. |
| 3 | No invented certainty | Fabricating a plausible value where knowledge is absent. |
| 4 | Separate dimensions | Collapsing integrity, publisher identity, authority, confidence, freshness, and evidence completeness into one score. |
| 5 | Visible failure | Silent degradation, drift, revocation, contradiction, or uncertainty. |
| 6 | Language sovereignty | Letting an implementation language define the protocol. |
| 7 | Local and cloud neutrality | Essential protocol functions that cannot be self-hosted. |
| 8 | Open extension, governed canon | Both closed extension and automatic canonisation. |
| 9 | Least authority | Inferring action authority from a read interface. |
| 10 | Optional cryptographic infrastructure | Making a chain a mandatory protocol sovereign. |
| 11 | No token | Selling governance rights or protocol participation through a speculative asset. |
| 12 | Honest sustenance | Disguising maintainer compensation, or exchanging it for ownership of the standard. |
Decision classes
Not every change deserves the same ceremony. The class determines the record that must exist before the change is accepted.
| Class | Examples | Required record |
|---|---|---|
| Implementation | Refactor, internal package layout, test helper | Pull request and tests |
| Architecture | Storage abstraction, wire encoding, isolation boundary | Architecture decision record |
| Protocol | Representation semantics, provenance fields, trust states | RFC plus conformance vectors |
| Security-critical | URL policy, signature rules, action risk | Threat-model update, security review, RFC or ADR |
| Constitutional | Ownership, funding rights, protocol guarantees | Charter amendment |
A material protocol decision must record the problem, the alternatives considered, the security and compatibility effects, the rationale, the decision owner, the date and version, and the conditions under which it would be reversed or migrated. ADR 001 is the worked example.
The admission rule
Automated systems may generate candidates. Only the admission path may create canonical releases.
In Genesis, admission is a reviewed repository change containing fixtures, expected outputs, compatibility analysis, and provenance. That is a low-tech process, and deliberately so: the rule matters more than the machinery, and the machinery can only be trusted once the rule has been enforced by hand for long enough to know what it costs.
How influence is earned
Influence follows demonstrated responsibility: accurate implementation, review quality, security discipline, maintenance over time, documentation and conformance work, and respect for the charter. Money, popularity, institutional status, nationality, ideology, and access to a model provider do not buy technical authority.
How disagreement is handled
Through explicit claims, evidence, experiments, benchmarks, threat analysis, and reversible decisions where possible. Competing modules or competing implementations are preferable to forcing a false consensus into the protocol.
What funding cannot buy
The project needs money and says so plainly on the funding page. The charter constrains what that money can ever mean.
A contributor may receive Implemented
- Public or private acknowledgment, at their choice
- Project updates
- Transparent evidence of how the contribution was used
- Participation through the ordinary contribution and review process
A contributor does not receive
- Ownership of the protocol
- Equity, by implication or otherwise
- Governance votes or private vetoes
- Canon or ontology admission
- Preferential security exceptions
- Exclusive access to the specification
- A token, or any promise of financial return
Grant terms are held to the same standard. Any confidential condition that could affect protocol independence must be rejected or disclosed before acceptance.
Succession
No indispensable credential, repository, domain, wallet, signing key, or production system should remain permanently controlled by one person. Today, several do.
That is stated rather than hidden because it is the honest description of a one-person project at its first gate. The charter fixes the remedy in advance: when the project has additional trusted stewards, critical assets migrate to threshold or multisignature control with documented recovery procedures. If the steward organisation dissolves, public protocol assets transfer to a compatible open-source or public-interest steward — never a private buyer.
Current concentration
One maintainer holds the repository, the release decision, and — once declared — the treasury wallet under single-signature control. The migration condition is published on the funding page: multisignature control after at least two additional trusted stewards and tested recovery procedures exist.
The four documents
Mixing morality, governance, implementation, and wire rules into one document is the most common way a project's commitments become unenforceable. These four are kept separate on purpose.
| Document | Function | Authority |
|---|---|---|
| Public declaration | A concise invitation and public commitment, readable by non-specialists. | Explanatory |
| Manifesto | Why the project exists, what it values, and the future it wants. | Explanatory |
| Charter | Binding stewardship and governance law. Constrains the steward. | Normative |
| Specifications | Technical requirements for conformance and independent implementation. | Normative |
Also public: GOVERNANCE.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, ACCESS_POLICY.md, and the constitution directory.