This pack gives you: (1) Mermaid for the Release Control menu and every screen flow, (2) an ASCII mock per screen, and (3) “Formerly / Why changed” per screen. It also adds the missing Release Bundle Organizer (digest→version, Vault/Consul-derived env variables, per-repo changelog, bundle composition).

flowchart TD
  RC[Release Control] --> RC_HOME[Control Plane]
  RC --> RC_BUNDLES[Bundles]
  RC --> RC_RELEASES[Releases]
  RC --> RC_APPROVALS[Approvals]
  RC --> RC_ENV[Regions & Environments]
  RC --> RC_DELIVERY[Delivery]

  RC_BUNDLES --> B_CAT[Bundle Catalog]
  RC_BUNDLES --> B_ORG[Bundle Organizer]
  RC_BUNDLES --> B_REPOS[Repositories & Versions]

  B_CAT --> B_DETAIL[Bundle Detail]
  B_ORG --> B_DETAIL

  RC_RELEASES --> R_LIST[Releases List]
  R_LIST --> R_DETAIL[Release Detail]

  RC_APPROVALS --> A_QUEUE[Approvals Queue]
  A_QUEUE --> A_DETAIL[Approval Detail]

  RC_ENV --> REG_OV[Region Overview]
  REG_OV --> ENV_DETAIL[Environment Detail]
  RC_ENV --> PROMO[Promotion Paths]

  RC_DELIVERY --> TARGETS[Targets]
  RC_DELIVERY --> AGENTS[Agents]
  RC_DELIVERY --> WF[Workflows]

Design intent: Release Control is where you compose, promote, and govern releases/hotfixes—with bundles as the organizing primitive, regions first, and security/evidence surfaced at decision points.

2) Release Control → Control Plane

Previously

Formerly: Control Plane (top-level) Showed environment pipeline (Dev/Staging/UAT/Prod), pending approvals, active deployments, recent releases.

Now (Redesign)

Now: Release Control → Control Plane Adds:
- Region-first pipeline (tabs or left rail: eu-west, us-east, etc.)
- Per-env SBOM posture (not just deploy health): critical reachable, SBOM freshness, reachability coverage
- Nightly Jobs / Data Health summary (feeds, rescan backlog, integration connectivity)
- Quick jumps into Bundles, Approvals, Environment Detail, Nightly Ops Report

Why changed

This page must drive release governance. The first question is not “what deployed?” but: “What can be safely promoted in each region, given current SBOM + reachability + feed health?”

Screen graph (Mermaid)

flowchart TD
  CP[Release Control: Control Plane] --> A[Approvals Queue]
  CP --> R[Releases List]
  CP --> B[Bundle Catalog]
  CP --> E[Environment Detail]
  CP --> P[Promotion Paths]
  CP --> S[Security Overview]
  CP --> N[Operations: Nightly Ops Report]
  CP --> I[Integrations: Status]
  CP --> EV[Evidence & Audit: Export Center]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASE CONTROL ▸ CONTROL PLANE                                              [Create Bundle]   │
