Pack 4 — Release Control (root) + Bundle Organizer + Regions/Environments (with SBOM + Reachability surfaced)

Below is a complete Mermaid IA graph for the Release Control area (as a root menu), plus screen-by-screen Mermaid navigation graphs and ASCII mockups. Each screen includes: formerly (where it lived before) + why it moved / changed.

flowchart TD
  A[Stella Ops] --> D[Dashboard]
  A --> RC[Release Control]
  A --> SEC[Security]
  A --> EA[Evidence & Audit]
  A --> OPS[Operations]
  A --> INT[Integrations]
  A --> ADM[Administration]

What changed vs PoC:

In the PoC, “Release Control” is under Settings. You asked that Release Control becomes a root menu because it’s the center of gravity (release/hotfix + security + auditability).
“Dashboard” becomes release-centric and surfaces SBOM findings + reachability + nightly job health (second-class, not buried).

flowchart TD
  RC[Release Control] --> RC0[Control Plane]
  RC --> RC1[Regions & Environments]
  RC --> RC2[Bundles]
  RC --> RC3[Releases]
  RC --> RC4[Hotfixes]
  RC --> RC5[Approvals]
  RC --> RC6[Deployments]

  RC --> RC7[Configure]
  RC7 --> RC7a[Targets]
  RC7 --> RC7b[Agents]
  RC7 --> RC7c[Workflows]

  RC2 --> RC2a[Bundle Catalog]
  RC2 --> RC2b[Bundle Organizer]
  RC2 --> RC2c[Bundle Detail / Versions]

  RC3 --> RC3a[Release List]
  RC3 --> RC3b[Release Detail]

RC-DASH — Dashboard (Release Ops)

Previously

Formerly: Control Plane (top-level menu) – the pipeline tiles + pending approvals + active deployments. (Screenshot: “Control Plane” page.)

Now (Redesign)

Now: Dashboard (root) → “Release Ops Dashboard”

Why this change

Your requirement: the dashboard must surface SBOM findings, specifically:
- “no issues” vs “X envs with critical reachable”
- identify Env N / Env M with details
Also must surface nightly jobs health (SBOM rescan, CVE source sync, integration connectivity), and hybrid reachability coverage.
The PoC dashboard currently shows deployment pipeline but hides security posture and scan freshness.

flowchart TD
  Dash[Dashboard] -->|click Region/Env tile| EnvDetail[Environment Detail]
  Dash -->|click "Critical Reachable"| Findings[Security Findings]
  Dash -->|click "Bundle at Risk"| BundleDetail[Bundle Detail]
  Dash -->|click "Pending Approval"| ApprovalDetail[Approval Detail]
  Dash -->|click "Nightly Jobs"| Nightly[Operations: Nightly Jobs Report]
  Dash -->|click "Release"| ReleaseDetail[Release Detail]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ DASHBOARD (Release Ops)   Time: Last 24h ▾   Region: All ▾   Env: All ▾     Search: _____     │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ AT-A-GLANCE                                                                                   │
