How stewardship works

AASI stewards the GAA Standard under four recorded principles:

1. Open specification. The specification text is public and evolves through recorded proposals. Decisions about its content are written where implementers and the public can read them.
2. No single-vendor veto. No member — including the founder — can unilaterally block or force a specification change. Steward decisions are recorded with reasons on the proposal of record.
3. Same doors, no first-party privilege. Any vendor, including the founder, enters by conformance only. There is one conformance path and one set of published criteria; the reference implementation is judged by them like any other.
4. Decisions recorded openly. Proposal outcomes, version bumps, and conformance-criteria changes are written down where implementers can read them.

How the founder relates to the Institute

The founding team authored the initial specification text and maintains a reference implementation. Within AASI the founder is one implementer among equals. The reference implementation has no normative status: where the specification text and the implementation disagree, the text governs and the implementation has a defect (or the text has a recorded erratum — decided by the process, not by the founder). The reference implementation's enforcement internals are the founder's own property and are not part of the Standard.

How to propose a change

While the specification is in pre-publication, participation is by invitation; the process below is written so it holds unchanged after the public release.

1. Open a proposal. Describe the problem first — what the specification fails to say, says wrongly, or says ambiguously — then the proposed change, referencing the affected section(s).
2. Discuss in the open. Implementers are encouraged to bring evidence from real implementations. A change no implementation can satisfy is a defect in the change.
3. Steward review. The steward reviews the proposal against the charter's principles and records the outcome: accepted, accepted-with-changes, or declined-with-reasons.
4. Specification change. Accepted proposals land against the specification text, referencing the proposal. Normative wording changes bump the draft version; editorial changes do not.

Ground rules. Normative text is conservative and requires demonstrated need plus at least one implementation sketch. Normative text names no vendor. Text must not present demo or simulated results as production results.

How a version publishes — and how the prior one is kept

The Institute is the keeper of the Standard: it publishes each version, it archives each prior version, and it is what implementers cite. The full cycle:

1. Propose — the problem first, then the change (above).
2. Review — steward review against the charter principles; outcome recorded.
3. Version — accepted changes land against the text; normative changes bump the draft version with a recorded rationale.
4. Publish — the new version becomes the text at /standard/text and gains its entry on the version history, with a per-version citable URL.
5. Archive-prior — the superseded version is preserved as a version of record — never deleted, never silently rewritten.

Each staged or published version is emitted through a governed flow and carries a seal — a tamper-evident record an independent party can re-derive without the Institute's cooperation. The version history page shows the seal beside the version it seals. A standards body whose own change history is verifiable is held to the same standard it publishes; requirement IDs (GAA-*) stay stable through every cycle, so citations survive renumbering.