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
19.1 Audit Log Model
Orbnetes deployment and release orchestration documentation for operators and platform teams.
Orbnetes audit and compliance capabilities are built around one principle: every critical operational action should be traceable to an actor, timestamp, and affected object.
This section explains how audit data is modeled, queried, and used in operational governance.
The Audit Log records security- and operation-relevant events generated by user/API/system actions.
Typical audit record components:
- timestamp (when event happened),
- actor (user/API identity),
- action (what happened),
- resource type (release, blueprint, project, secret, etc.),
- resource id/reference (which object was affected),
- metadata/context (project, status, key fields, request context where applicable).
Design intent:
- support incident reconstruction,
- support access/governance review,
- support compliance evidence export.
Audit scope should include at minimum:
- release create/approve/cancel/rerun related actions,
- blueprint create/update/delete actions,
- secret/variable/environment changes,
- agent update/configuration actions,
- user/permission changes.