│ ┌───────────────┐ ┌───────────────┐ ┌────────────────────┐ ┌──────────────────┐             │
│ │ Pending Appr:2 │ │ Deploying: 1  │ │ Critical Reachable │ │ Integrations     │             │
│ │ (Prod:2)       │ │ (Hotfix 1.2.4)│ │ 2 envs (Prod+UAT)   │ │ 1 degraded,1 down│            │
│ └───────────────┘ └───────────────┘ └────────────────────┘ └──────────────────┘             │
│                                                                                               │
│ ENVIRONMENT STATUS (by Region) — includes Runtime + Image SBOM + Reachability Coverage         │
│  Region tabs: [us-east] [us-west] [eu-central] [ap-south]                                      │
│  ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│  │ ENV        Runtime   Image SBOM    Reachability (Build/Registry/Runtime)   Notes         │  │
│  │ dev        OK        OK           80% / 70% / 20%                          coverage gap  │  │
│  │ staging    OK        WARN         92% / 85% / 60%                          1 med reach. │  │
│  │ uat        DEGRADED  FAIL         95% / 90% / 90%                          CRIT reachable│  │
│  │ prod       DEGRADED  FAIL         98% / 95% / 95%                          CRIT reachable│  │
│  └─────────────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                               │
│ FINDINGS HOTSPOTS (Critical Reachable)              NIGHTLY HEALTH (last run)                  │
│ ┌─────────────────────────────────────────────┐    ┌───────────────────────────────────────┐ │
│ │ prod/us-east  3 CRIT reachable  (Open)  >    │    │ SBOM Rescan: FAIL (stale 2d)   >     │ │
│ │ uat/eu-central 1 CRIT reachable (Open)  >    │    │ CVE Feed Sync: DEGRADED (NVD)  >     │ │
│ │ staging/...    0                              │    │ Integration Check: OK                │ │
│ └─────────────────────────────────────────────┘    │ Evidence Sign/Verify: OK               │ │
│                                                   └───────────────────────────────────────┘ │
│                                                                                               │
│ RECENT BUNDLES / RELEASES                                                                      │
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│ │ Bundle v2.1.0 (payments-suite)  -> staging  | Risk: PASS | Evidence: Complete     (Open) │  │
│ │ Hotfix 1.2.4 (auth-service)     -> prod     | Risk: WARN | Evidence: Partial      (Open) │  │
│ └─────────────────────────────────────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC0 — Control Plane (Promotion pipeline)

Previously

Formerly: Control Plane (top-level menu) — environment pipeline + pending approvals + active deployments.

Now

Now: Release Control → Control Plane

Why this change

Control Plane is not a generic dashboard; it’s release governance execution view.
Dashboard stays summary; Control Plane becomes “run the shop”: promotion paths, gates, rollback/hotfix, regionalized env lanes.

flowchart TD
  CP[RC: Control Plane] --> Env[Regions & Environments]
  CP --> Rel[Release Detail]
  CP --> Appr[Approvals]
  CP --> Dep[Deployments]
  CP --> Bund[Bundle Detail]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASE CONTROL / CONTROL PLANE      Region: us-east ▾   Path: dev→staging→uat→prod ▾          │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ PIPELINE (region lane)                                                                         │
│  dev            staging                 uat                     prod                            │
│ ┌─────────┐    ┌─────────────────┐     ┌─────────────────┐     ┌──────────────────────────┐    │
│ │ 0 rel   │ -> │ 2 rel | HEALTHY  │ ->  │ 0 rel | UNKNOWN  │ ->  │ 1 rel | DEGRADED         │    │
│ │ SBOM OK │    │ SBOM WARN (1)    │     │ SBOM ?           │     │ SBOM FAIL (CRIT reach.)  │    │
│ └─────────┘    └─────────────────┘     └─────────────────┘     └──────────────────────────┘    │
│                                                                                               │
│ PENDING GATES / ACTIONS                                                                       │
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│ │ [Approval] API Gateway v2.1.0  staging→prod  Policy: PASS  Reachability: OK        (Open)│  │
│ │ [Approval] User Service v3.0.0 staging→prod  Policy: BLOCK Reachability: CRIT      (Open)│  │
│ └─────────────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                               │
│ ACTIVE DEPLOYMENTS                                                                            │
│  Hotfix 1.2.4  → prod/us-east  status: RUNNING  agent: prod-agent-01  (View deployment)       │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC1 — Regions & Environments

Previously

Formerly: partial + fragmented:
- Control Plane (only a flat pipeline, not regional)
- Settings → Release Control → Environments (config only, no operational SBOM posture view)
- Security screens for findings (not tied to env operational posture)

Now

Now: Release Control → Regions & Environments

Why this change

You asked for environments organized per region (missing today).
Each environment must show Runtime status + Image/SBOM status + Reachability coverage — not only “docker status”.

