Versioning & Release Structure
Governance systems require deterministic change management. This page defines how Layer-7 versions its schemas, policies, models, and releases to preserve backward compatibility and audit integrity.
If versioning is unclear, accountability is unclear.
Semantic Versioning Model
MAJOR.MINOR.PATCH
MAJOR → Breaking schema or contract change
MINOR → Backward-compatible feature addition
PATCH → Bug fix or documentation update
Schema Version
Applies to decision objects, ledger events, and API contracts.
Policy Version
Independent version track for governance rulesets.
Engine Version
Runtime implementation of policy enforcement logic.
Version Scope Separation
| Component | Versioned? | Rollback Allowed? |
|---|---|---|
| Schema | Yes | Only if backward compatible |
| Policy | Yes (Signed) | Signed rollback only |
| Ledger | Append-only | No rollback permitted |
| Risk Model | Yes | Documented downgrade path |
Ledger integrity supersedes release convenience.
Release Channels
Stable
Production-certified release. Fully audited.
Candidate
Pre-production validation build.
Experimental
Feature testing. Not certified for regulated environments.
Deprecated
Sunset version. Migration required.
Backward Compatibility Rules
- No schema mutation after ledger writes.
- Minor releases must not invalidate prior decisions.
- Policy updates cannot retroactively alter historical decisions.
- Breaking changes require MAJOR increment and migration documentation.
Governance history cannot be rewritten to match new policy.
Release Documentation Structure
Release: 1.2.0
Date: YYYY-MM-DD
Changes:
– Added risk band “critical”
– Improved ledger anchoring validation
– Minor API contract update
Impact:
– No breaking changes
Migration Required: No
Every release must document impact and migration requirements.