## 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.