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
7.2 Notifications Settings
Orbnetes deployment and release orchestration documentation for operators and platform teams.
Notification settings define how Orbnetes sends operational events to users.
Typical responsibilities:
- Enable/disable notification subsystem.
- Select provider type (SMTP/API transport if supported).
- Define sender identity (
fromemail/name). - Store required credentials for delivery backend.
Event sources usually include:
- release lifecycle changes,
- approval requests and approval state changes,
- pipeline/run completion states (success/fail/cancel),
- comments or governance-related actions.
Signal quality strategy:
- Start with high-value events (failure, approval required, canceled).
- Add additional events only when teams prove they are actionable.
- Avoid notification fatigue by tuning project-level overrides.
Validation checklist after config change:
- test email delivery from platform,
- verify sender identity appears correctly,
- verify event templates include direct links to relevant pages.