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
14.3 Delay and Trigger Rules
Orbnetes deployment and release orchestration documentation for operators and platform teams.
Rollback delay introduces controlled wait before rollback execution.
Why delay exists:
- allow transient systems to settle,
- allow short-lived dependencies to recover,
- provide manual intervention window before automatic rollback starts.
Trigger timing model:
- release execution reaches evaluation point,
- failure condition matches policy,
- system waits configured delay,
- rollback release is created/executed.
Operational guidance:
- keep delay short for high-availability critical services,
- use moderate delay when post-deploy checks need warm-up time,
- avoid very long delays unless business process requires manual review window.
Practical recommendation: pair delay with explicit health-check job for predictable trigger behavior.