│ Formerly: Control Plane                                                                             │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Region: [All ▾]  eu-west  us-east  ap-south                         Time: Last 24h ▾           │
│ Data Health: OSV OK | NVD STALE | Registry OK | Vault OK | Jenkins DEGRADED → [Nightly Ops]     │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ REGION PIPELINE (env status + SBOM posture)                                                     │
│ ┌───────────────┐  ┌───────────────┐  ┌───────────────┐  ┌───────────────┐                    │
│ │ Dev           │→ │ Staging       │→ │ UAT           │→ │ Production    │                    │
│ │ Deploy: OK    │  │ Deploy: OK    │  │ Deploy: ?     │  │ Deploy: DEG   │                    │
│ │ SBOM: 0 crit  │  │ SBOM: 1 crit* │  │ SBOM: -       │  │ SBOM: 5 crit* │                    │
│ │ ReachCov: 72% │  │ ReachCov: 81% │  │ ReachCov: -   │  │ ReachCov: 58% │                    │
│ │ [Open]        │  │ [Open]        │  │ [Open]        │  │ [Open]        │                    │
│ └───────────────┘  └───────────────┘  └───────────────┘  └───────────────┘                    │
│ *crit = critical reachable                                                                       │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ PENDING APPROVALS (region/env aware)                     ACTIVE DEPLOYMENTS                      │
│ - api-gateway@bundle v2.1.0  staging→prod  PASS 1/2     - hotfix 1.2.4  prod-eu   RUNNING       │
│ - user-service@bundle v3.0.0  staging→prod  BLOCK 0/2    [View All]                               │
│ [View Approvals]                                                                             │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ BUNDLES READY / AT RISK                                                                            │
│ - Bundle: platform@v1.3.0-rc1  Staging  SBOM: clean  Evidence: 92%  [Open Bundle]               │
│ - Bundle: api-gateway@v2.1.0   Prod     SBOM: 3 crit* NVD stale      [Open Findings]            │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

3) Release Control → Bundles → Bundle Catalog

Previously

Formerly: no explicit bundle concept.
- Bundling was implied by Releases and “components count”.
- Digest was primary; “bundle organization” and “per-repo changelog” were not first-class.

Now (Redesign)

Now: Release Control → Bundles → Bundle Catalog
- Lists Bundle Versions as the thing that gets promoted
- Shows security posture per bundle (critical reachable counts, reachability coverage)
- Shows evidence completeness (is the bundle audit-ready)
- One click to “Create Release” or “Request Approval” in a region/env

Why changed

StellaOps is “promote by digest,” but humans and auditors reason in versions and bundles:

“api-gateway v2.1.0 in prod-eu” (bundle version)
“what changed since v2.0.9” (changelog)
“what config snapshot was used” (Vault/Consul references)

Screen graph (Mermaid)

flowchart TD
  BC[Bundle Catalog] --> BD[Bundle Detail]
  BC --> BO[Bundle Organizer]
  BC --> RV[Repositories & Versions]
  BC --> AQ[Approvals Queue]
  BC --> RL[Releases List]
  BC --> SF[Security Findings (filtered)]
  BC --> EV[Evidence & Audit: Export Center]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASE CONTROL ▸ BUNDLES ▸ CATALOG                                        [ + Create Bundle ] │
│ Formerly: (N/A) Bundles were implicit under Releases/components                                     │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Filters: Repo ▾  Bundle Name ▾  Version ▾  Region ▾  Env ▾  SBOM Status ▾  Evidence ▾           │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Bundle                Version     Repo Scope     SBOM (crit*)  ReachCov  Evidence  Actions      │
│-------------------------------------------------------------------------------------------------│
│ api-gateway           v2.1.0      gateway-repo   3 crit*        81%       88%      [Open] [Rel] │
│ user-service          v3.0.0-rc1  user-repo      0              77%       91%      [Open] [Rel] │
│ platform              v1.3.0-rc1  multi-repo     1 high*        66%       74%      [Open] [Rel] │
│ *crit* = critical reachable (hybrid reachability)                                                 │
│ [Rel] = Create Release / Request Approval                                                          │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

4) Release Control → Bundles → Bundle Organizer (the missing core)

Previously

Formerly: partial/implicit across:
- Releases (components count)
- SCM/CI (outside StellaOps) for composing “what is in a release”
- Vault/Consul config was not attached as a release artifact
- No consistent “digest→version” mapping with changelog & config snapshot

Now (Redesign)

Now: Release Control → Bundles → Bundle Organizer
- Digest→Version: a microservice digest becomes a bundle version (semver/rc)
- Bundle composition: multiple microservices + their pinned digests/versions
- Env variables: references to Vault and Consul keys used for a given env/region (store pointers + redacted resolved values, not secrets)
- Per-repo changelog: commits/tags between prior version and new digest
- Built-in “security/evidence readiness” before generating a release/approval

Why changed

