1373 lines
58 KiB
Markdown
1373 lines
58 KiB
Markdown
## Pack 9 — Admin + moved “Settings” pages (Mermaid per menu + Mermaid per screen + ASCII per screen)
|
||
|
||
This pack finishes the remaining “Settings” screens by **moving them into StellaOps-first roots** while keeping your main IA intact:
|
||
|
||
* **Release Control** stays a **root menu** (already done)
|
||
* **Security** stays a **root menu**
|
||
* **Evidence & Audit** stays a **root menu**
|
||
* **Operations** stays a **root menu**
|
||
* **Integrations** stays a **root menu**
|
||
* **Administration** becomes the place for the truly “settings/admin” things
|
||
|
||
---
|
||
|
||
# 0) Where each old “Settings” item goes now (mapping)
|
||
|
||
* **Settings → Integrations** ➜ **Integrations** (root)
|
||
*Why:* it’s a data-plane and must bubble health into approvals/release decisions.
|
||
|
||
* **Settings → Release Control** ➜ **Release Control** (root)
|
||
*Why:* release governance/config is first-class.
|
||
|
||
* **Settings → Policy Governance** ➜ **Release Control → Governance & Policy**
|
||
*Why:* these rules/baselines/simulation directly gate promotions and exceptions.
|
||
|
||
* **Settings → Trust & Signing** ➜ **Evidence & Audit → Trust & Signing**
|
||
*Why:* keys, transparency logs, and trust scoring are evidence primitives.
|
||
|
||
* **Settings → System** ➜ **Operations → Platform Admin** (admin-only)
|
||
*Why:* health/doctor/jobs are operational controls; not “settings”.
|
||
|
||
* **Settings → Security Data** ➜ **Integrations → Security Data Sources** (Pack 10)
|
||
*Why:* CVE feeds, VEX feeds, registry sources are integrations/data sources.
|
||
|
||
* **Settings → Identity & Access** ➜ **Administration → Identity & Access**
|
||
|
||
* **Settings → Tenant / Branding** ➜ **Administration → Tenants & Branding**
|
||
|
||
* **Settings → Usage & Limits** ➜ **Administration → Usage & Limits** (links to Ops quotas)
|
||
|
||
* **Settings → Notifications** ➜ **Administration → Notifications**
|
||
|
||
---
|
||
|
||
# 1) Administration menu graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
ADM[Administration] --> ADM_IAM[Identity & Access]
|
||
ADM --> ADM_TENANT[Tenants & Branding]
|
||
ADM --> ADM_NOTIF[Notifications]
|
||
ADM --> ADM_USAGE[Usage & Limits]
|
||
|
||
ADM_IAM --> IAM_USERS[Users]
|
||
ADM_IAM --> IAM_ROLES[Roles]
|
||
ADM_IAM --> IAM_OAUTH[OAuth Clients]
|
||
ADM_IAM --> IAM_TOKENS[API Tokens]
|
||
ADM_IAM --> IAM_TENANTS[Tenants]
|
||
|
||
ADM_NOTIF --> N_RULES[Notification Rules]
|
||
ADM_NOTIF --> N_CHANNELS[Channels]
|
||
ADM_NOTIF --> N_TEMPL[Templates]
|
||
ADM_NOTIF --> N_LOG[Activity Log]
|
||
```
|
||
|
||
---
|
||
|
||
## 2) Administration → Identity & Access (landing)
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** `Settings → Identity & Access` (`/settings/admin`)
|
||
|
||
### Now (Redesign)
|
||
|
||
* **Now:** `Administration → Identity & Access`
|
||
* Still the same capability set, but:
|
||
|
||
* links “Tenants” to **Tenants & Branding** (admin model)
|
||
* adds “Where used” indicators (e.g., API tokens used by integrations/agents)
|
||
|
||
### Why changed
|
||
|
||
Identity is not release governance. It’s administrative plumbing. It should not clutter the release/security core, but it must remain accessible.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A[Administration: Identity & Access] --> U[Users]
|
||
A --> R[Roles]
|
||
A --> O[OAuth Clients]
|
||
A --> T[API Tokens]
|
||
A --> TN[Tenants]
|
||
A --> INT[Integrations (tokens used by connectors)]
|
||
A --> OPS[Operations (admin-only actions)]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ ADMINISTRATION ▸ IDENTITY & ACCESS │
|
||
│ Formerly: Settings ▸ Identity & Access │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Tabs: [Users] [Roles] [OAuth Clients] [API Tokens] [Tenants] │
|
||
│ Banner (if backend degraded): “IAM service unavailable” → [Open Platform Admin]│
|
||
│ │
|
||
│ Quick actions: [+ Add User] [+ Create Role] [+ New OAuth Client] │
|
||
│ Notes: Tokens used by Integrations/Agents are shown with “in use” badges. │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 3) Administration → Identity & Access → Users
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** `Settings → Identity & Access → Users` tab
|
||
|
||
### Now
|
||
|
||
* **Now:** `Administration → Identity & Access → Users`
|
||
|
||
### Why changed
|
||
|
||
Same function; new placement keeps “settings” out of release/security but still first-accessible.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
U[Users] --> UD[User Detail]
|
||
U --> R[Roles]
|
||
U --> T[API Tokens]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ ADMIN ▸ IAM ▸ USERS │
|
||
│ Formerly: Settings ▸ Identity & Access ▸ Users │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Search: [ name/email/role ] Filters: Status ▾ Role ▾ Tenant ▾ │
|
||
│ │
|
||
│ NAME EMAIL ROLE STATUS ACTIONS │
|
||
│ alice alice@… releasemgr active [Edit] [Disable] │
|
||
│ bob bob@… security active [Edit] [Disable] │
|
||
│ │
|
||
│ [+ Add User] │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 4) Administration → Identity & Access → Roles
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** `Settings → Identity & Access → Roles` tab
|
||
|
||
### Now
|
||
|
||
* **Now:** `Administration → Identity & Access → Roles`
|
||
|
||
### Why changed
|
||
|
||
RBAC belongs in Administration; it controls who can approve/promote/manage evidence.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
R[Roles] --> RD[Role Detail / Permissions]
|
||
R --> U[Users]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ ADMIN ▸ IAM ▸ ROLES │
|
||
│ Formerly: Settings ▸ Identity & Access ▸ Roles │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ ROLE DESCRIPTION PERMISSIONS (summary) │
|
||
│ releasemgr release approvals approve, promote, export evidence │
|
||
│ security findings/vex/exceptions view+manage exceptions, vex │
|
||
│ auditor read-only evidence view bundles, proofs, exports │
|
||
│ [+ Create Role] │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 5) Administration → Identity & Access → OAuth Clients
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** `Settings → Identity & Access → OAuth Clients` tab
|
||
|
||
### Now
|
||
|
||
* **Now:** `Administration → Identity & Access → OAuth Clients`
|
||
|
||
### Why changed
|
||
|
||
OAuth clients are how external systems authenticate; they are part of admin posture and should be auditable.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
O[OAuth Clients] --> OD[Client Detail]
|
||
O --> T[API Tokens]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ ADMIN ▸ IAM ▸ OAUTH CLIENTS │
|
||
│ Formerly: Settings ▸ Identity & Access ▸ OAuth Clients │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ CLIENT REDIRECTS SCOPES STATUS ACTIONS │
|
||
│ ci-bot …/callback read:releases,write… active [Rotate] │
|
||
│ auditor-app …/cb read:evidence active [Rotate] │
|
||
│ [+ New Client] │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 6) Administration → Identity & Access → API Tokens
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** `Settings → Identity & Access → API Tokens` tab
|
||
|
||
### Now
|
||
|
||
* **Now:** `Administration → Identity & Access → API Tokens`
|
||
|
||
### Why changed
|
||
|
||
Tokens should show **where they’re used** (integrations/agents) so you can rotate safely without breaking pipelines.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
T[API Tokens] --> TD[Token Detail]
|
||
T --> INT[Integrations]
|
||
T --> AG[Release Control: Delivery Agents]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ ADMIN ▸ IAM ▸ API TOKENS │
|
||
│ Formerly: Settings ▸ Identity & Access ▸ API Tokens │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ TOKEN NAME OWNER LAST USED USED BY STATUS ACTIONS │
|
||
│ reg-sync ci-bot 5m ago Integrations: Harbor active [Rotate]│
|
||
│ agent-eu-1 ops 1m ago Agent: agent-eu-1 active [Rotate]│
|
||
│ [+ Create Token] │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 7) Administration → Identity & Access → Tenants
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** `Settings → Identity & Access → Tenants` tab
|
||
|
||
### Now
|
||
|
||
* **Now:** `Administration → Identity & Access → Tenants` (and cross-links to Tenants & Branding)
|
||
|
||
### Why changed
|
||
|
||
Tenant management is admin, but branding is a separate concern—separating reduces clutter.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
TN[Tenants] --> TND[Tenant Detail]
|
||
TN --> TB[Tenants & Branding]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ ADMIN ▸ IAM ▸ TENANTS │
|
||
│ Formerly: Settings ▸ Identity & Access ▸ Tenants │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ TENANT PLAN REGIONS ENABLED STATUS ACTIONS │
|
||
│ acme enterprise eu-west, us-east active [Open] │
|
||
│ demo trial us-east active [Open] │
|
||
│ Branding lives in: Administration ▸ Tenants & Branding → [Open] │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
# 3) Administration → Tenants & Branding
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** `Settings → Tenant / Branding`
|
||
|
||
### Now
|
||
|
||
* **Now:** `Administration → Tenants & Branding`
|
||
|
||
* Tenant metadata + branding config (logo, theme, domains)
|
||
* Optional per-tenant notification defaults
|
||
|
||
### Why changed
|
||
|
||
It’s admin-only, not part of the release security workflow. Keeping it separate reduces cognitive noise.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
TB[Tenants & Branding] --> TND[Tenant Branding Detail]
|
||
TB --> IAM[Identity & Access: Tenants]
|
||
TB --> N[Notifications (tenant defaults)]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ ADMINISTRATION ▸ TENANTS & BRANDING │
|
||
│ Formerly: Settings ▸ Tenant / Branding │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Tenant ▾ (acme) │
|
||
│ Branding: Logo [Upload] Product name [Stella Ops] Domain [acme.stella…] │
|
||
│ UI options: timezone default, regional labels, footer compliance text │
|
||
│ [Save] [Preview] │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
# 4) Administration → Notifications (landing)
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** `Settings → Notifications` (`/settings/notifications`)
|
||
|
||
### Now
|
||
|
||
* **Now:** `Administration → Notifications`
|
||
|
||
* Adds “source events” from:
|
||
|
||
* approvals
|
||
* releases/hotfixes
|
||
* security findings (reachable criticals)
|
||
* data health (feeds stale, scans failing)
|
||
* Tenant defaults link (if multi-tenant)
|
||
|
||
### Why changed
|
||
|
||
Notifications are a control system that supports release governance, but do not belong under Release Control itself.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
N[Administration: Notifications] --> NR[Notification Rules]
|
||
N --> NC[Channels]
|
||
N --> NT[Templates]
|
||
N --> NL[Activity Log]
|
||
N --> RC[Release Control (event sources)]
|
||
N --> SEC[Security (event sources)]
|
||
N --> OPS[Operations (health events)]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ ADMINISTRATION ▸ NOTIFICATIONS │
|
||
│ Formerly: Settings ▸ Notifications │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Cards: │
|
||
│ - Notification Rules [ + Add Rule ] │
|
||
│ - Channels (Email/Slack/Webhook) │
|
||
│ - Templates [Edit Templates] │
|
||
│ - Activity Log [View Log] │
|
||
│ │
|
||
│ Common triggers: “Approval blocked by crit reachable”, “NVD stale”, “Hotfix done”│
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 5) Administration → Notifications → Notification Rules
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** Settings notifications “Rules” card
|
||
|
||
### Now
|
||
|
||
* **Now:** Admin Notifications Rules includes:
|
||
|
||
* event type
|
||
* scope filters (region/env/bundle/severity)
|
||
* delivery channels
|
||
* deduping and escalation
|
||
|
||
### Why changed
|
||
|
||
Rules must be region/env aware to support multi-region governance without spam.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
NR[Notification Rules] --> NRD[Rule Detail]
|
||
NR --> NC[Channels]
|
||
NR --> NT[Templates]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ ADMIN ▸ NOTIFICATIONS ▸ RULES │
|
||
│ Formerly: Settings ▸ Notifications ▸ Notification Rules │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Rule: “Reachable Critical in Production” │
|
||
│ Trigger: Security Finding (severity=CRIT, reachable=YES) │
|
||
│ Scope: Region=Any, Env=Production, Bundle=Any │
|
||
│ Channel: Slack #release-alerts + Email sec@… │
|
||
│ [Enable] [Edit] [Test] [Disable] │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 6) Administration → Notifications → Channels
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** Settings notifications “Channels” card
|
||
|
||
### Now
|
||
|
||
* **Now:** same capabilities; adds “used by rules” reference list.
|
||
|
||
### Why changed
|
||
|
||
This prevents breaking notifications during rotation or migration.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
NC[Channels] --> NCD[Channel Detail]
|
||
NC --> NR[Rules]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ ADMIN ▸ NOTIFICATIONS ▸ CHANNELS │
|
||
│ Formerly: Settings ▸ Notifications ▸ Channels │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Email (Active) from: noreply@… Used by: 4 rules [Edit] │
|
||
│ Slack (Active) workspace: … Used by: 7 rules [Edit] │
|
||
│ Webhook (Not configured) Used by: 0 rules [Configure] │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 7) Administration → Notifications → Templates
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** Settings notifications “Templates” card
|
||
|
||
### Now
|
||
|
||
* **Now:** templates include decision context (bundle/version/env/region + evidence link).
|
||
|
||
### Why changed
|
||
|
||
Notifications must carry **actionable** release governance context.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
NT[Templates] --> NTE[Template Editor]
|
||
NT --> NR[Rules]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ ADMIN ▸ NOTIFICATIONS ▸ TEMPLATES │
|
||
│ Formerly: Settings ▸ Notifications ▸ Templates │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Template: “Approval Blocked” │
|
||
│ Variables: {region} {env} {bundle} {crit_reachable} {evidence_url} │
|
||
│ Preview: “prod-eu blocked: api-gateway v2.1.0 has 3 critical reachable…” │
|
||
│ [Edit] [Preview] [Save] │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 8) Administration → Notifications → Activity Log
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** Settings notifications “Activity Log” card
|
||
|
||
### Now
|
||
|
||
* **Now:** includes delivery audit trail with links back to the originating event (approval/release/finding).
|
||
|
||
### Why changed
|
||
|
||
Auditors may ask “who was notified and when,” especially around exceptions/hotfixes.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
NL[Notification Activity Log] --> AD[Approval Detail]
|
||
NL --> RD[Release Detail]
|
||
NL --> FD[Finding Detail]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ ADMIN ▸ NOTIFICATIONS ▸ ACTIVITY LOG │
|
||
│ Formerly: Settings ▸ Notifications ▸ Activity Log │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Time Event Channel Result Link │
|
||
│ 08:31 Approval blocked (crit*) Slack OK [Open Approval] │
|
||
│ 08:15 NVD feed stale Email OK [Nightly Ops] │
|
||
│ 07:55 Hotfix completed prod-eu Slack OK [Open Release] │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
# 5) Administration → Usage & Limits
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** `Settings → Usage & Limits` (`/settings/usage`)
|
||
Included scan counts, storage, evidence packets, API requests, and “Configure Quotas”.
|
||
|
||
### Now
|
||
|
||
* **Now:** `Administration → Usage & Limits`
|
||
|
||
* Keeps usage metrics + quota config
|
||
* Adds links to:
|
||
|
||
* **Operations → Quotas dashboard** (runtime throttles/events)
|
||
* **Operations → Scheduler/Background Jobs** for cost drivers (nightly rescans)
|
||
|
||
### Why changed
|
||
|
||
This is administrative oversight (billing/limits). Operational throttles and job health remain under Operations.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
UL[Administration: Usage & Limits] --> QCFG[Quota Configuration]
|
||
UL --> OQ[Operations: Quotas Dashboard]
|
||
UL --> OPS[Operations: Scheduler/Background Jobs]
|
||
UL --> EV[Evidence & Audit (storage consumers)]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ ADMINISTRATION ▸ USAGE & LIMITS │
|
||
│ Formerly: Settings ▸ Usage & Limits │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Usage (this month): Scans 6,500/10,000 | Storage 42GB/100GB | Evidence 2,800 │
|
||
│ API Requests: 15,000/100,000 │
|
||
│ │
|
||
│ Quota Configuration: [Configure Quotas] │
|
||
│ Operational throttles live in: Operations ▸ Quotas → [Open] │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
# 6) Moved from Settings → Policy Governance ➜ Release Control → Governance & Policy
|
||
|
||
## Release Control → Governance & Policy (menu graph)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
GP[Release Control: Governance & Policy] --> PB[Policy Baselines]
|
||
GP --> GR[Governance Rules]
|
||
GP --> PS[Policy Simulation]
|
||
GP --> EW[Exception Workflow]
|
||
GP --> AQ[Approvals Queue]
|
||
GP --> SEC[Security (inputs)]
|
||
GP --> EV[Evidence & Audit (signing/proofs)]
|
||
```
|
||
|
||
---
|
||
|
||
## 9) Release Control → Governance & Policy (landing)
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** `Settings → Policy Governance` (`/settings/policy`)
|
||
|
||
### Now
|
||
|
||
* **Now:** `Release Control → Governance & Policy`
|
||
|
||
### Why changed
|
||
|
||
These controls define:
|
||
|
||
* what blocks/permits promotion,
|
||
* what evidence is required,
|
||
* how exceptions are handled.
|
||
That is **release governance**, not generic settings.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
GP[Governance & Policy] --> PB[Policy Baselines]
|
||
GP --> GR[Governance Rules]
|
||
GP --> PS[Policy Simulation]
|
||
GP --> EW[Exception Workflow]
|
||
GP --> AQ[Approvals Queue]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ RELEASE CONTROL ▸ GOVERNANCE & POLICY │
|
||
│ Formerly: Settings ▸ Policy Governance │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Cards: │
|
||
│ - Policy Baselines [+ Create Baseline] │
|
||
│ - Governance Rules [Edit Rules] │
|
||
│ - Policy Simulation [Run Simulation] │
|
||
│ - Exception Workflow [Configure Workflow] │
|
||
│ Notes: rules can be scoped by region/env/promotion hop. │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 10) Release Control → Governance & Policy → Policy Baselines
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** Settings policy baselines card
|
||
|
||
### Now
|
||
|
||
* **Now:** Baselines are explicitly scoped by **Region + Env + Promotion hop**.
|
||
|
||
### Why changed
|
||
|
||
Baselines must differ per region/env and must be traceable to approvals.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
PB[Policy Baselines] --> PBD[Baseline Detail]
|
||
PB --> GR[Governance Rules]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ RELEASE CONTROL ▸ POLICY BASELINES │
|
||
│ Formerly: Settings ▸ Policy Governance ▸ Policy Baselines │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Baseline Scope (region/env) Promotion hop Key checks │
|
||
│ prod-core eu-west/prod-eu staging→prod no crit reachable, VEX │
|
||
│ staging-lite us-east/staging-us dev→staging scan required │
|
||
│ [+ Create Baseline] │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 11) Release Control → Governance & Policy → Governance Rules
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** Settings governance rules card
|
||
|
||
### Now
|
||
|
||
* **Now:** Rules are expressed in release terms:
|
||
|
||
* bundle/version
|
||
* region/env
|
||
* hybrid reachability
|
||
* evidence completeness
|
||
|
||
### Why changed
|
||
|
||
Rules should directly map to “why approval is blocked” and be exportable in evidence.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
GR[Governance Rules] --> GRD[Rule Detail]
|
||
GR --> AQ[Approvals Queue (blocked by rule)]
|
||
GR --> PS[Policy Simulation]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ RELEASE CONTROL ▸ GOVERNANCE RULES │
|
||
│ Formerly: Settings ▸ Policy Governance ▸ Governance Rules │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Rule: Block promotion if (severity=CRIT AND hybrid_reachable=YES) in target env│
|
||
│ Rule: Require signed policy decision + proof chain for staging→prod │
|
||
│ Rule: Allow override only via exception workflow with expiry │
|
||
│ [Edit] [Version] [Audit history] │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 12) Release Control → Governance & Policy → Policy Simulation
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** Settings policy simulation card
|
||
|
||
### Now
|
||
|
||
* **Now:** Simulation runs against:
|
||
|
||
* a bundle version
|
||
* a region/env path
|
||
* current data freshness state
|
||
* produces a “would pass/would block” report
|
||
|
||
### Why changed
|
||
|
||
This reduces failed promotions and makes policy changes safer.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
PS[Policy Simulation] --> PSR[Simulation Report]
|
||
PS --> PB[Policy Baselines]
|
||
PS --> GR[Governance Rules]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ RELEASE CONTROL ▸ POLICY SIMULATION │
|
||
│ Formerly: Settings ▸ Policy Governance ▸ Policy Simulation │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Inputs: Bundle ▾ Region ▾ Path ▾ Data snapshot ▾(now/last night) │
|
||
│ Output: PASS/BLOCK + reasons │
|
||
│ Example: BLOCK (3 critical reachable in prod-eu; NVD stale warns) │
|
||
│ [Run] [Export Report] │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 13) Release Control → Governance & Policy → Exception Workflow
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** Settings exception workflow card
|
||
|
||
### Now
|
||
|
||
* **Now:** Exception workflow is explicitly tied to approvals and evidence:
|
||
|
||
* required approvers
|
||
* maximum duration
|
||
* required mitigation fields
|
||
* automatic reminders on expiry
|
||
|
||
### Why changed
|
||
|
||
Exceptions are a release governance primitive and must be captured as evidence.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
EW[Exception Workflow] --> EX[Security Exceptions]
|
||
EW --> AQ[Approvals Queue]
|
||
EW --> EV[Evidence & Audit: Export]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ RELEASE CONTROL ▸ EXCEPTION WORKFLOW │
|
||
│ Formerly: Settings ▸ Policy Governance ▸ Exception Workflow │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Required approvers: security-lead + release-manager │
|
||
│ Max duration: 30 days Renewal requires: updated mitigation + fresh scan │
|
||
│ Fields: reason, mitigation, scope(region/env/bundle), expiry │
|
||
│ Notifications: 14d/7d/1d before expiry │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
# 7) Moved from Settings → Trust & Signing ➜ Evidence & Audit → Trust & Signing
|
||
|
||
## Evidence & Audit → Trust & Signing (menu graph)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
TS[Evidence & Audit: Trust & Signing] --> SK[Signing Keys]
|
||
TS --> IS[Issuers]
|
||
TS --> C[Certificates]
|
||
TS --> TL[Transparency Log]
|
||
TS --> SC[Trust Scoring]
|
||
TS --> AL[Audit Log]
|
||
TS --> EV[Evidence Bundles/Proof Chains]
|
||
TS --> VEX[VEX Hub]
|
||
```
|
||
|
||
---
|
||
|
||
## 14) Evidence & Audit → Trust & Signing (landing)
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** `Settings → Trust & Signing` (`/settings/trust`)
|
||
|
||
### Now
|
||
|
||
* **Now:** `Evidence & Audit → Trust & Signing`
|
||
|
||
### Why changed
|
||
|
||
This is foundational for:
|
||
|
||
* signing evidence packets
|
||
* verifying VEX statements
|
||
* producing auditor-ready proof chains
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
TS[Trust & Signing] --> SK[Signing Keys]
|
||
TS --> IS[Issuers]
|
||
TS --> C[Certificates]
|
||
TS --> TL[Transparency Log]
|
||
TS --> SC[Trust Scoring]
|
||
TS --> AL[Audit Log]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ EVIDENCE & AUDIT ▸ TRUST & SIGNING │
|
||
│ Formerly: Settings ▸ Trust & Signing │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Cards: [Signing Keys] [Issuers] [Certificates] │
|
||
│ [Transparency Log] [Trust Scoring] [Audit Log] │
|
||
│ Notes: Used by Evidence Bundles, Proof Chains, VEX statements. │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 15) Evidence & Audit → Trust & Signing → Signing Keys
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** Settings trust & signing → signing keys
|
||
|
||
### Now
|
||
|
||
* **Now:** keys are labeled by usage:
|
||
|
||
* evidence signing
|
||
* policy decision signing
|
||
* VEX signing (issuer-bound)
|
||
|
||
### Why changed
|
||
|
||
You need clean provenance: which keys sign what artifacts.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
SK[Signing Keys] --> SKD[Key Detail]
|
||
SK --> EV[Evidence Bundles]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ EVIDENCE ▸ TRUST & SIGNING ▸ SIGNING KEYS │
|
||
│ Formerly: Settings ▸ Trust & Signing ▸ Signing Keys │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Key Type Usage Rotation Status │
|
||
│ evidence-k1 KMS evidence bundles, proofs 90d active │
|
||
│ policy-k1 KMS signed policy decisions 30d active │
|
||
│ [Manage Keys] │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 16) Evidence & Audit → Trust & Signing → Issuers
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** Settings trust & signing → issuers
|
||
|
||
### Now
|
||
|
||
* **Now:** issuer trust is tied to:
|
||
|
||
* VEX acceptance
|
||
* attestation verification
|
||
|
||
### Why changed
|
||
|
||
Issuer trust determines what evidence is accepted.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
IS[Issuers] --> ISD[Issuer Detail]
|
||
IS --> VEX[VEX Hub]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ EVIDENCE ▸ TRUST & SIGNING ▸ ISSUERS │
|
||
│ Formerly: Settings ▸ Trust & Signing ▸ Issuers │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Issuer Scope Trusted For Status │
|
||
│ VendorA VEX statements VEX trusted │
|
||
│ InternalSec policy decisions policy+evidence trusted │
|
||
│ [Manage Issuers] │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 17) Evidence & Audit → Trust & Signing → Certificates
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** Settings trust & signing → certificates
|
||
|
||
### Now
|
||
|
||
* **Now:** certificates are tied to signing and verification chains.
|
||
|
||
### Why changed
|
||
|
||
Auditors want to validate the chain without hunting around.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
C[Certificates] --> CD[Certificate Detail]
|
||
C --> EV[Evidence Bundles]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ EVIDENCE ▸ TRUST & SIGNING ▸ CERTIFICATES │
|
||
│ Formerly: Settings ▸ Trust & Signing ▸ Certificates │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Cert Used For Expires Status │
|
||
│ org-root verify issuers 2027-… active │
|
||
│ tls-admin UI/API TLS 2026-… active │
|
||
│ [Manage Certificates] │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 18) Evidence & Audit → Trust & Signing → Transparency Log
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** Settings trust & signing → transparency log (Rekor)
|
||
|
||
### Now
|
||
|
||
* **Now:** it’s explicitly used by:
|
||
|
||
* evidence bundle envelopes
|
||
* signed decisions
|
||
* VEX statements (if configured)
|
||
|
||
### Why changed
|
||
|
||
Transparency logs are part of “proof you didn’t tamper.”
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
TL[Transparency Log] --> TLD[Rekor Config]
|
||
TL --> EV[Evidence Bundles]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ EVIDENCE ▸ TRUST & SIGNING ▸ TRANSPARENCY LOG │
|
||
│ Formerly: Settings ▸ Trust & Signing ▸ Transparency Log │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Rekor: configured ✓ Endpoint: … │
|
||
│ Recorded artifacts (last 7d): 1,204 │
|
||
│ [Configure Rekor] [View Records] │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 19) Evidence & Audit → Trust & Signing → Trust Scoring
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** Settings trust & signing → trust scoring
|
||
|
||
### Now
|
||
|
||
* **Now:** scoring influences UI badges and policy gates (optional).
|
||
|
||
### Why changed
|
||
|
||
Make “trust” explainable and consistent (not tribal knowledge).
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
SC[Trust Scoring] --> SCD[Score Config]
|
||
SC --> GR[Release Control: Governance Rules]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ EVIDENCE ▸ TRUST & SIGNING ▸ TRUST SCORING │
|
||
│ Formerly: Settings ▸ Trust & Signing ▸ Trust Scoring │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Scoring inputs: issuer trust, signature validity, transparency log presence, │
|
||
│ proof chain completeness │
|
||
│ Output: TRUST score 0–100 shown on bundles/evidence. │
|
||
│ [Edit Score Config] │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 20) Evidence & Audit → Trust & Signing → Audit Log
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** Settings trust & signing → audit log
|
||
|
||
### Now
|
||
|
||
* **Now:** audit events link back to:
|
||
|
||
* key rotations
|
||
* issuer changes
|
||
* evidence exports
|
||
* policy changes
|
||
|
||
### Why changed
|
||
|
||
It’s a compliance primitive and belongs with evidence controls.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
AL[Audit Log] --> EV[Evidence Export]
|
||
AL --> SK[Signing Keys]
|
||
AL --> GR[Governance Rules]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ EVIDENCE ▸ TRUST & SIGNING ▸ AUDIT LOG │
|
||
│ Formerly: Settings ▸ Trust & Signing ▸ Audit Log │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Time Actor Action Object Link │
|
||
│ 08:10 admin rotated key policy-k1 [Open] │
|
||
│ 07:40 sec-lead trusted issuer VendorA [Open] │
|
||
│ 07:05 auditor exported evidence audit-bundle [Open] │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
# 8) Moved from Settings → System ➜ Operations → Platform Admin (admin-only)
|
||
|
||
## Operations → Platform Admin (menu graph)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
PA[Operations: Platform Admin] --> HC[Health Check]
|
||
PA --> DR[Doctor]
|
||
PA --> SLO[SLO Monitoring]
|
||
PA --> BJ[Background Jobs]
|
||
PA --> OPS[Operations pages (Scheduler/Orchestrator/etc)]
|
||
```
|
||
|
||
---
|
||
|
||
## 21) Operations → Platform Admin (landing)
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** `Settings → System` (`/settings/system`)
|
||
|
||
### Now
|
||
|
||
* **Now:** `Operations → Platform Admin` (admin-only)
|
||
|
||
### Why changed
|
||
|
||
System health and diagnostics are operational. They affect release governance indirectly (data freshness, job failures), but belong in Operations.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
PA[Platform Admin] --> HC[Health Check Details]
|
||
PA --> DR[Run Doctor]
|
||
PA --> SLO[View SLOs]
|
||
PA --> BJ[Background Jobs]
|
||
PA --> N[Operations: Nightly Ops Report]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ OPERATIONS ▸ PLATFORM ADMIN (Admin only) │
|
||
│ Formerly: Settings ▸ System │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Cards: │
|
||
│ - Health Check (All systems operational) [View Details] │
|
||
│ - Doctor (diagnostics) [Run Doctor] │
|
||
│ - SLO Monitoring (SLOs) [View SLOs] │
|
||
│ - Background Jobs (job processing) [View Jobs] │
|
||
│ Links: [Nightly Ops Report] (feeds/scans/rescans) │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 22) Operations → Platform Admin → Health Check Details
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** Settings System → Health Check
|
||
|
||
### Now
|
||
|
||
* **Now:** Ops Platform Admin → Health Check details
|
||
|
||
### Why changed
|
||
|
||
Makes it clear this is operational diagnostics, not release governance UI.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
HC[Health Check Details] --> INT[Integrations Status]
|
||
HC --> OPS[Operations: Scheduler/Orchestrator]
|
||
HC --> N[Nightly Ops Report]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ OPS ▸ PLATFORM ADMIN ▸ HEALTH CHECK DETAILS │
|
||
│ Formerly: Settings ▸ System ▸ Health Check │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Component Status Notes │
|
||
│ API OK - │
|
||
│ SBOM ingest DEGRADED backlog growing │
|
||
│ CVE sync WARN NVD stale │
|
||
│ [Open Integrations] [Open Nightly Ops] │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 23) Operations → Platform Admin → Doctor
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** Settings System → Doctor
|
||
|
||
### Now
|
||
|
||
* **Now:** Ops Platform Admin → Doctor
|
||
|
||
### Why changed
|
||
|
||
Doctor is a diagnostic operator tool; it belongs near Orchestrator/Scheduler.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
DR[Doctor] --> HC[Health Check Details]
|
||
DR --> DL[Dead Letter]
|
||
DR --> S[Scheduler Runs]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ OPS ▸ PLATFORM ADMIN ▸ DOCTOR │
|
||
│ Formerly: Settings ▸ System ▸ Doctor │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Checks: DB connectivity, queue health, feed sync, registry auth, vault auth │
|
||
│ [Run Doctor] Output: PASS/WARN/FAIL with remediation links │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 24) Operations → Platform Admin → SLO Monitoring
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** Settings System → SLO Monitoring
|
||
|
||
### Now
|
||
|
||
* **Now:** Ops Platform Admin → SLO Monitoring
|
||
|
||
### Why changed
|
||
|
||
SLOs affect reliability and data freshness which affects approval confidence.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
SLO[SLO Monitoring] --> OPS[Operations dashboards]
|
||
SLO --> N[Nightly Ops Report]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ OPS ▸ PLATFORM ADMIN ▸ SLO MONITORING │
|
||
│ Formerly: Settings ▸ System ▸ SLO Monitoring │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ SLO: “CVE feed freshness < 6h” Current: FAIL (NVD stale) │
|
||
│ SLO: “SBOM ingest lag < 15m” Current: WARN │
|
||
│ [View SLOs] [Open Nightly Ops] │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 25) Operations → Platform Admin → Background Jobs
|
||
|
||
### Previously
|
||
|
||
* **Formerly:** Settings System → Background Jobs
|
||
|
||
### Now
|
||
|
||
* **Now:** Ops Platform Admin → Background Jobs (links to Scheduler/Dead Letter)
|
||
|
||
### Why changed
|
||
|
||
Jobs are an operational substrate; failures must show up as data-health risks to release governance.
|
||
|
||
### Screen graph (Mermaid)
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
BJ[Background Jobs] --> S[Scheduler Runs]
|
||
BJ --> DL[Dead Letter]
|
||
BJ --> N[Nightly Ops Report]
|
||
```
|
||
|
||
### ASCII mock
|
||
|
||
```text
|
||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||
│ OPS ▸ PLATFORM ADMIN ▸ BACKGROUND JOBS │
|
||
│ Formerly: Settings ▸ System ▸ Background Jobs │
|
||
├───────────────────────────────────────────────────────────────────────────────┤
|
||
│ Job Last Run Status Notes │
|
||
│ nightly-sbom-rescan 02:00 FAIL registry auth timeout │
|
||
│ cve-sync-nvd 02:05 FAIL upstream unreachable │
|
||
│ reachability-runtime-ingest 02:10 WARN agent-eu-2 degraded │
|
||
│ [Open Scheduler Runs] [Open Dead Letter] [Open Nightly Ops Report] │
|
||
└───────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## What’s left (next pack)
|
||
|
||
**Pack 10 — Integrations (root):** Integrations page + Feeds (mirrors/airgap/version locks) + “Security Data Sources” mapping, with the same Mermaid + ASCII + Formerly/Why.
|
||
|
||
Say “Pack 10” and I’ll continue.
|