3.1 Control Plane vs Agent Execution Plane
3.2 Project Scope Model
3.3 Data Flow: Source -> Release -> Pipeline -> Logs/Artifacts
3.4 Runtime Configuration Layers (global / project / environment)
3.5 Pipeline Execution Semantics
3.6 Release Governance Path
3.7 Rollback Architecture (Policy-driven)
3.8 Security and Trust Boundaries
3.9 State and Persistence Model
3.10 Scalability Model
3.11 Failure Modes and Recovery Patterns
3.12 Why This Architecture Works in Practice
23.4 Versioning and Changelog Guidance
Orbnetes deployment and release orchestration documentation for operators and platform teams.
Versioning and Changelog Guidance
Versioning strategy
Use semantic versioning where possible: MAJOR.MINOR.PATCH (for example v1.4.2, v2.0.0).
When semantic versioning is not available, use immutable build identifiers (for example 2026.03.12+build.184, release-2026-03-12-rc1).
Changelog structure
Use clear sections: Added, Changed, Fixed, Security.
Example entry:
## [1.1.8] - 2026-03-10
### Added
- Added rollback policy UI support for selected version source resolution.
### Changed
- Improved release creation redirect behavior for approval-gated flow.
### Fixed
- Fixed dynamic source/tag/file loading in rollback selected version mode.
### Security
- Clarified token and credential handling guidance in documentation.
Operational guidance
- Update changelog before release tag is published.
- Include behavior changes, not just code internals.
- Reference release ID/pipeline evidence for high-impact fixes.
- Keep entries concise and operator-focused.
Recommended release note minimum
- What changed.
- Who is affected.
- Any migration/behavior impact.
- Rollback guidance if needed.
This keeps technical and operational teams aligned during rollout and incident response.