flowchart TD
  RE[RC: Regions & Environments] --> ED[Environment Detail]
  RE --> RCcfg[Release Control: Configure/Targets]
  RE --> SECFind[Security Findings]
  RE --> Bund[Bundle Detail]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASE CONTROL / REGIONS & ENVIRONMENTS        Search env/bundle: ________                   │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Region: us-east                                                                                │
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│ │ Environment  Runtime   Bundle/Version     Image SBOM   Critical Reachable   Coverage      │  │
│ │ dev          OK        platform v1.3.0-rc1 OK          0                  B80/R70/RT20    │  │
│ │ staging      OK        api-suite v2.1.0    WARN        0                  B92/R85/RT60    │  │
│ │ uat          DEGRADED  api-suite v2.1.0    FAIL        1                  B95/R90/RT90    │  │
│ │ prod         DEGRADED  hotfix v1.2.4       FAIL        3                  B98/R95/RT95    │  │
│ └─────────────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                               │
│ Region: eu-central                                                                             │
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│ │ ...                                                                                         │
│ └─────────────────────────────────────────────────────────────────────────────────────────┘  │
│ Legend: Coverage = Build/Registry/Runtime                                                     │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC1a — Environment Detail

Previously

Formerly: not a first/second class page. Operators had to stitch together:
- runtime health (somewhere else)
- findings (Security → Findings)
- SBOM analytics (Analytics → SBOM Lake)
- reachability (not visible / scattered)
- release context (Releases)

Now

Now: Release Control → Regions & Environments → Environment Detail

Why this change

This is where you make go/no-go decisions. It must unify:
- what is deployed (bundle + digests)
- SBOM posture (image + rescan freshness)
- reachability coverage (Build/Registry/Runtime)
- the actionable list of critical reachable issues

flowchart TD
  ED[Environment Detail] --> Rel[Release Detail]
  ED --> Bund[Bundle Detail]
  ED --> Findings[Security Findings (filtered to env)]
  ED --> Nightly[Ops: Nightly Jobs (filtered)]
  ED --> Appr[Approvals (filtered to env)]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ ENVIRONMENT: prod / us-east      Runtime: DEGRADED      Current Bundle: hotfix v1.2.4         │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ DEPLOYED ARTIFACTS (digests)                    SBOM + REACHABILITY                           │
│ ┌─────────────────────────────────────────────┐ ┌───────────────────────────────────────────┐ │
│ │ service          digest        version      │ │ Image SBOM: FAIL (3 CRIT reachable)       │ │
│ │ auth-service     sha256:...     1.2.4       │ │ Last SBOM scan: 2h ago  | Rescan: nightly │ │
│ │ api-gateway      sha256:...     2.1.0       │ │ Reachability coverage: Build 98%          │ │
│ │ worker           sha256:...     3.1.0       │ │                         Registry 95%       │ │
│ └─────────────────────────────────────────────┘ │                         Runtime 95%        │ │
│                                                └───────────────────────────────────────────┘ │
│                                                                                               │
│ TOP FINDINGS (Critical reachable)                                                             │
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│ │ CVE-2026-1234 | pkg:openssl | reachable: YES | path: api-gateway->tls->... | Fix: 1.2.5    │  │
│ │ CVE-2026-2222 | pkg:...     | reachable: YES | runtime confirmed | mitigation: VEX?       │  │
│ └─────────────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                               │
│ NIGHTLY STATUS (impacting this env)                                                           │
│ SBOM rescan: OK  | CVE feed sync: DEGRADED (NVD) | Integration: Jenkins WARN | Evidence: OK   │
│                                                                                               │
│ ACTIONS: [Open Approvals] [Request Hotfix] [Force Rescan] [Generate Evidence Bundle]          │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC2a — Bundle Catalog

Previously

Formerly: there is no “bundle catalog”.
The closest analogs:
- Releases list (but it’s a mixed concept: release events + component sets)
- ad-hoc “create release” flow (digest-first, per release)

Now

Now: Release Control → Bundles → Bundle Catalog

Why this change

You asked for a Release Bundle Organizer: bundles must be first-class.
Bundles are the stable unit that carries:
- component digests
- version mapping
- config materialization (Vault/Consul)
- per-repo change log
- security posture + evidence completeness

