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

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

← 11. Registry Governance · Section index · 13. Dialect Lifecycle →

12. Distribution Model

12.1 Pull Distribution

The default model: governed applications pull dialect bundles from the registry at subscription time and cache them locally. Re-resolution occurs on:

Application restart
Governance authority directive
Subscription version constraint change
Periodic freshness check (configurable interval)

12.2 Push Notification

The registry pushes notifications to subscribers when:

A new version is published within their version constraint
Their subscribed version is deprecated
A security advisory is issued against their subscribed version
A breaking change is published (MAJOR version) in their dialect lineage

Notifications are advisory. They do not force upgrades. The governance decision to upgrade is organizational, not protocol-mandated.

12.3 Offline Operation

Governed applications MUST be able to operate with a locally cached dialect bundle if the registry is unreachable. The cached bundle carries its own hash and signature; validity does not depend on registry connectivity.

This mirrors AIGP’s fail-open/fail-closed semantics (RFC-010 §2, Principle 4): a governance authority that cannot reach the registry operates on cached state, with degraded freshness but maintained structural validity.

12.4 Bundle Format

A dialect bundle is distributed as a signed, integrity-verified archive:

autonomous_systems-2.1.0.aigp-dialect
├── (all files from §4 structure)
├── SIGNATURE.json   # Publisher signature over bundle hash
└── INTEGRITY.json   # Per-file hashes for tamper detection

The .aigp-dialect extension is a convention. The bundle is a standard archive format (e.g., tar+gzip) with a well-known internal structure.

← 11. Registry Governance · Section index · 13. Dialect Lifecycle →