RFC-038: Domain of Concern Registry — AIGP Dialects as First-Class Artifacts — 5. Versioning Model

AIGP Specification › RFC-038: Domain of Concern Registry — AIGP Dialects as First-Class Artifacts › 5. Versioning Model

← 4. Dialect Structure · Section index · 6. Registry Operations →

5. Versioning Model

5.1 Semantic Versioning for Observation Apparatus

Dialects follow semantic versioning (MAJOR.MINOR.PATCH) with domain-specific semantics:

Change Type	Version Increment	Meaning	Subscriber Impact
Variable added	MINOR	New observable dimension; existing calculations unaffected	Existing subscriptions remain valid; new variable is optional until next MAJOR
Variable removed	MAJOR	Observable dimension eliminated; existing calculations may break	Subscribers MUST upgrade or declare exemption
Variable type/scale changed	MAJOR	Measurement semantics altered; gap operators may change	Subscribers MUST upgrade
Threshold tightened (default profile)	MINOR	Higher bar for passing; existing evidence may now trigger gaps	Subscribers MAY override via Local Profile
Threshold relaxed (default profile)	MINOR	Lower bar for passing	Subscribers MAY override via Local Profile
Hard stop added	MAJOR	New circuit-break condition; existing workflows may halt	Subscribers MUST acknowledge
Hard stop removed	MAJOR	Safety regression; existing protections removed	Subscribers MUST explicitly accept
Observer requirement changed	MAJOR	Who may verdict has changed	Subscribers MUST re-accredit
Evidence admissibility floor raised	MINOR	Higher evidence quality required; weak evidence becomes inadmissible	Subscribers with Level 3+ evidence unaffected
Extraction method refined	PATCH	Implementation detail; same measurement semantics	Transparent to subscribers
Documentation/description update	PATCH	No behavioral change	Transparent to subscribers
Warrant or backing updated	PATCH	Argumentative support improved; no structural change	Transparent to subscribers

5.2 Immutability Invariant

A published dialect version is immutable. Once autonomous_systems@2.1.0 is published to a registry, its content MUST NOT change. Any correction — including typo fixes — produces a new version (2.1.1).

This mirrors the scientific requirement: a published research protocol is a historical record. Corrections are published as amendments, not silent edits.

5.3 Deprecation

A dialect version MAY be deprecated but MUST NOT be deleted. Deprecated versions carry a deprecated_at timestamp and a successor pointer:

{
  "version": "1.3.0",
  "deprecated_at": "2026-09-01T00:00:00Z",
  "successor": "2.0.0",
  "deprecation_reason": "Variable type violations corrected in 2.x series; 1.x permits ordinal aggregation that violates Stevens constraint."
}

Subscribers to deprecated versions receive governance warnings but are not forcibly migrated. The choice to upgrade is a governance decision, not a protocol enforcement.

5.4 Pre-Release and Draft Dialects

Dialects MAY be published as pre-release (2.0.0-rc.1, 3.0.0-alpha.1). Pre-release dialects:

MUST NOT be used in production governance without explicit organizational acceptance
MAY be used for evaluation, testing, and calibration
Are NOT subject to the immutability invariant (they may be withdrawn)
Do NOT trigger subscription notifications unless the subscriber opts into pre-release channels

← 4. Dialect Structure · Section index · 6. Registry Operations →