This is the governance kernel: what exactly is being promoted, with what config, and what changed, in a form that is exportable as evidence.

Screen graph (Mermaid)

flowchart TD
  BO[Bundle Organizer] --> BD[Bundle Detail]
  BO --> RV[Repositories & Versions]
  BO --> INT[Integrations: SCM/CI/Registry/Vault/Consul]
  BO --> SF[Security Findings (bundle filtered)]
  BO --> EV[Evidence & Audit: Proof Chain + Export]
  BO --> REL[Create Release]
  BO --> APR[Request Approval]

ASCII mock (tabs show bundle composition + config + changelog)

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASE CONTROL ▸ BUNDLES ▸ ORGANIZER: Create/Update Bundle                                     │
│ Formerly: (N/A) Composition lived across CI/CD + Releases list                                   │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Bundle: [api-gateway]   Version: [v2.1.0 ▾]   Region: [eu-west ▾]  Target Env: [staging→prod ▾] │
│ Repo(s): gateway-repo, auth-repo, shared-lib-repo                                                   │
│ Tabs: [Components] [Config (Vault/Consul)] [Changelog] [Security] [Evidence]                      │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ COMPONENTS                                                                                       │
│ Service/Microservice     Digest (registry)                 Derived Version   SBOM   Reach (H/B/I/R) │
│-------------------------------------------------------------------------------------------------│
│ api-gateway              sha256:abc...                     v2.1.0            OK     YES/NO/YES/YES │
│ auth-sidecar             sha256:def...                     v1.8.4            WARN   NO/NO/YES/NO   │
│ shared-config             git: tag v4.2.0 → v4.2.1         v4.2.1            -      -              │
│ [ + Add service ]  [Auto-derive versions]  [Pin digests]                                         │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ CONFIG (Vault / Consul) (stored as references + redacted snapshot)                               │
│ Vault paths:   kv/prod/eu-west/api-gateway/*     (status: connected)                              │
│ Consul prefix: eu-west/prod/api-gateway/         (status: connected)                              │
│ Resolved variables (redacted):  RATE_LIMIT=***  DB_HOST=***  FEATURE_FLAG_X=***                   │
│ [Validate access] [Snapshot config refs] [Diff vs previous bundle]                                │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ CHANGELOG (per repository)                                                                        │
│ gateway-repo:  v2.0.9 → digest abc...   12 commits  3 PRs   [View]                                 │
│ auth-repo:     v1.8.3 → digest def...   4 commits   1 PR    [View]                                 │
│ [Generate release notes] [Attach links]                                                           │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ ACTIONS                                                                                           │
│ [Save Bundle Draft]  [Sign Bundle]  [Create Release]  [Request Approval]                          │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

Reachability note: the table explicitly shows Hybrid/Build/Image(Dover)/Runtime reach flags (second-class, not buried).

5) Release Control → Bundles → Bundle Detail

Previously

Formerly: fragmented:
- Release row detail (not dedicated)
- Evidence scattered under Evidence menu
- Config (Vault/Consul) not attached as a release artifact

Now (Redesign)

Now: Release Control → Bundles → Bundle Detail
- Shows: components + digests + derived versions
- Config snapshot pointers (Vault/Consul)
- Security posture (crit reachable, VEX coverage)
- Evidence readiness + export
- Buttons: create release, request approval, open findings

Why changed

Bundle Detail is the canonical “what is this thing?” page used by:

release managers,
security reviewers,
auditors.

Screen graph (Mermaid)

flowchart TD
  BD[Bundle Detail] --> BO[Bundle Organizer]
  BD --> REL[Create Release]
  BD --> APR[Request Approval]
  BD --> SF[Security Findings (bundle filtered)]
  BD --> VEX[VEX Hub (bundle filtered)]
  BD --> ENV[Environment Detail (where deployed)]
  BD --> EV[Evidence & Audit: Export Bundle]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASE CONTROL ▸ BUNDLES ▸ DETAIL: api-gateway v2.1.0                                           │
│ Formerly: (N/A) This information was split across Releases + external CI/CD                      │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Scope: Region eu-west  | Promotion: staging → production                                         │
│ Security: Critical reachable: 3  High reachable: 1  VEX: awaiting 2                               │
│ Data provenance: SBOM snapshot 2026-02-18T02:00Z | CVE dataset OSV OK | NVD STALE                 │
│ Actions: [Edit Bundle] [Create Release] [Request Approval] [Export Evidence]                     │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ COMPONENTS (pinned)                                                                              │
│ - api-gateway v2.1.0   digest sha256:abc...                                                       │
│ - auth-sidecar v1.8.4  digest sha256:def...                                                       │
│ - shared-config v4.2.1 git tag                                                                    │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ CONFIG REFERENCES                                                                                │
│ Vault: kv/prod/eu-west/api-gateway/*    Consul: eu-west/prod/api-gateway/*                       │
│ Config diff vs previous: 7 keys changed (redacted)  [View Diff]                                  │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ DEPLOYMENT FOOTPRINT                                                                             │
│ Deployed in: staging-eu (YES)  prod-eu (NO)  runtime inventory fresh: 54%                         │
│ [Open Environment Detail]                                                                        │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

6) Release Control → Bundles → Repositories & Versions

Previously

Formerly: implicit across SCM tags and container registries; StellaOps didn’t own the “digest→version lineage”.

Now (Redesign)

Now: Release Control → Bundles → Repositories & Versions
- Per repo:
  - last built digests
  - derived versions
  - SBOM status + scan freshness
  - changelog anchors (tags/commits)
- Feeds into Bundle Organizer

Why changed

You can’t do bundle governance without a stable mapping from: repo changes → artifact digest → bundle version → release approval decision.

Screen graph (Mermaid)

flowchart TD
  RV[Repositories & Versions] --> BO[Bundle Organizer]
  RV --> BD[Bundle Detail (filtered)]
  RV --> INT[Integrations: SCM/Registry/CI]
  RV --> SF[Security Findings (repo/component filtered)]
  RV --> N[Operations: Nightly Ops Report (failed scans/builds)]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASE CONTROL ▸ BUNDLES ▸ REPOSITORIES & VERSIONS                                              │
│ Formerly: (N/A) Versioning lineage lived outside StellaOps                                       │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Repo: [gateway-repo ▾]   Branch: main ▾   Time: Last 30d ▾                                       │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Digest                 Derived Version   Built By    SBOM Fresh   Crit*   Notes                  │
│-------------------------------------------------------------------------------------------------│
│ sha256:abc...          v2.1.0           Jenkins     <24h         3       used in prod-eu? NO    │
│ sha256:aaa...          v2.0.9           Jenkins     7d           0       previous stable        │
│ Actions: [Open in Bundle Organizer] [View Changelog] [View Findings]                              │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

7) Release Control → Releases → Releases List

Previously

Formerly: Releases (top-level) /releases
- Listed releases with status, env, components, created, actions.

Now (Redesign)

Now: Release Control → Releases → Releases List
- Adds:
  - Region filter and region column
  - Bundle link (release points to a bundle version)
  - Security snapshot at time of release creation (crit reachable, feed status)
  - Evidence readiness (quick indicator)

Why changed

A release is the execution of promoting a bundle into a region/env—with a captured security/evidence snapshot.

Screen graph (Mermaid)

flowchart TD
  RL[Releases List] --> RD[Release Detail]
  RL --> BD[Bundle Detail]
  RL --> AQ[Approvals Queue (filtered)]
  RL --> ENV[Environment Detail]
  RL --> EV[Evidence & Audit: Export Center]
  RL --> SF[Security Findings (release snapshot)]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASE CONTROL ▸ RELEASES ▸ LIST                                           [ + Create Release ]│
│ Formerly: Releases (top-level) /releases                                                      │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Filters: Status ▾  Region ▾  Env ▾  Bundle ▾  Type ▾(release/hotfix)                              │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Release           Bundle            Status     Region     Env Path           Crit*  Evidence     │
│-------------------------------------------------------------------------------------------------│
│ Hotfix 1.2.4       platform@1.2.4   DEPLOYING  eu-west    staging→prod       0      93%          │
│ Platform 1.3.0-rc1 platform@1.3.0   READY      us-east    staging→prod       1      74%          │
│ Actions: [Open] [Open Bundle] [Open Approvals] [Export Evidence]                                 │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

8) Release Control → Releases → Release Detail

Previously

Formerly: release row “View” icon; no canonical execution page shown in the PoC.

Now (Redesign)

Now: Release Control → Releases → Release Detail
- Execution timeline:
  - selected targets
  - workflow steps
  - deployment status by target
  - rollback state
- Security snapshot at decision time (crit reachable, reach coverage)
- Evidence snapshot (policy decision, approvals, signatures)
- Links to Orchestrator/Scheduler when something fails

Why changed

This is the page that explains:

what happened,
why it was allowed,
and what evidence proves it.

Screen graph (Mermaid)

flowchart TD
  RD[Release Detail] --> BD[Bundle Detail]
  RD --> AD[Approval Detail]
  RD --> ENV[Environment Detail]
  RD --> WF[Workflows]
  RD --> T[Targets]
  RD --> O[Operations: Orchestrator]
  RD --> S[Operations: Scheduler Runs]
  RD --> SF[Security Findings (snapshot)]
  RD --> EV[Evidence & Audit: Export Evidence Bundle]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASE CONTROL ▸ RELEASE DETAIL: Hotfix 1.2.4                                                   │
│ Formerly: Releases list → row “View”                                                            │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Bundle: platform@1.2.4   Region: eu-west   Path: staging → production   Status: DEPLOYING       │
│ Security snapshot: crit reachable=0 | reach cov=78% | feeds: OSV OK, NVD OK                      │
│ Evidence snapshot: policy decision signed | approvals 2/2 | proof chain complete=YES            │
│ Actions: [Rollback] [Pause] [Export Evidence] [Open Bundle]                                     │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ TARGET EXECUTION                                                                                │
│ Target            Status      Workflow Step           Last Update    Logs                        │
│-------------------------------------------------------------------------------------------------│
│ prod-eu-1         RUNNING     Deploy → Verify         2m ago         [View]                      │
│ prod-eu-2         PENDING     Deploy                  -              -                           │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ TIMELINE                                                                                         │
│ ✓ bundle resolved → ✓ policy gates → ✓ approvals → ▶ deploy(prod-eu-1) → ▢ deploy(prod-eu-2)     │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

9) Release Control → Approvals → Approvals Queue

Previously

Formerly: Approvals (top-level) /approvals Showed approval cards with policy gates, approvals count, approve/reject.

Now (Redesign)

Now: Release Control → Approvals → Queue
- Adds:
  - region filter and explicit “this is blocked because crit reachable in env X”
  - hybrid reachability breakdown in the card (H/B/I/R)
  - explicit “data health” banner if feeds/scans stale (to prevent approving blind)

Why changed

Approvals are where release control meets security/evidence. The queue must show:

“blocked because real exploitable risk exists”
“blocked because we don’t have trustworthy data”

Screen graph (Mermaid)

flowchart TD
  AQ[Approvals Queue] --> AD[Approval Detail]
  AQ --> BD[Bundle Detail]
  AQ --> SF[Security Findings (filtered)]
  AQ --> EX[Security Exceptions (filtered)]
  AQ --> N[Operations: Nightly Ops Report]
  AQ --> EV[Evidence & Audit: Proof Chain]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASE CONTROL ▸ APPROVALS ▸ QUEUE                                                             │
│ Formerly: Approvals (top-level) /approvals                                                      │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Filters: Status ▾  Region ▾  Env ▾  Bundle ▾                                                     │
│ Banner: NVD stale → approvals may be incomplete  [Open Nightly Ops Report]                       │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ [Pending] api-gateway bundle v2.1.0   staging→prod (eu-west)   Policy: PASS 1/2   Approvals: 1/2│
│ Security: crit reachable=3 (prod-eu)  Reach(H/B/I/R)=YES/NO/YES/YES  VEX awaiting=2             │
│ Actions: [View Details] [Approve] [Reject] [Request Exception]                                   │
│-------------------------------------------------------------------------------------------------│
│ [Pending] user-service bundle v3.0.0-rc1  staging→prod (us-east)  Policy: BLOCK 0/2  Approvals 0/2│
│ Block reason: Evidence incomplete (missing signed policy decision)                               │
│ Actions: [View Details] [Open Evidence]                                                          │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

10) Release Control → Approvals → Approval Detail

Previously

Formerly: Approvals card “View Details” (not shown as a full audit-grade page).

Now (Redesign)

Now: Release Control → Approvals → Approval Detail
- Full gate breakdown:
  - security (crit reachable, VEX, exceptions)
  - evidence (signed decision, proofs)
  - data freshness (feeds/scans)
- Shows “approve” rationale (captured, signed, exportable)

Why changed

Approval is the most scrutinized action. It must produce a defensible audit artifact.

Screen graph (Mermaid)

flowchart TD
  AD[Approval Detail] --> BD[Bundle Detail]
  AD --> SF[Security Findings]
  AD --> EX[Exceptions]
  AD --> VEX[VEX Hub]
  AD --> EV[Evidence & Audit: Proof Chain + Export]
  AD --> N[Operations: Nightly Ops Report]
  AD --> RD[Release Detail (after approval)]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASE CONTROL ▸ APPROVAL DETAIL: api-gateway v2.1.0 staging→prod (eu-west)                     │
│ Formerly: Approvals list → card “View Details”                                                   │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Decision: PENDING   Requested by: alice.johnson   Age: 36d                                       │
│ Bundle: api-gateway v2.1.0   Target: prod-eu                                                     │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ GATES                                                                                             │
│ - Security Gate: FAIL  (crit reachable=3)  [View Findings]  [Request Exception]                  │
│ - Evidence Gate: PASS  (policy decision signed, proof chain complete) [Open Proof Chain]        │
│ - Data Freshness: WARN (NVD stale) [Open Nightly Ops Report]                                     │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ APPROVER ACTION                                                                                   │
│ Rationale (required): _______________________________________________________________           │
│ [Approve] [Reject]  (writes signed decision + links evidence bundle)                               │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

11) Release Control → Regions & Environments → Region Overview

Previously

Formerly: Settings → Release Control → Environments (“Manage Environments”) Region concept was missing/implicit.

Now (Redesign)

Now: Release Control → Regions & Environments → Region Overview
- Regions are the top organizing primitive
- Each region lists envs (dev/staging/prod) with:
  - deployment health
  - SBOM posture (crit reachable counts)
  - freshness of runtime inventory

Why changed

Promotion decisions differ by region (different runtime reality, different config sources, different agent health).

Screen graph (Mermaid)

flowchart TD
  REG[Region Overview] --> ENV[Environment Detail]
  REG --> PROMO[Promotion Paths]
  REG --> T[Targets]
  REG --> A[Agents]
  REG --> SEC[Security Overview (region filtered)]
  REG --> OPS[Operations: Platform Health]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASE CONTROL ▸ REGIONS & ENVIRONMENTS ▸ REGION OVERVIEW                                       │
│ Formerly: Settings ▸ Release Control ▸ Environments                                               │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Region: eu-west                                                                                  │
│ Environments:                                                                                     │
│ - dev-eu      Deploy OK   SBOM crit*=0   Runtime inventory fresh 68%   [Open]                    │
│ - staging-eu  Deploy OK   SBOM crit*=1   Runtime inventory fresh 61%   [Open]                    │
│ - prod-eu     Deploy DEG  SBOM crit*=5   Runtime inventory fresh 54%   [Open]                    │
│ *crit* = critical reachable (hybrid)                                                             │
│ [Configure Promotion Paths]  [Targets] [Agents]                                                   │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

12) Release Control → Regions & Environments → Environment Detail

Previously

Formerly: partially under Settings/Release Control and scattered operational pages.

Now (Redesign)

Now: Release Control → Regions & Environments → Environment Detail
- Environment posture includes:
  - deployment status
  - image SBOM status
  - reachability coverage (build/image/runtime)
  - config sources (Vault/Consul pointers used)
- Shows “what’s running” and “what is promotable next”

Why changed

This page must connect runtime truth (inventory) to release governance (approvals).

Screen graph (Mermaid)

flowchart TD
  ED[Environment Detail] --> AQ[Approvals Queue (env filtered)]
  ED --> RL[Releases List (env filtered)]
  ED --> BD[Bundle Catalog (env compatible)]
  ED --> SF[Security Findings (env filtered)]
  ED --> INT[Integrations: Vault/Consul/Registry]
  ED --> AG[Agents]
  ED --> TG[Targets]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASE CONTROL ▸ ENVIRONMENT DETAIL: prod-eu (eu-west)                                          │
│ Formerly: Settings ▸ Release Control (partial) + scattered ops pages                              │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Deploy Health: DEGRADED  | Active release: Hotfix 1.2.4 (RUNNING)                                 │
│ SBOM Posture: crit reachable=5 | high reachable=7                                                 │
│ Reachability coverage: Build 92% | Image/Dover 96% | Runtime 54%                                   │
│ Config sources: Vault kv/prod/eu-west/*  | Consul eu-west/prod/*                                   │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ WHAT’S RUNNING (inventory)                                                                        │
│ Service           Version/Digest          SBOM Fresh   Crit*   Reach(H/B/I/R)                      │
│-------------------------------------------------------------------------------------------------│
│ api-gateway       v2.0.9 / sha256:aaa...  <24h        3       YES/NO/YES/YES                       │
│ user-service      v2.9.4 / sha256:bbb...  3d          0       NO/NO/NO/NO                           │
│ Actions: [View Findings] [Open Bundles compatible] [Open Approvals]                               │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

13) Release Control → Regions & Environments → Promotion Paths

Previously

Formerly: implicit in pipeline UI + Settings/Release Control environments; not region-aware.

Now (Redesign)

Now: Release Control → Regions & Environments → Promotion Paths
- Configure per region:
  - allowed paths (dev→staging→prod)
  - gates required per hop
  - required evidence set for promotion (e.g., policy decision signed)

Why changed

Promotion rules are governance, and regions differ.

Screen graph (Mermaid)

flowchart TD
  PP[Promotion Paths] --> ED[Environment Detail]
  PP --> WF[Workflows]
  PP --> POL[Administration: Policy Governance]
  PP --> EXW[Administration: Exception Workflow]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASE CONTROL ▸ PROMOTION PATHS (eu-west)                                                      │
│ Formerly: implicit pipeline + Settings ▸ Release Control                                          │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Path: dev-eu → staging-eu → prod-eu                                                              │
│ Gates per hop:                                                                                   │
│ - dev→staging: SBOM scan required, evidence optional                                              │
│ - staging→prod: no crit reachable, VEX required for high+ reachables, signed policy decision     │
│ Workflow template: prod-deploy-v3                                                                 │
│ [Edit] [Link Workflow] [View Policy Rules]                                                        │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

14) Release Control → Delivery → Targets

Previously

Formerly: Settings → Release Control → Targets

Now (Redesign)

Now: Release Control → Delivery → Targets
- Targets are region/env scoped (prod-eu-1, prod-us-2, etc.)
- Show target readiness and compatibility (agent health, required capabilities)

Why changed

Targets are operational, but they determine whether a release can execute safely. Keeping them under Release Control preserves governance context.

Screen graph (Mermaid)

flowchart TD
  T[Targets] --> ED[Environment Detail]
  T --> A[Agents]
  T --> WF[Workflows]
  T --> RD[Release Detail]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASE CONTROL ▸ DELIVERY ▸ TARGETS                                                             │
│ Formerly: Settings ▸ Release Control ▸ Targets                                                   │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Filters: Region ▾  Env ▾  Status ▾                                                                │
│ Target         Region     Env       Agent       Status     Capabilities                          │
│-------------------------------------------------------------------------------------------------│
│ prod-eu-1      eu-west    prod-eu   agent-eu-1  READY      deploy,verify,inventory               │
│ prod-eu-2      eu-west    prod-eu   agent-eu-2  DEGRADED   deploy                                │
│ Actions: [Open] [Test] [Assign Workflow]                                                         │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

15) Release Control → Delivery → Agents

Previously

Formerly: Settings → Release Control → Agents

Now (Redesign)

Now: Release Control → Delivery → Agents
- Agents are tied to targets and regions
- Must show whether agents can also provide required runtime inventory signals (needed for hybrid reachability)

Why changed

Agent health affects not only deployment but whether your reachability and inventory data is trustworthy.

Screen graph (Mermaid)

flowchart TD
  AG[Agents] --> T[Targets]
  AG --> ED[Environment Detail]
  AG --> OPS[Operations: Platform Health]
  AG --> N[Operations: Nightly Ops Report]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASE CONTROL ▸ DELIVERY ▸ AGENTS                                                              │
│ Formerly: Settings ▸ Release Control ▸ Agents                                                     │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Agent        Region     Status     Deploy Capable  Runtime Inventory  Last Seen   Notes         │
│-------------------------------------------------------------------------------------------------│
│ agent-eu-1   eu-west    OK         YES            YES               1m ago      -             │
│ agent-eu-2   eu-west    DEGRADED   YES            NO                2h ago      inventory stuck│
│ Actions: [Open] [Restart] [View Logs]                                                            │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

16) Release Control → Delivery → Workflows

Previously

Formerly: Settings → Release Control → Workflows

Now (Redesign)

Now: Release Control → Delivery → Workflows
- Workflow templates include:
  - deploy steps
  - verify steps
  - evidence capture steps (sign decisions, export proofs)
  - optional SBOM scan / rescan triggers (for hotfix)

Why changed

Workflows enforce consistency across releases/hotpatches and ensure evidence is captured uniformly.

Screen graph (Mermaid)

flowchart TD
  WF[Workflows] --> RD[Release Detail]
  WF --> PP[Promotion Paths]
  WF --> T[Targets]
  WF --> EV[Evidence & Audit: Proof Chains]
  WF --> OPS[Operations: Scheduler/Orchestrator]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASE CONTROL ▸ DELIVERY ▸ WORKFLOWS                                                           │
│ Formerly: Settings ▸ Release Control ▸ Workflows                                                  │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Workflow Template: prod-deploy-v3                                                                │
│ Steps:                                                                                           │
│ 1) Resolve bundle + config refs (Vault/Consul)                                                   │
│ 2) Policy gates (security + evidence + data freshness)                                           │
│ 3) Require approvals                                                                            │
│ 4) Deploy to targets                                                                            │
│ 5) Verify (health + smoke)                                                                      │
│ 6) Capture evidence (signed decision, logs, provenance)                                          │
│ 7) Export bundle (optional)                                                                     │
│ [Edit] [Clone] [Assign to Promotion Path]                                                       │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

What stayed intact (your requirement)

Release Control is a root menu (not grouped under Settings).
Security + Evidence + Operations remain separate roots; Release Control screens link to them where needed (findings, nightly jobs, export evidence), but do not absorb them.

Next pack options (you choose with one line)

Pack 9 — Administration (Settings): Identity & Access, Trust & Signing, Policy Governance, Notifications, Usage & Limits, System (with same Mermaid + ASCII + formerly/why).
Pack 10 — Integrations: consolidate integrations + feeds under a coherent “data sources” model and show how degraded integrations bubble up into approvals/releases.