Pack 11 — Release Control (root) + Governance + Admin (IAM/Notifications/Usage) + System + Trust & Signing
This pack converts the remaining “Settings” pages into the release-first Stella Ops IA, adds the missing region-first environment model, and makes governance + determinism explicit (aligned with Stella’s stated focus on digest-first release identity, evidence, reachability/hybrid reachability, and audit exports). (Stella Ops Suite)
11.1 Menu graph (Mermaid) — the menus touched in this pack
NOTE: This is a partial root graph (only the menus we’re redesigning here). It preserves your “main reorg” (release-first), keeps Release Control as a root menu, and moves “Settings” items into Admin / System / Evidence Trust where they belong.
flowchart TD ROOT[Stella Ops Console] --> RC[Release Control (ROOT)] ROOT --> ADM[Administration] ROOT --> SYS[System (Platform)] ROOT --> EVID[Evidence] ROOT --> INT[Integrations] %% RELEASE CONTROL RC --> RC_HOME[Release Control Home] RC --> RC_REG[Regions & Environments] RC --> RC_TARGETS[Deployment Targets] RC --> RC_AGENTS[Agents] RC --> RC_WF[Workflows] RC --> RC_GOV[Governance\n(Policy, Gates, Simulation, Exception Workflow)] RC_REG --> RC_ENV[Environment Detail] %% ADMIN ADM --> IAM[Identity & Access] ADM --> NOTIF[Notifications] ADM --> LIMITS[Usage & Limits] ADM --> BRAND[Tenants & Branding] %% SYSTEM SYS --> SYS_HOME[System Console\n(Health, Doctor, SLO, Jobs)] SYS_HOME --> JOBS[Background Jobs] SYS_HOME --> HEALTH[Health Check Detail] %% EVIDENCE / TRUST EVID --> TRUST[Trust & Signing] TRUST --> KEYS[Signing Keys] TRUST --> ISSUERS[Issuers] TRUST --> CERTS[Certificates] TRUST --> REKOR[Transparency Log] TRUST --> SCORE[Trust Scoring] TRUST --> AUDIT[Audit Log] %% CROSS LINKS (2nd-class, not buried) RC_ENV -. "Vault/Consul inputs" .-> INT JOBS -. "Feed sync failures" .-> INT RC_GOV -. "Exception workflow uses Security Exceptions" .-> ROOT
11.2 Screen — Release Control Home
Formerly
- Settings → Release Control (
/settings/release-control) (cards: Environments, Targets, Agents, Workflows)
Why moved / reshaped
- Stella is explicitly release-governance centric (promotion graphs, digest-first identity, deterministic decision records). (Gitea: Git with a cup of tea)
- So “Release Control” must be ROOT (operator-facing), not buried under Settings.
Screen graph (Mermaid)
flowchart LR A[Release Control Home] --> B[Regions & Environments] A --> C[Deployment Targets] A --> D[Agents] A --> E[Workflows] A --> F[Governance Hub] A --> G[Integrations Hub]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Release Control (ROOT) │
│ Legacy: Settings ▸ Release Control (/settings/release-control) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Purpose: configure how releases are promoted + executed across regions/envs (digest-first). │
│ Region scope: [All] US-East EU-West APAC Env types: Dev/QA/Staging/Prod │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Quick Links │
│ [Regions & Environments] [Targets] [Agents] [Workflows] [Governance] │
│ │
│ Attention (release-impacting drift) │
│ • EU-West Prod: env variables source missing (Consul mapping not configured) │
│ • US-East Stage: agent offline → promotions will stall │
│ • Policy baseline “Prod” updated yesterday → 2 approvals will replay under new baseline │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.3 Screen — Regions & Environments
Formerly
- Accessed via Settings → Release Control → Manage Environments (button from the card)
Why moved / reshaped
- You called out a missing core: environments must be organized per region.
- Stella’s model is “what is deployed where” must be unambiguous; region-first is required for that clarity. (Gitea: Git with a cup of tea)
Screen graph (Mermaid)
flowchart TD A[Regions & Environments] --> B[Region Detail] B --> C[Environment Detail] A --> D[Create Region] B --> E[Create Environment] C --> F[Promotion Graph] C --> G[Env Inputs (Vault/Consul)] C --> H[Env SBOM & Findings Summary]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Regions & Environments │
│ Legacy: Settings ▸ Release Control ▸ Environments (Manage Environments) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Regions: [ + Create Region ] │
│ │
│ ┌───────────────────────┬───────────────┬───────────┬──────────────────────────────────────┐ │
│ │ Region │ Environments │ Agents OK │ Release Health Summary │ │
│ ├───────────────────────┼───────────────┼───────────┼──────────────────────────────────────┤ │
│ │ US-East │ 6 (2 prod) │ 5/6 │ 1 env w/ critical reachable findings │ │
│ │ EU-West │ 4 (1 prod) │ 4/4 │ clean │ │
│ │ APAC │ 3 (1 prod) │ 3/3 │ feeds stale → gating risk medium │ │
│ └───────────────────────┴───────────────┴───────────┴──────────────────────────────────────┘ │
│ Click a region → Region Detail │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.4 Screen — Region Detail
Formerly
- Not present as a first-class concept (regions missing; envs likely flat)
Why moved / reshaped
Region is the natural unit for:
- feed freshness / mirror selection,
- deployment agents & targets,
- environment variables sources (Vault/Consul partitioning).
Screen graph (Mermaid)
flowchart LR A[Region Detail] --> B[Environment Detail] A --> C[Region Agents] A --> D[Region Feeds Freshness] A --> E[Region Targets] A --> F[Region Defaults\n(policy baseline, locks, inputs)]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Region: US-East │
│ Legacy: (new) — previously environments were not region-first │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Defaults: Policy Baseline = Prod-US-East Feed Lock = lock-2026-02-18 Vars = Vault+Consul │
│ │
│ Environments │
│ ┌───────────────┬──────────────┬───────────────┬─────────────────────┬──────────────────────┐│
│ │ Env │ Type │ Promotion Path │ SBOM/Security Status │ Agent/Target ││
│ ├───────────────┼──────────────┼───────────────┼─────────────────────┼──────────────────────┤│
│ │ us-dev │ Dev │ — │ informational only │ agent-01 / docker-01 ││
│ │ us-stage │ Staging │ dev→stage │ 2 high (not reachable)│ agent-02 / docker-02 ││
│ │ us-prod │ Production │ stage→prod │ 1 critical reachable │ agent-03 / docker-03 ││
│ └───────────────┴──────────────┴───────────────┴─────────────────────┴──────────────────────┘│
│ Links: [Feeds Freshness] [Agents] [Targets] [Region Defaults] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.5 Screen — Environment Detail (Config + Status summary)
Formerly
- “Environment” concept appeared on Control Plane / Releases / Approvals pages, but
- no dedicated region-first “env detail” with SBOM + reachability + runtime proof surfaced.
Why moved / reshaped
Stella’s promise includes reachability and hybrid reachability evidence. (Gitea: Git with a cup of tea)
Environment is where hybrid reachability becomes meaningful:
- Image reachability (static),
- Build reachability (build-time evidence),
- Runtime reachability (environment traces).
This must be second-class (tabs/sections), not buried.
Screen graph (Mermaid)
flowchart TD A[Environment Detail] --> B[Overview] A --> C[Promotion Rules] A --> D[Inputs\n(Vault/Consul mappings)] A --> E[SBOM & Findings Summary] A --> F[Reachability Coverage\n(image/build/runtime)] A --> G[Targets & Agents] A --> H[Audit Trail\n(decisions affecting env)]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Environment: us-prod (Region: US-East) │
│ Legacy: part of Settings ▸ Release Control ▸ Environments / scattered across Control Plane │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Tabs: [Overview] [Promotion] [Inputs] [SBOM & Findings] [Reachability] [Targets/Agents] [Audit]│
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Overview │
│ Current deployed bundle: bundle-us-prod-2026.02.18-01 │
│ Current deployed digests: 14 images (13 known scanned / 1 pending scan) │
│ │
│ Security summary (last 24h) │
│ Critical reachable: 1 | High reachable: 0 | High not reachable: 3 | VEX coverage: 62% │
│ “Why?” links → open Finding set filtered to env + reachability class │
│ │
│ Hybrid reachability coverage (2nd-class, but visible here) │
│ Image evidence: 100% | Build evidence: 78% | Runtime evidence: 35% │
│ Gap: runtime traces missing on 9 services → enable agent trace hook / importer │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.6 Screen — Deployment Targets
Formerly
- Settings → Release Control → Manage Targets
Why moved / reshaped
- Targets are release execution primitives (where things get deployed).
- Putting them under Release Control keeps “release execution” in the same domain as “release governance”.
Screen graph (Mermaid)
flowchart LR A[Targets] --> B[Target Detail] A --> C[Create Target] B --> D[Test Connection] B --> E[Assigned Environments]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Deployment Targets │
│ Legacy: Settings ▸ Release Control ▸ Targets (Manage Targets) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Region: [All] US-East EU-West APAC Type: [Docker Hosts] [VM Groups] [Baremetal] │
│ Actions: [+ Create Target] │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ ┌───────────────┬───────────┬─────────────┬──────────────┬─────────────────────────────────┐│
│ │ Target │ Region │ Status │ Last Check │ Used by Environments ││
│ ├───────────────┼───────────┼─────────────┼──────────────┼─────────────────────────────────┤│
│ │ docker-us-03 │ US-East │ HEALTHY │ 2m ago │ us-prod, us-stage ││
│ │ docker-eu-01 │ EU-West │ HEALTHY │ 3m ago │ eu-prod ││
│ │ docker-apac-02 │ APAC │ DEGRADED │ 12m ago │ apac-uat ││
│ └───────────────┴───────────┴─────────────┴──────────────┴─────────────────────────────────┘│
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.7 Screen — Agents
Formerly
- Settings → Release Control → Manage Agents
Why moved / reshaped
Agents are needed for:
- deployment execution,
- optional runtime evidence collection (hybrid reachability),
- replay/verify hooks.
Keeping them here keeps the “control plane” coherent with Stella’s evidence and reachability focus. (Gitea: Git with a cup of tea)
Screen graph (Mermaid)
flowchart TD A[Agents] --> B[Agent Detail] B --> C[Capabilities\n(deploy, trace, attest)] B --> D[Assigned Targets/Envs] B --> E[Health Logs]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Agents │
│ Legacy: Settings ▸ Release Control ▸ Agents (Manage Agents) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ ┌───────────────┬───────────┬─────────────┬─────────────────────┬──────────────────────────┐│
│ │ Agent │ Region │ Status │ Capabilities │ Assigned ││
│ ├───────────────┼───────────┼─────────────┼─────────────────────┼──────────────────────────┤│
│ │ agent-03 │ US-East │ HEALTHY │ deploy, attest, trace│ us-prod ││
│ │ agent-02 │ US-East │ HEALTHY │ deploy, attest │ us-stage ││
│ │ agent-apac-01 │ APAC │ DEGRADED │ deploy │ apac-uat ││
│ └───────────────┴───────────┴─────────────┴─────────────────────┴──────────────────────────┘│
│ Note: Trace capability drives “runtime reachability coverage” on env detail. │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.8 Screen — Workflows
Formerly
- Settings → Release Control → Edit Workflows
Why moved / reshaped
- Workflows are the standardized release execution templates (canary, A/B, rollback) that Stella highlights as part of release governance and controlled rollout. (Stella Ops Suite)
- This becomes the canonical place to manage them.
Screen graph (Mermaid)
flowchart LR A[Workflows] --> B[Workflow Editor] B --> C[Validate Workflow] B --> D[Publish Version] B --> E[Used by Releases/Policies]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Workflows │
│ Legacy: Settings ▸ Release Control ▸ Workflows (Edit Workflows) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ ┌──────────────────────┬───────────────┬──────────┬────────────────────────────────────────┐ │
│ │ Workflow │ Version │ Status │ Used by │ │
│ ├──────────────────────┼───────────────┼──────────┼────────────────────────────────────────┤ │
│ │ Rolling Update │ v3 │ ACTIVE │ default │ │
│ │ Canary 10% → 50% → 100│ v2 │ ACTIVE │ prod baselines │ │
│ │ Fast Rollback │ v1 │ ACTIVE │ incident response │ │
│ └──────────────────────┴───────────────┴──────────┴────────────────────────────────────────┘ │
│ Actions: [Create] [Edit] [Validate] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.9 Screen — Governance Hub (Policy baselines, gate rules, simulation, exception workflow)
Formerly
Settings → Policy Governance (
/settings/policy)- Policy Baselines
- Governance Rules
- Policy Simulation
- Exception Workflow
Why moved / reshaped
Governance is not “settings”; it is core Release Control:
- policy-as-code evaluation with traceable outcomes (“why blocked?”) and replayability is a stated Stella deliverable. (Gitea: Git with a cup of tea)
So it becomes: Release Control → Governance (still admin-controlled, but release-centric).
Screen graph (Mermaid)
flowchart TD A[Governance Hub] --> B[Policy Baselines] A --> C[Gate Rules] A --> D[Policy Simulation] A --> E[Exception Workflow Config] C --> F[Gate Detail\n(why blocked trace model)] E --> G[Security Exceptions\n(request/approve)]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Release Control ▸ Governance │
│ Legacy: Settings ▸ Policy Governance (/settings/policy) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Cards │
│ [Policy Baselines] [Gate Rules] [Policy Simulation] [Exception Workflow] │
│ │
│ Recent governance changes (audit-relevant) │
│ • Prod baseline updated: CVE freshness gate now “hard block” │
│ • Exception workflow: requires 2 approvers for critical reachable │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.10 Screen — Identity & Access
Formerly
- Settings → Identity & Access (
/settings/admin)
Why moved / reshaped
- This is classic administrative scope: users, roles, API keys, OAuth clients, tenants.
- Move under Administration, not in release/security menus.
Screen graph (Mermaid)
flowchart LR A[Identity & Access] --> B[Users] A --> C[Roles] A --> D[OAuth Clients] A --> E[API Tokens] A --> F[Tenants]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Administration ▸ Identity & Access │
│ Legacy: Settings ▸ Identity & Access (/settings/admin) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Tabs: [Users] [Roles] [OAuth Clients] [API Tokens] [Tenants] │
│ Banner: failures here can block approvals + evidence signing (auth). │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.11 Screen — Notifications
Formerly
- Settings → Notifications (
/settings/notifications)
Why moved / reshaped
- Also admin scope.
- But must support release-centric alerting: approvals waiting, feed stale, scan failed, evidence export ready.
Screen graph (Mermaid)
flowchart TD A[Notifications] --> B[Rules] A --> C[Channels] A --> D[Templates] A --> E[Delivery Log] B --> F[Rule Detail\n(event→recipients)]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Administration ▸ Notifications │
│ Legacy: Settings ▸ Notifications (/settings/notifications) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Rules (event triggers) Channels Templates │
│ - approval.pending → #release-approvals - Email: Active - Approval request │
│ - feed.stale → #sec-ops - Slack: Active - Feed stale alert │
│ - scan.failed → #build-cops - Webhook: Not configured - Scan failure │
│ - evidence.ready → email auditors │
│ [View Delivery Log] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.12 Screen — Usage & Limits
Formerly
- Settings → Usage & Limits (
/settings/usage)
Why moved / reshaped
- This is tenant/admin entitlement + limit configuration.
- Keep operational usage charts accessible, but do quota enforcement config here; operational throttles remain in Platform Ops → Quotas.
Screen graph (Mermaid)
flowchart LR A[Usage & Limits] --> B[Entitlements Summary] A --> C[Quota Configuration] A --> D[Usage Reports] A --> E[Throttle Events Link\n(to Ops Quotas)]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Administration ▸ Usage & Limits │
│ Legacy: Settings ▸ Usage & Limits (/settings/usage) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ This month: Scans 6,500/10,000 Storage 42/100 GB Evidence Packets 2,800/10,000 │
│ API Requests 15,000/100,000 │
│ │
│ [Configure Quotas] [Export Usage Report] Link: [View Operational Throttles (Ops ▸ Quotas)]│
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.13 Screen — System Console (Health / Doctor / SLO / Background Jobs)
Formerly
- Settings → System (
/settings/system)
Why moved / reshaped
System health + background jobs directly explain:
- “why are feeds stale?”
- “why are rescans failing?”
- “why are evidence exports missing?”
That’s operational, not “settings”. It becomes System (Platform), reachable as root and also second-class from the Dashboard “Nightly Ops Signals”.
Screen graph (Mermaid)
flowchart TD A[System Console] --> B[Health Check Detail] A --> C[Doctor] A --> D[SLO Monitoring] A --> E[Background Jobs] E --> F[Nightly Ops Report\n(job failures → impacts)] E --> G[Dead Letter Queue]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ System (Platform) │
│ Legacy: Settings ▸ System (/settings/system) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Health Check: ● All systems operational [View Details] │
│ Doctor: [Run Doctor] SLO Monitoring: [View SLOs] │
│ Background Jobs: [View Jobs] │
│ │
│ Operator note: job failures here must surface on Dashboard + block/reduce confidence in gates. │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.14 Screen — Trust & Signing
Formerly
- Settings → Trust & Signing (
/settings/trust)
Why moved / reshaped
This is the cryptographic and issuer-trust foundation for:
- DSSE evidence, attestations,
- issuer trust/conflict resolution for VEX,
- transparency logs.
Those belong under Evidence → Trust & Signing, consistent with Stella’s emphasis on verifiability and audit export. (Gitea: Git with a cup of tea)
Screen graph (Mermaid)
flowchart TD A[Trust & Signing] --> B[Signing Keys] A --> C[Issuers] A --> D[Certificates] A --> E[Transparency Log] A --> F[Trust Scoring] A --> G[Audit Log]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Evidence ▸ Trust & Signing │
│ Legacy: Settings ▸ Trust & Signing (/settings/trust) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Modules │
│ [Signing Keys] [Issuers] [Certificates] [Transparency Log] [Trust Scoring] [Audit Log] │
│ │
│ Why here: this config affects evidence packets, attestations, issuer trust, and audits. │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
What I did NOT include yet (next pack)
You explicitly flagged Release Bundle Organizer as crucial. It needs its own pack because it’s not a single screen—it’s a workflow:
- Bundle catalog (per repo / per product line),
- Bundle compose (digests → service versions),
- Env-var resolution (Vault + Consul mappings per env/region),
- Bundle changelog (per repository),
- Bundle → Release promotion linkage.
If you say “continue”, Pack 12 will be only the Bundle Organizer: full Mermaid graphs + ASCII mocks + “formerly/why” (it’s mostly net-new).