flowchart TD
  BC[Bundle Catalog] --> BO[Bundle Organizer (create version)]
  BC --> BD[Bundle Detail]
  BC --> RL[Release List (filtered by bundle)]
  BC --> ED[Environment Detail (where deployed)]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASE CONTROL / BUNDLES / CATALOG        [Create Bundle]   Search: ________   Risk: All ▾  │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Bundles                                                                                       │
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│ │ Bundle            Latest Version   Repos(services)   Risk (CRIT reach)  Evidence   Deployed│  │
│ │ payments-suite    v2.1.0           6 (12 svcs)       PASS (0)           COMPLETE   staging │  │
│ │ platform-core     v1.3.0-rc1       3 (8 svcs)        WARN (0)           PARTIAL    dev     │  │
│ │ hotfix-auth       v1.2.4           1 (1 svc)         FAIL (3)           COMPLETE   prod    │  │
│ └─────────────────────────────────────────────────────────────────────────────────────────┘  │
│ Actions per row: (Open) (New Version) (Promote) (Export Evidence)                               │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC2b — Bundle Organizer (NEW: bundle composition + config materialization + changelog)

Previously

Formerly: scattered across:
- Releases → Create Release (component selection/digest)
- SCM/CI/CD systems for “what changed”
- Vault/Consul for runtime config (not captured as release artifact)
- Evidence/attestations stored elsewhere (not presented as bundle version contract)

Now

Now: Release Control → Bundles → Bundle Organizer

Why this change

Your explicit requirement:
- microservice digest becomes version X
- plus env variables derived from Vault + Consul
- plus other microservices becomes a bundle
- plus change log per repository
This turns releases into an auditable contract: “this exact set of digests + this exact config snapshot”.

flowchart TD
  BO[Bundle Organizer] --> BD[Bundle Detail / Version]
  BO --> INT[Integrations (SCM/CI/CD/Registry/Vault/Consul)]
  BO --> SEC[Security preflight (policy + reachability)]
  BO --> EA[Evidence pack preview]
  BO --> RL[Create Release from Bundle Version]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ BUNDLE ORGANIZER (Create/Update Bundle Version)    Bundle: payments-suite ▾   Version: v2.1.1 │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ STEP BAR: ① Select repos  ② Select digests  ③ Materialize config  ④ Change log  ⑤ Validate   │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ REPOSITORIES / SERVICES              DIGESTS + VERSION MAP                  CONFIG SNAPSHOT   │
│ ┌───────────────────────────────┐   ┌───────────────────────────────────┐  ┌───────────────┐ │
│ │ repo: api-gateway             │   │ svc          digest      ver       │  │ Env: staging  │ │
│ │   commits: 9 (since v2.1.0)   │   │ api-gateway  sha256...   2.1.1     │  │ Vault: path…  │ │
│ │ repo: auth-service            │   │ auth-service sha256...   1.2.5     │  │ Consul: kv…   │ │
│ │   commits: 2                  │   │ worker       sha256...   3.1.1     │  │ Resolved vars │ │
│ │ repo: worker                  │   │ ...                               │  │  DB_URL=...   │ │
│ └───────────────────────────────┘   └───────────────────────────────────┘  │  FEATURE_X=on │ │
│                                                                            └───────────────┘ │
│                                                                                               │
│ CHANGE LOG (per repository)                                                                   │
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│ │ api-gateway: PR#123 add rate limiting | PR#128 fix header parsing                          │  │
│ │ auth-service: PR#77 fix auth timeout                                                      │  │
│ │ worker: PR#44 reduce queue retries                                                       │  │
│ └─────────────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                               │
│ PREFLIGHT VALIDATION                                                                          │
│ Policy simulation: PASS  | SBOM delta scan: WARN (1 MED) | Reachability: OK | Evidence: Ready │
│ ACTIONS: [Save Bundle Version] [Create Release Run] [Export Bundle Manifest]                  │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC2c — Bundle Detail / Versions

Previously

Formerly: there was no bundle entity; release detail partially served as “bundle detail”.

Now

Now: Release Control → Bundles → Bundle Detail

Why this change

