Governance Model

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

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 with the standard-change label
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

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.