Pack 13 — Releases + Approvals redesigned to be Bundle‑version driven (digest‑first), with SBOM findings + hybrid reachability surfaced as 2nd‑class signals
This pack updates the existing Releases and Approvals areas so every promotion is anchored on an immutable Bundle Version (bundle manifest digest), while keeping the UI familiar and preserving current functionality.
13.1 Menu graph (Mermaid) — Releases + Approvals area (and their cross‑links)
flowchart TD ROOT[Stella Ops Console] --> REL[Releases] ROOT --> APPR[Approvals] ROOT --> RC[Release Control (ROOT)] ROOT --> EVID[Evidence] ROOT --> SEC[Security] ROOT --> OPS[Operations] ROOT --> INT[Integrations] %% Releases REL --> REL_LIST[Releases (Promotions)] REL --> REL_CREATE[Create Promotion] REL --> REL_DETAIL[Promotion Detail] REL_DETAIL --> REL_RUN[Deployment Run (timeline/logs)] REL_DETAIL --> REL_EVID[Evidence Snapshot] REL_DETAIL --> REL_SEC[Security Snapshot] REL_DETAIL --> REL_REACH[Reachability Snapshot] %% Approvals APPR --> APPR_LIST[Approvals Queue] APPR --> APPR_DETAIL[Approval Detail] APPR_DETAIL --> APPR_GATES[Gate Results] APPR_DETAIL --> APPR_RISK[SBOM/Findings + Reachability] APPR_DETAIL --> APPR_EVID[Evidence used for decision] APPR_DETAIL --> APPR_REPLAY[Replay/Verify decision] %% Cross links REL_CREATE -.select bundle version.-> BUNDLE[(Bundle Version Detail)] REL_DETAIL -.references.-> BUNDLE APPR_DETAIL -.references.-> BUNDLE REL_CREATE -.materialize inputs.-> RC REL_CREATE -.inputs from.-> INT REL_DETAIL -.export.-> EVID APPR_DETAIL -.exception request.-> SEC REL_DETAIL -.ops signals.-> OPS APPR_DETAIL -.ops signals.-> OPS
13.2 Releases sub‑graph (Mermaid) — screens and flow
flowchart LR A[Releases (Promotions) List] --> B[Promotion Detail] A --> C[Create Promotion] C --> D[Materialize Bundle → Env] D --> E[Evaluate Gates] E --> F[Request Approval (if needed)] F --> G[Run Workflow / Deploy] G --> B B --> H[Export Evidence] B --> I[Rollback / Re-run]
13.3 Screen — Releases (Promotions) List
Formerly
- Releases (
/releases) Shows release rows with status (Draft/Ready/Deploying/Deployed/Rolled back), env, components count, created, actions.
Why changed like this
The “release” row needs to represent a promotion run of a Bundle Version (digest‑first), not an ad‑hoc component list.
This preserves the list UX, but adds the missing anchors:
- Bundle name + bundle version
- Bundle manifest digest
- SBOM / findings summary
- Data freshness / nightly ops signals (so you don’t approve based on stale feeds or failed rescans)
- Hybrid reachability coverage surfaced as a compact signal (2nd‑class, not a whole new menu)
Screen graph (Mermaid)
flowchart TD A[Releases (Promotions) List] --> B[Filter by Region/Env/Status] A --> C[Open Promotion Detail] A --> D[Create Promotion] A --> E[Open Bundle Version Detail] A --> F[Jump to Approvals (if pending)]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Releases (Promotions) │
│ Legacy name/location: "Releases" (/releases) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Filters: Region [All] Env [All] Status [All] Bundle [search...] Data Health [All] │
│ Actions: [+ Create Promotion] │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ ┌──────────────────────────────┬───────────────┬──────────────┬──────────────┬──────────────┐ │
│ │ Promotion (Bundle Version) │ Env Path │ Status │ Risk Signal │ Data Health │ │
│ ├──────────────────────────────┼───────────────┼──────────────┼──────────────┼──────────────┤ │
│ │ Hotfix Bundle 1.2.4 │ stage→prod │ DEPLOYING │ clean │ OK │ │
│ │ manifest: sha256:abcd... │ US-East │ │ Reach: 1/0/0 │ feeds fresh │ │
│ │ Platform Release 1.3.0-rc1 │ stage→prod │ READY │ 1 crit reach │ WARN │ │
│ │ manifest: sha256:beef... │ EU-West │ │ Reach: 1/0/3 │ NVD stale 3h │ │
│ │ Platform Release 1.2.2 │ prod │ ROLLED BACK │ 2 high reach │ OK │ │
│ └──────────────────────────────┴───────────────┴──────────────┴──────────────┴──────────────┘ │
│ Risk Signal format: Critical reachable / High reachable / High not reachable (and VEX % link) │
│ Data Health: feed freshness + scan job status + integration connectivity (links to Ops) │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
13.4 Screen — Create Promotion (wizard)
Formerly
- + Create Release on
/releases(button) In PoC, this likely created a “release row” with components count, but no explicit bundle version composition workflow.
Why changed like this
Promotion should start by selecting a Bundle Version (already composed in Bundle Organizer), then:
- choose region + env path,
- materialize env-specific inputs (Vault/Consul),
- evaluate policy gates with freshest data,
- create approval request (if required),
- run deployment workflow.
This turns “Create Release” into “Create Promotion” while keeping the Releases menu.
Screen graph (Mermaid)
flowchart TD A[Create Promotion] --> B[Step 1: Select Bundle Version] A --> C[Step 2: Select Region + Env Path] A --> D[Step 3: Materialize Inputs (Vault/Consul)] A --> E[Step 4: Evaluate Gates (policy + data freshness)] A --> F[Step 5: Approval Requirements + Justification] A --> G[Step 6: Launch Promotion / Schedule] G --> H[Promotion Detail]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Create Promotion │
│ Legacy name/location: "+ Create Release" (button on /releases) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Steps: (1) Bundle Version (2) Target Env (3) Inputs (4) Gates (5) Approvals (6) Launch │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ (1) Select Bundle Version │
│ Bundle: [Platform Release ▼] │
│ Version: [1.3.0-rc1 ▼] manifest digest: sha256:beef... │
│ Snapshot: 1 critical reachable | VEX 62% | Reach coverage: Img100/Build78/Run35 │
│ Links: [Open Bundle Version Detail] │
│ │
│ Next → │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
13.5 Screen — Create Promotion Step: Materialize Inputs (Vault/Consul) + bind check
Formerly
Env variables and secrets were implied:
- Vault integration exists under Settings → Integrations
- Release Control had “Environments” but no “promotion-time resolved plan” UI
Why changed like this
This is where your requirement becomes enforceable:
- “bundle becomes deployable to env X with variables from Vault/Consul”
Missing bindings must block (or warn) before you request approvals.
Screen graph (Mermaid)
flowchart LR A[Inputs Materialization] --> B[Resolve from Vault/Consul] A --> C[Detect missing bindings] A --> D[Preview resolved deployment plan] A --> E[Link: Release Control → Env Inputs] A --> F[Continue to Gates]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Create Promotion — Step (3) Inputs (Materialize) │
│ Legacy: scattered across Integrations (Vault) + Release Control (env config) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Target: US-East / us-prod │
│ │
│ Resolution results │
│ ✓ consul service/api-gw/rate_limit_max = 500 │
│ ✓ vault secret/api-gw/jwt_keys = (sealed) │
│ ✗ vault secret/user/db_password = MISSING binding │
│ │
│ Outcome: BLOCKED — cannot proceed to policy evaluation / approval request │
│ Fix: [Open Release Control → US-East/us-prod → Inputs] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
13.6 Screen — Promotion Detail (Release Detail)
Formerly
- Likely “Release detail” behind the eye icon on
/releases(not included in your screenshots, but implied by actions)
Why changed like this
Promotion detail must clearly tie together:
- bundle version identity (digest-first),
- gate outcome + explanation,
- SBOM findings summary by env,
- hybrid reachability coverage for confidence,
- ops data health (feeds/rescans/integrations),
- evidence snapshot and export.
Hybrid reachability remains 2nd‑class: a tab/section, not its own menu.
Screen graph (Mermaid)
flowchart TD A[Promotion Detail] --> B[Overview] A --> C[Gate Trace (why pass/block)] A --> D[Security Snapshot (SBOM findings)] A --> E[Reachability Snapshot (image/build/runtime)] A --> F[Deployment Run Timeline] A --> G[Evidence Snapshot + Export] A --> H[Ops/Data Health] A --> I[Diff vs previous deployed bundle]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Promotion: Platform Release 1.3.0-rc1 (manifest sha256:beef...) │
│ Legacy name/location: Release detail from "Releases" (/releases) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Env Path: EU-West / eu-stage → eu-prod Status: READY Workflow: Canary 10→50→100 │
│ Requested by: alice.johnson Justification: scheduled release w/ rate limiting + bug fixes │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Tabs: [Overview] [Gates] [Security] [Reachability] [Run] [Evidence] [Ops/Data] [Diff] │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Overview │
│ Risk summary: 1 critical reachable (eu-prod) | 0 high reachable | 3 high not reachable │
│ VEX coverage: 62% │
│ Data health: WARN — NVD feed stale 3h; last rescan job failed (worker) │
│ │
│ Actions: [Request Approval] [Run Now] [Schedule] [Export Evidence] [Rollback (if running)] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
13.7 Screen — Promotion Detail: Gates (explain “why” + tie to freshness)
Formerly
“Policy Gates” summary existed on Approvals cards (“PASS/BLOCK”) but lacked:
- structured trace,
- explicit linkage to data freshness and job state.
Why changed like this
Stella’s value is “explain every decision” / deterministic traceability.
Gate trace must include:
- what inputs were used (bundle digest, env, policy baseline),
- whether CVE feeds were fresh,
- whether SBOM scans completed,
- reachability evidence quality (warn/block based on baseline).
Screen graph (Mermaid)
flowchart LR A[Gates Tab] --> B[Gate Results Table] A --> C[Gate Trace Detail (inputs + evidence)] A --> D[Replay evaluation] A --> E[Link to Exception Request]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Gates — Platform Release 1.3.0-rc1 → EU-West/eu-prod │
│ Legacy: Approvals cards showed PASS/BLOCK without full trace │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Baseline: Prod-EU-West | Evaluated: Feb 18, 08:30 | Data: NVD stale 3h (warn threshold 2h) │
│ │
│ ┌──────────────────────────────┬──────────┬──────────────────────────────────────────────────┐ │
│ │ Gate │ Result │ Why │ │
│ ├──────────────────────────────┼──────────┼──────────────────────────────────────────────────┤ │
│ │ SBOM scans complete │ FAIL │ worker digest pending scan (required for prod) │ │
│ │ Critical reachable CVEs │ FAIL │ CVE-XXXX reachable in eu-prod (no VEX) │ │
│ │ Feed freshness │ WARN │ NVD last sync 3h │ │
│ │ Reachability coverage runtime │ WARN │ runtime evidence 35% (policy warn) │ │
│ └──────────────────────────────┴──────────┴──────────────────────────────────────────────────┘ │
│ Actions: [Replay Gate Eval] [Request Exception] [Open Findings] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
13.8 Approvals sub‑graph (Mermaid) — screens and flow
flowchart TD A[Approvals Queue] --> B[Approval Detail] B --> C[Approve / Reject] B --> D[View Gate Trace] B --> E[View Security Snapshot] B --> F[View Evidence] B --> G[Request Exception] C --> H[Promotion continues / deploy run starts]
13.9 Screen — Approvals Queue
Formerly
- Approvals (
/approvals) Shows pending items with justification, policy gates PASS/BLOCK, approvals count, approve/reject buttons.
Why changed like this
Approval items must reference:
- the Bundle Version (manifest digest),
- the target region/env path,
- SBOM findings summary (critical reachable per env),
- hybrid reachability confidence,
- data freshness / nightly job issues that might invalidate the scan picture.
This allows reviewers to answer: “Is this safe to promote right now?”
Screen graph (Mermaid)
flowchart LR A[Approvals Queue] --> B[Filter by Region/Env/Status/Risk] A --> C[Open Approval Detail] A --> D[Jump to Promotion Detail] A --> E[Jump to Bundle Version Detail]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Approvals │
│ Legacy name/location: "Approvals" (/approvals) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Filters: Status [Pending] Region [All] Env [All] Risk [All] Data Health [All] │
│ │
│ Results (2) │
│ ┌──────────────────────────────────────────────────────────────────────────────────────────┐ │
│ │ Platform Release 1.3.0-rc1 (manifest sha256:beef...) eu-stage → eu-prod │ │
│ │ Justification: scheduled release with rate limiting feature and bug fixes. │ │
│ │ Gates: BLOCK (2/4) Approvals: 0/2 │ │
│ │ Risk: 1 critical reachable (eu-prod) | VEX 62% | Reach Img100/Build78/Run35 │ │
│ │ Data health: WARN (NVD stale 3h; rescan job failed) │ │
│ │ [Approve] [Reject] [View Details] │ │
│ └──────────────────────────────────────────────────────────────────────────────────────────┘ │
│ ┌──────────────────────────────────────────────────────────────────────────────────────────┐ │
│ │ Hotfix Bundle 1.2.4 (manifest sha256:abcd...) us-stage → us-prod │ │
│ │ Justification: critical fix for user authentication timeout issue. │ │
│ │ Gates: PASS (4/4) Approvals: 1/2 │ │
│ │ Risk: clean | Reach Img100/Build100/Run80 │ │
│ │ Data health: OK │ │
│ │ [Approve] [Reject] [View Details] │ │
│ └──────────────────────────────────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
13.10 Screen — Approval Detail (decision packet)
Formerly
Likely behind “View Details” on
/approvals(not shown), plus scattered info across:- Security overview/findings,
- Evidence exports,
- Replay/Verify.
Why changed like this
Approval is the decision choke point; it must show:
- what is being approved (bundle digest),
- what env(s) are impacted,
- why gates pass/block,
- SBOM findings and reachability evidence quality,
- evidence pointers for audit,
- replay/verify capability.
Screen graph (Mermaid)
flowchart TD A[Approval Detail] --> B[Decision Overview] A --> C[Gate Results + Trace] A --> D[SBOM Findings (by env)] A --> E[Reachability (image/build/runtime)] A --> F[Evidence used] A --> G[Ops/Data Health] A --> H[Replay/Verify] A --> I[Approve/Reject actions]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Approval: Platform Release 1.3.0-rc1 → EU-West/eu-prod │
│ Legacy name/location: Approval detail from "Approvals" (/approvals) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Bundle version: Platform Release 1.3.0-rc1 │
│ Manifest digest: sha256:beef... Requested by: alice.johnson Requested: 36d ago │
│ Env path: eu-stage → eu-prod Workflow: Canary 10→50→100 │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Tabs: [Overview] [Gates] [Security] [Reachability] [Evidence] [Ops/Data] [Replay/Verify] │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Overview │
│ Current gate state: BLOCK │
│ Blocking reasons: (1) critical reachable CVE without VEX (2) SBOM scan incomplete │
│ │
│ Actions: [Approve] (disabled) [Reject] [Request Exception] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
13.11 Approval Detail: Security tab (SBOM findings by env + “what changed”)
Formerly
- Security summary existed, but disconnected from the approval object and env context.
Why changed like this
Approvals must be grounded in:
- which environments have critical reachable issues,
- and whether they are already present (“existing risk”) or introduced by this promotion (“delta”).
Screen graph (Mermaid)
flowchart LR A[Security Tab] --> B[Findings summary by severity + reachability] A --> C[By environment breakdown] A --> D[Delta vs currently deployed bundle in target env] A --> E[Open Finding detail / VEX]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Security — Approval Detail │
│ Legacy: Security Overview/Findings were separate from Approvals │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Summary (target env: eu-prod) │
│ Critical reachable: 1 High reachable: 0 High not reachable: 3 VEX coverage: 62% │
│ │
│ By environment │
│ eu-stage: 0 critical reachable │
│ eu-prod : 1 critical reachable (CVE-XXXX in user-service sha256:2222...) │
│ │
│ Delta (vs currently deployed bundle in eu-prod) │
│ +1 critical reachable introduced by this promotion │
│ Links: [Open Finding] [Open Component Version] [Open VEX Statement] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
13.12 Approval Detail: Reachability tab (hybrid reachability as 2nd‑class)
Formerly
- Reachability appeared conceptually in approvals (“policy + reachability”) but without clear sourcing.
Why changed like this
You require hybrid reachability from:
- image (Dover scan),
- build evidence,
- runtime evidence.
This must be visible during approvals but stays 2nd‑class (tab).
Screen graph (Mermaid)
flowchart TD A[Reachability Tab] --> B[Coverage metrics: image/build/runtime] A --> C[Evidence sources list] A --> D[Policy interpretation (warn/block thresholds)] A --> E[Drill into component reachability]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Reachability — Approval Detail │
│ Legacy: reachability referenced but not clearly sourced │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Coverage (for bundle version) │
│ Image evidence: 100% Build evidence: 78% Runtime evidence: 35% │
│ │
│ Interpretation (baseline Prod-EU-West) │
│ • Runtime coverage < 50% → WARN (does not block) │
│ • Critical reachable requires runtime evidence OR VEX override → BLOCK │
│ │
│ Component breakdown │
│ user-service sha256:2222... Image ✓ Build ✗ Runtime ✗ │
│ api-gateway sha256:1111... Image ✓ Build ✓ Runtime ✗ │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
13.13 Approval Detail: Ops/Data tab (nightly job + feed + integration health)
Formerly
- Feeds freshness: Operations → Feeds
- Background jobs: System → Background Jobs
- Integrations: Settings → Integrations
- None were summarized at approval time.
Why changed like this
Approvals must warn if:
- CVE feeds are stale,
- SBOM rescans failing,
- integrations disconnected (e.g., Vault/Registry/CI), because decision confidence is reduced.
Screen graph (Mermaid)
flowchart LR A[Ops/Data Tab] --> B[Feed freshness (NVD/OSV)] A --> C[SBOM rescan job status] A --> D[Integration connectivity] A --> E[Links: Ops/System/Integrations]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Ops/Data Health — Approval Detail │
│ Legacy: separate screens (Ops Feeds, System Jobs, Integrations) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Feeds │
│ OSV: synced 20m ago (OK) │
│ NVD: synced 3h ago (WARN; threshold 2h) │
│ │
│ Nightly jobs │
│ SBOM rescan (worker sha256:4444...): FAILED (last run 1h ago) │
│ Reachability import (runtime): RUNNING │
│ │
│ Integrations │
│ Registry: OK CI/CD: DEGRADED (Jenkins) Vault: OK │
│ Links: [Open Ops Feeds] [Open System Jobs] [Open Integrations] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
What stays the same (so we preserve PoC functionality)
- Releases list still shows statuses like Draft/Ready/Deploying/Deployed/Rolled back.
- Approvals queue still has Approve/Reject and the same “requested by + justification” feel.
- Promotion path concept (staging → production) remains identical — now region‑scoped and bundle‑version‑anchored.
If you say “continue”, Pack 14 will cover the Release Run / Deployment timeline screen (logs, checkpoints, rollback triggers, evidence capture points) and how it ties into Replay/Verify and Evidence Export without adding new top‑level clutter.