Bundle Detail becomes the auditable contract object:
- versions timeline
- component digests
- config snapshots (Vault/Consul refs + resolved values hash)
- SBOM posture + reachability + evidence completeness
- links to release runs across environments

flowchart TD
  BD[Bundle Detail] --> BV[Bundle Version Detail]
  BD --> RL[Release Runs using this bundle]
  BD --> ED[Environments where deployed]
  BD --> EA[Evidence Bundle Export]
  BD --> SEC[Security posture drilldown]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ BUNDLE: payments-suite                                                                        │
│ Latest: v2.1.1   Risk: WARN (0 CRIT reachable)   Evidence: COMPLETE   Deployed: staging, dev  │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ VERSIONS                                                                                      │
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│ │ v2.1.1  created Feb 18  | repos changed: 3 | policy: PASS | sbom: WARN | reach cov: 92/85/60│ │
│ │ v2.1.0  created Feb 12  | repos changed: 6 | policy: PASS | sbom: OK   | reach cov: 90/80/40│ │
│ └─────────────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                               │
│ THIS VERSION CONTENT (v2.1.1)                                                                 │
│ Components(digests) | Config snapshot refs (Vault/Consul) | Change log per repo | Evidence    │
│ [Open version detail] [Export manifest] [Generate audit bundle]                               │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC3a — Releases list (Release Runs)

Previously

Formerly: Releases (top-level menu)

Now

Now: Release Control → Releases

Why this change

Releases should be treated as promotion runs of a bundle version across envs (and regions).
The PoC release list lacks explicit bundle/version framing and doesn’t tie in security posture at list level.

flowchart TD
  RL[Release List] --> RD[Release Detail]
  RL --> BD[Bundle Detail]
  RL --> ED[Environment Detail]
  RL --> AP[Approvals]
  RL --> DP[Deployments]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASES (Promotion Runs)     Status: All ▾   Env: All ▾   Region: All ▾   [Create Release]   │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│ │ Release Run        Bundle/Version        Path              Status      Risk     Evidence    │  │
│ │ Hotfix 1.2.4       hotfix-auth v1.2.4    staging→prod      DEPLOYING   FAIL     COMPLETE    │  │
│ │ Platform 1.3.0-rc1 platform-core v1.3.0  dev→staging       READY       WARN     PARTIAL     │  │
│ │ API Gateway 2.1.0  payments-suite v2.1.0 staging→prod      PENDING     PASS     COMPLETE    │  │
│ └─────────────────────────────────────────────────────────────────────────────────────────┘  │
│ Row actions: Open | Approvals | Deployment | Export Evidence                                   │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC3b — Release Detail (promotion, policy, SBOM, reachability, evidence)

Previously

Formerly: release detail was implicit/limited; approvals had some gating info; security detail was elsewhere.

Now

Now: Release Control → Releases → Release Detail

Why this change

Release Detail must unify:
- approval gates (policy + human)
- SBOM posture (including reachable critical)
- hybrid reachability coverage (Build/Registry/Runtime)
- evidence chain status (signing/rekor/proof)

flowchart TD
  RD[Release Detail] --> APD[Approval Detail]
  RD --> DP[Deployment Detail]
  RD --> BD[Bundle Version Detail]
  RD --> Findings[Security Findings filtered]
  RD --> EA[Evidence Bundle + Proof Chains]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASE RUN: API Gateway 2.1.0     Bundle: payments-suite v2.1.0    staging → production       │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ GATES                                                                                          │
│ ┌───────────────────────────────┐  ┌───────────────────────────────┐  ┌─────────────────────┐ │
│ │ Policy Gates: PASS (2/2)      │  │ Human Approvals: 1/2          │  │ Evidence: COMPLETE  │ │
│ │ Reachability requirement: OK  │  │ Pending: sec-lead             │  │ DSSE ✓ Rekor ✓      │ │
│ └───────────────────────────────┘  └───────────────────────────────┘  └─────────────────────┘ │
│                                                                                               │
│ SECURITY POSTURE                                                                              │
│ SBOM: WARN (0 CRIT reachable, 1 MED)   | Coverage: Build 92% / Registry 85% / Runtime 60%     │
│ Top deltas: +pkgX 1.2.3  -pkgY 4.5.6                                                            │
│ [Open findings] [Request VEX] [Force rescan]                                                   │
│                                                                                               │
│ PROMOTION TIMELINE                                                                            │
│ staging: READY  → prod: PENDING APPROVAL  → (deploy agent: prod-agent-01)                      │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC4 — Hotfixes

