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

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)

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

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  U[Users] --> UD[User Detail]
  U --> R[Roles]
  U --> T[API Tokens]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  R[Roles] --> RD[Role Detail / Permissions]
  R --> U[Users]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  O[OAuth Clients] --> OD[Client Detail]
  O --> T[API Tokens]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  T[API Tokens] --> TD[Token Detail]
  T --> INT[Integrations]
  T --> AG[Release Control: Delivery Agents]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  TN[Tenants] --> TND[Tenant Detail]
  TN --> TB[Tenants & Branding]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  TB[Tenants & Branding] --> TND[Tenant Branding Detail]
  TB --> IAM[Identity & Access: Tenants]
  TB --> N[Notifications (tenant defaults)]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

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

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  NR[Notification Rules] --> NRD[Rule Detail]
  NR --> NC[Channels]
  NR --> NT[Templates]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  NC[Channels] --> NCD[Channel Detail]
  NC --> NR[Rules]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  NT[Templates] --> NTE[Template Editor]
  NT --> NR[Rules]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  NL[Notification Activity Log] --> AD[Approval Detail]
  NL --> RD[Release Detail]
  NL --> FD[Finding Detail]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

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

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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

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)

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

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  PB[Policy Baselines] --> PBD[Baseline Detail]
  PB --> GR[Governance Rules]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  GR[Governance Rules] --> GRD[Rule Detail]
  GR --> AQ[Approvals Queue (blocked by rule)]
  GR --> PS[Policy Simulation]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  PS[Policy Simulation] --> PSR[Simulation Report]
  PS --> PB[Policy Baselines]
  PS --> GR[Governance Rules]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  EW[Exception Workflow] --> EX[Security Exceptions]
  EW --> AQ[Approvals Queue]
  EW --> EV[Evidence & Audit: Export]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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

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)

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

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  SK[Signing Keys] --> SKD[Key Detail]
  SK --> EV[Evidence Bundles]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  IS[Issuers] --> ISD[Issuer Detail]
  IS --> VEX[VEX Hub]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  C[Certificates] --> CD[Certificate Detail]
  C --> EV[Evidence Bundles]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  TL[Transparency Log] --> TLD[Rekor Config]
  TL --> EV[Evidence Bundles]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  SC[Trust Scoring] --> SCD[Score Config]
  SC --> GR[Release Control: Governance Rules]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  AL[Audit Log] --> EV[Evidence Export]
  AL --> SK[Signing Keys]
  AL --> GR[Governance Rules]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

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)

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

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  HC[Health Check Details] --> INT[Integrations Status]
  HC --> OPS[Operations: Scheduler/Orchestrator]
  HC --> N[Nightly Ops Report]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  DR[Doctor] --> HC[Health Check Details]
  DR --> DL[Dead Letter]
  DR --> S[Scheduler Runs]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  SLO[SLO Monitoring] --> OPS[Operations dashboards]
  SLO --> N[Nightly Ops Report]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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)

flowchart TD
  BJ[Background Jobs] --> S[Scheduler Runs]
  BJ --> DL[Dead Letter]
  BJ --> N[Nightly Ops Report]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────┐
│ 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.