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
3.3 Data Flow: Source -> Release -> Pipeline -> Logs/Artifacts
Orbnetes deployment and release orchestration documentation for operators and platform teams.
3.3.1 Source Resolution
A release source (GitHub/GitLab/URL/Storage) provides:
- tags/versions,
- selected release file,
- metadata (author, notes, timestamps, URLs where available).
3.3.2 Release Creation
Release binds together:
- blueprint,
- selected source + tag + file,
- configuration environments,
- launch inputs,
- optional approvers,
- optional rollback policy.
3.3.3 Deployment Expansion
For each selected configuration environment, Orbnetes creates deployment/run units according to deployment mode (parallel/sequential policy context).
3.3.4 Pipeline Materialization
Blueprint YAML is compiled into executable jobs:
- dependencies resolved (
needsDAG), - conditions attached (
if), - failure semantics attached (
allow_failure), - runtime context injected (inputs, vars, secrets, release file path).
3.3.5 Agent Execution
Agents claim eligible jobs by tag and status:
- execute step commands,
- report run status and progress,
- send step logs continuously,
- report artifacts and execution metadata.
3.3.6 Observability and Traceability
Control plane persists:
- release/deployment/job/run status transitions,
- live and historical logs,
- artifact records,
- audit events and actor identity.
This creates an end-to-end chain from selected release file to executed step output.