Previously

Formerly: hotfixes are just “Releases” with a name “Hotfix …”, not a first-class fast-path.

Now

Now: Release Control → Hotfixes

Why this change

Hot patches are central to Stella Ops: they deserve:
- dedicated queue
- forced visibility on dashboard
- explicit “expedite policy” handling (still audited)

flowchart TD
  HX[Hotfixes] --> RD[Release Detail (hotfix mode)]
  HX --> AP[Approvals]
  HX --> ED[Environment Detail]
  HX --> EA[Evidence export]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ HOTFIXES     Status: All ▾   Region: All ▾   [Request Hotfix]                                  │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│ │ Hotfix          Target Env     Status      CRIT Reachable  Evidence   Requested By         │  │
│ │ Hotfix 1.2.4     prod/us-east   DEPLOYING   3              COMPLETE   security-team        │  │
│ │ Hotfix 1.2.3     prod/eu        DEPLOYED    0              COMPLETE   deploy-bot           │  │
│ └─────────────────────────────────────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC5 — Approvals (release-centric)

Previously

Formerly: Approvals (top-level menu)

Now

Now: Release Control → Approvals (still can be quick-access pinned)

Why this change

Approvals are a release control primitive; they belong under Release Control.
Also: approvals must show SBOM+reachability and not only “policy gates pass/block”.

flowchart TD
  AP[Approvals Queue] --> APD[Approval Detail]
  AP --> RD[Release Detail]
  AP --> Findings[Security Findings]
  AP --> EA[Evidence]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ APPROVALS     Status: Pending ▾  Env: prod ▾  Sort: Risk ▾                                      │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ [1] API Gateway v2.1.0  staging→prod  Policy: PASS  Reachability: OK  SBOM: OK     (Open)     │
│     Evidence: COMPLETE | Requested: alice.johnson | Age: 36d                                     │
│                                                                                               │
│ [2] User Service v3.0.0 staging→prod  Policy: BLOCK Reachability: CRIT  SBOM: FAIL  (Open)     │
│     CRIT reachable: CVE-... | Evidence: PARTIAL | Requested: david.wilson | Age: 36d           │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC5a — Approval Detail (decision with full context)

Previously

Formerly: approval cards + minimal “View Details”.

Now

Now: Release Control → Approvals → Approval Detail

Why this change

Approval must be explainable (audit):
- “what changed” (bundle changelog per repo)
- “what’s the risk” (reachability, criticality)
- “what evidence exists” (SBOMs, attestations, policy decision record)

flowchart TD
  APD[Approval Detail] --> BD[Bundle Version Detail]
  APD --> Findings[Findings (delta+reachable)]
  APD --> EA[Evidence Packet / Proof Chain]
  APD --> RD[Release Detail]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ APPROVAL: User Service v3.0.0-rc1   staging → production   Risk: HIGH                           │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ SUMMARY: Policy: BLOCK (2 gates failed)  | CRIT reachable: 1 | Evidence: PARTIAL               │
│                                                                                               │
│ WHAT CHANGED (per repo)                                                                      │
│ - auth-service: PR#77 fix auth timeout                                                        │
│ - api-gateway: PR#123 rate limiting                                                           │
│                                                                                               │
│ SECURITY (hybrid reachability)                                                                │
│ Coverage: Build 95% / Registry 90% / Runtime 90%                                               │
│ Blocking item: CVE-2026-XXXX reachable via api-gateway->...                                    │
│                                                                                               │
│ EVIDENCE                                                                                       │
│ SBOMs: present ✓ | Attestations: missing ✗ | Policy Decision: present ✓ | Rekor: present ✓     │
│                                                                                               │
│ DECISION: [Approve] [Reject] [Request VEX] [Request Rescan] [Request Exception]                │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC6 — Deployments (promotion execution)

