1 Purpose
This document establishes governance requirements for Document Control Version and Supersession Rules within the defined Good Taste Awards standards system.
2 Scope
This document applies to the requirements, decisions, records, controls, and outputs expressly identified under Document Control Version and Supersession Rules. Award scope and exclusions are defined by GTA-STD-100; this document shall not create an additional award dimension. Operational prerequisites identified here affect assessment validity and never constitute product certification.
3 Authority and interpretation
The Standards Authority owns GTA-GOV-003; the Standards Authority approves it. formal verbs, defined terms, stable requirement identities, policy constants, and generated representations shall be interpreted under GTA-GOV-002, GTA-GOV-005, and the defined registers.
3.1 Registered relationships
| Relationship | Direction | Related document |
|---|---|---|
controls | outbound | GTA-REG-001 |
controls | outbound | GTA-REG-003 |
governed_by | outbound | GTA-GOV-001 |
4 Requirements
GTA-GOV-003-R001 — Document identity
The Standards Authority shall assign one document number, semantic version, title, family, owner, status, visibility, and source path.
GTA-GOV-003-R002 — Active resolution
The Standards Authority shall resolve one active version while preserving every superseded version for reconstruction.
GTA-GOV-003-R003 — Source control
The Standards Authority shall permit amendment only at the registered source and prohibit direct editing of generated outputs.
GTA-GOV-003-R004 — Change classification
The Standards Authority shall classify semantic, technical, editorial, emergency, and withdrawal changes by effect.
GTA-GOV-003-R005 — Impact analysis
The Standards Authority shall identify dependent requirements, procedures, forms, fields, tests, routes, and public representations before approval.
GTA-GOV-003-R006 — Version assignment
The Standards Authority shall apply the defined semantic-version rule consistently to metadata, filenames, routes, and manifests.
GTA-GOV-003-R007 — Activation
The Standards Authority shall activate a version only after approval, validation, build, and publication checks succeed.
GTA-GOV-003-R008 — Supersession
The Standards Authority shall preserve fixed-version access and direct the active route to the confirmed version.
5 Document lifecycle
| State | Entry condition | Permitted effect | Required preservation |
|---|---|---|---|
active | approved source and all release checks passed | active route resolves to this version | source, approval, build, validation, and release evidence |
superseded | a later active version replaces the content | fixed-version route remains available and no new work uses it unless expressly authorized | complete former representation and replacement relationship |
withdrawn | authority removes the document without an active replacement or removes its permitted use | active resolution is removed or redirected to a withdrawal notice | former fixed version, withdrawal basis, affected-scope record, and public status |
Only one active version of a standards document number is permitted. Status changes shall not erase a version or reuse its semantic version. Requirement identifiers and stable anchors shall remain associated with the version in which their text appeared.
6 Change classification and version control
| Change class | Typical effect | Required control |
|---|---|---|
| Major semantic | changes construct, authority, decision outcome, compatibility, public meaning, or required evidence | major-version increment, complete impact analysis, method validation as applicable, and full release review |
| Minor semantic | adds a backward-compatible control, route, field, category parameter, or public capability | minor-version increment, affected validation, dependency review, and full release checks |
| Editorial | corrects language or presentation without changing meaning or implementation | patch-version increment and documented semantic-equivalence review |
| Technical representation | changes schema, build, rendering, search, export, or integrity handling without changing authoritative text | version effect determined by interface compatibility; regression and representation-equivalence evidence required |
| Withdrawal | removes authority or permitted use | status transition, affected-scope analysis, route control, and preserved fixed-version record |
A change package shall contain the former value, proposed value, reason, affected requirements, dependent files, data and interface effects, validation obligations, visibility consequences, migration rule, recovery method, reviewers, and approval disposition. File renaming alone shall not create a new document identity.
7 Activation, supersession, and recovery
Activation shall occur only from a registered source after successful compilation, schema validation, relationship validation, public-projection checks, fixed-version generation, integrity verification, and release authorization. Generated Markdown, structured objects, search records, or reader output shall not be amended directly.
Supersession shall create an explicit replacement relationship and shall move the active route only after the new fixed-version resource is available. Recovery shall restore a previously verified release as a new confirmed activation event; it shall not rewrite the content or history of either release.
8 Conformity and records
Conformity with Document Control Version and Supersession Rules requires evidence comprising the source evidence, defined decision, accountable role, and independent or automated verification. The record for each applicable GTA-GOV-003 requirement shall permit reconstruction without relying on an unrecorded explanation.
Evidence created under GTA-GOV-003 shall use stable identifiers, immutable event sequence numbers, and machine event timestamps. A correction shall be append-only. A nonconformity shall place the affected object in a non-releasable state until its consequence and confirmed disposition are recorded. Role combination remains subject to the mandatory separation rules.