> Markdown twin of https://adna.network/reference/governance-model/
> Index: https://adna.network/llms.txt · Full corpus: https://adna.network/llms-full.txt
> State is a build-time snapshot generated 2026-08-30 (UTC); nothing here is live.

# Governance Model — aDNA Reference

> How the aDNA standard evolves: stewardship, release cadence, backwards compatibility, and the process for proposing changes.

---

## Stewardship

### Founding Architect Model

The aDNA standard is currently governed under a **Founding Architect** stewardship model:

- **Steward**: The Founding Architect (FA) holds decision authority over standard changes
- **Scope**: All normative changes to `adna_standard.md`, conformance level definitions, and governance file requirements
- **Authority transfer**: The FA may delegate stewardship to a **Standard Council** (3+ members) as the community grows. This transition is a governance decision, not a standard version change

### Where governance is going — progressive decentralization

How aDNA is governed today is only the starting point. **The aDNA Network is committed to progressive decentralization:**

- The network is **stewarded by a Founding Architect today**.
- As it **finds and onboards trusted stewards**, those stewards take an **increasing role** in governance — as far as is **helpful and positive** — **at the Founding Architect's discretion**.
- That discretion is **eventually turned over to stewardship itself**.
- The destination is a protocol and network that is fully **steward-led, democratic, and public**.

This is a roadmap, not a claim about today: the democratic destination is an *earned* one, reached as real stewards join — not a status the network asserts before it has them.

**Steward recruitment is mission-aligned.** We look for stewards among the people closest to the network's core missions:

- **Rare disease**
- **Undiagnosed disease**
- **Biodiversity protection** — via conservation genomics, coherent with the network's genome/DNA framing

### Community Input

- Anyone may propose standard changes via the process defined below
- The FA reviews all proposals and provides written rationale for acceptance or rejection
- Community feedback is gathered via GitHub Issues on the aDNA repository

---

## Release Cadence

| Track | Cadence | Scope |
|-------|---------|-------|
| **Standard** (`adna_standard.md` version) | As needed | Normative specification changes — conformance levels, required files, naming rules |
| **Governance** (`CLAUDE.md` version, `CHANGELOG.md`) | Continuous | Operational changes — protocols, templates, skills, tooling |

### Version Numbering

Both tracks use `Major.Minor` versioning:

- **Major** (e.g., v2.x → v3.0): May introduce breaking changes. Requires migration guidance.
- **Minor** (e.g., v2.1 → v2.2): Additive only. MUST NOT invalidate conformant instances.

See `adna_standard.md` §15.4 for the normative backwards compatibility promise.

---

## Backwards Compatibility Promise

This promise is normative (defined in `adna_standard.md` §15.4):

1. **Minor standard versions** MUST NOT invalidate conformant instances. An instance passing Starter/Standard/Full conformance at v2.1 MUST still pass at v2.2.
2. **Major standard versions** MAY introduce breaking changes. When they do:
   - Migration guidance MUST be published before or alongside the release
   - A migration tool or checklist SHOULD be provided
   - The previous major version MUST remain documented for reference
3. **Governance version changes** do not affect standard conformance. A CLAUDE.md update from v5.5 to v6.0 does not require instance changes.

---

## Proposing Standard Changes

### Lightweight RFC Process

1. **Open a GitHub Issue** using the "Change proposal" issue template
2. **Describe**: What you want to change, why, and the impact on existing conformant instances
3. **Classification**: Is this a minor (additive) or major (breaking) change?
4. **Discussion**: Community and FA discuss in the issue
5. **Decision**: FA accepts, modifies, or declines with written rationale
6. **Implementation**: Accepted changes are incorporated into the next standard release

### Change Classification

| Type | Examples | Standard Version Impact |
|------|----------|------------------------|
| **Additive** | New optional field, new conformance check, new appendix | Minor bump (v2.2 → v2.3) |
| **Normative tightening** | SHOULD → MUST for existing recommendation | Major bump (v2.x → v3.0) |
| **Structural** | New required governance file, directory rename | Major bump |
| **Editorial** | Typo fixes, clarifications that don't change requirements | No version bump |

---

## Pre-Release Checklist

Before releasing a new standard version:

- [ ] All normative changes reviewed by FA
- [ ] Backwards compatibility verified for minor versions
- [ ] Migration guidance prepared for major versions
- [ ] `governance_sync_check.sh` reports zero drift
- [ ] `adna_validate.py` passes on the reference instance (adna repo)
- [ ] Example projects still pass their expected conformance level
- [ ] CHANGELOG.md updated with release entry
- [ ] Version strings updated in `adna_standard.md`, `README.md`

---

## Future Governance Evolution

Governance evolves along the **progressive-decentralization** curve above — from a single Founding Architect toward steward-led, public governance. The stages are directional, not automatic thresholds; each transition is a human-gated decision, made as trusted stewards join:

1. **Founding Architect** — a single steward holds decision authority (where the network is today)
2. **Increasing trusted stewards** — mission-aligned stewards enter the process and take on real decisions, at the Founding Architect's discretion, as far as is helpful and positive
3. **Standard Council** (3–5 members) — shared stewardship with majority vote, as discretion is turned over to stewardship itself
4. **Working Groups** — domain-specific groups (e.g., Bio-aDNA, Enterprise-aDNA) that propose extensions
5. **Formal RFC process** — structured proposal documents with review periods

The destination is a protocol and network that is **steward-led, democratic, and public** — governance carried by the communities closest to the mission (rare disease, undiagnosed disease, biodiversity protection), not by any single architect.