Previously

Formerly: deployment execution signals were split:
- Control Plane active deployments summary
- Operations → Orchestrator / Scheduler (technical execution)
- “Deployment status” not tied cleanly to release run object

Now

Now: Release Control → Deployments (release-run aware), still links to Ops internals

Why this change

Release operators need a release-centric deployment view:
- “this release run” → “these targets” → “this agent” → status/logs
Ops remains for deep platform internals; Release Control shows the release execution view.

flowchart TD
  DEP[RC: Deployments] --> RD[Release Detail]
  DEP --> ED[Environment Detail]
  DEP --> OPS[Operations: Orchestrator/Scheduler (deep)]
  DEP --> DLQ[Operations: Dead Letter]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ DEPLOYMENTS (Release execution)   Time: 24h ▾   Status: Running ▾                              │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│ │ Release Run        Target             Agent            Status     Logs     Retry / Rollback │  │
│ │ Hotfix 1.2.4       prod/us-east       prod-agent-01    RUNNING    View     (Retry) (Rollback)│ │
│ │ API Gateway 2.1.0  prod/eu-central    prod-agent-eu    QUEUED     View     (Cancel)         │  │
│ └─────────────────────────────────────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC7 — Configure (Targets, Agents, Workflows) — moved out of Settings

RC7a — Targets

Previously

Formerly: Settings → Release Control → Targets

Now

Now: Release Control → Configure → Targets

Why this change

Targets are not “generic settings”; they’re release control primitives tied to region/env topology.

flowchart TD
  T[Targets] --> TE[Target Detail]
  T --> RE[Regions & Environments]
  T --> AG[Agents]

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ CONFIGURE / TARGETS     [Add Target]   Region: us-east ▾                                       │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Target Name     Type       Bound Env(s)           Status     Agent Pool                        │
│ prod-us-east    compose    prod/us-east           OK         prod-agent-01,02                   │
│ uat-eu          host       uat/eu-central         WARN       uat-agent-eu                       │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC7b — Agents

Previously

Formerly: Settings → Release Control → Agents

Now

Now: Release Control → Configure → Agents

Why this change

Agents are part of the release execution chain; operators need them in release context.

flowchart TD
  AG[Agents] --> AGD[Agent Detail]
  AG --> DEP[Deployments]
  AG --> PH[Operations: Platform Health]

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ CONFIGURE / AGENTS     [Register Agent]                                                       │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Agent           Region     Last Seen   Capability (deploy/scan)   Status                        │
│ prod-agent-01   us-east    2m ago      deploy+runtime-scan        OK                            │
│ uat-agent-eu    eu-central 1h ago      deploy                      DEGRADED                      │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC7c — Workflows

Previously

Formerly: Settings → Release Control → Workflows

Now

Now: Release Control → Configure → Workflows

Why this change

Workflows define the promotion contract (gates, evidence requirements). It’s core to release control.

flowchart TD
  WF[Workflows] --> WFD[Workflow Detail]
  WF --> PG[Policy Governance]
  WF --> EA[Evidence requirements]

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ CONFIGURE / WORKFLOWS     [Create Workflow]                                                    │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Workflow            Applies To        Gates (policy/human)     Evidence Requirements            │
│ standard-prod       prod/*            policy+2 approvals       SBOM+attest+rekor+decision       │
│ hotfix-expedite     prod/* hotfix     policy+1 approval        SBOM+decision+rekor              │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

What I’ll send next (if you reply “continue”)

Pack 5: Integrations + Administration/Settings screens (Identity & Access, Trust & Signing, Policy Governance, Notifications, Usage & Limits, System, Tenant/Branding) — each with Mermaid graphs + ASCII + “formerly/why”.
Pack 6: Security + Evidence + Operations screens converted to the same Mermaid-per-screen + ASCII format (so everything is consistent end-to-end).