Stella Ops Module Documentation Index

This is the entry point for the architecture documentation of every Stella Ops module. Use it to find the dossier for a given module, understand how the source tree maps to docs, and track which historical modules have been consolidated into a parent.

Conventions

• Module doc directories use kebab-case names that map to the PascalCase src/ directory (e.g. binary-index/ → src/BinaryIndex/).
• Only product modules carry full dossiers; _template/ is the scaffold for new module docs.
• Pointer-stub convention (binding). A directory that is not the home of a dossier — a consolidated module, or a directory holding only an autogenerated api-reference.md + openapi/ — must carry a README.md stub naming its parent dossier and its src/ location. Current stubs: opsmemory → advisory-ai §15 · symbols + binary-index → binaryindex · scheduler + packsregistry → jobengine · signer + provenance → attestor · feedser + excititor → concelier · riskengine → findings (deployables retired 2026-08-27) · attestor + evidence-locker → evidence (deployables retired 2026-09-05; both keep their format, predicate and algorithm detail behind a retirement banner, and attestor/consolidation-design.md stays at its path because a conformance test parses it there) · issuer-directory → authority · policy-engine → policy · airgap-controller → airgap · registry-token → registry. findings-ledger is no longer the Findings dossier — findings is, as of 2026-08-27; findings-ledger keeps the ledger event-spine detail and a currency banner.
• Autogenerated api-reference.md / openapi/ files describe the wire shape only. They are not dossiers and they do not carry the auth/tenancy contract — read the parent dossier before trusting a parameter list.

How to use this index

• Browse by area: the Module Categories tables group every documented module by function (core platform, ingestion, scanning, evidence, policy, release, operations, integrations, infrastructure).
• Look up a module: the Module Catalog lists each module alphabetically with its source path, type, database, endpoints, and dependencies. Consolidated and deleted modules are kept here as pointers to their current home.
• Source is the ground truth. Per-module counts (migrations, endpoints, scopes) are illustrative and can lag src/; verify against the code before relying on a specific number.

Module Categories

Core Platform

Data Ingestion

Scanning & Analysis

Artifacts & Evidence

Policy & Risk

Release & Orchestration

Operations & Observability

Integration & Clients

Infrastructure & Libraries

Testing & Benchmarks

Cross-Cutting Concepts

These concepts span multiple modules rather than owning a standalone service. Most are documented inside their owning module; the dedicated Reachability concept doc is the exception.

Module Catalog

AdvisoryAI

• Source: src/AdvisoryAI/
• Docs: docs/modules/advisory-ai/
• Type: Service
• Database: PostgreSQL (2 SQL migrations: chat audit, knowledge search)
• Endpoints: 7 (attestation, chat, evidence pack, knowledge search, LLM adapter, run, companion explain)

AI-powered advisory summarization and knowledge search service using LLM inference to explain vulnerability advisories, VEX evidence, and remediation guidance. Uses retrieval-augmented generation (RAG) over advisories, VEX, and platform documentation with configurable LLM backends (Claude, OpenAI, Ollama, Gemini). Includes chat audit logging, doctor-search controls, and guardrails for determinism and offline operation.

Dependencies: Concelier, VEX Lens / Excititor, Policy Engine, SBOM Service, LLM providers.

AirGap

• Source: src/OfflineKit/__Libraries/StellaOps.AirGap.{Bundle,Importer,Sync} and src/__Libraries/StellaOps.AirGap.Policy — the src/AirGap/ root retired at OK-14 (2026-09-14)
• Docs: docs/modules/airgap/
• Type: Libraries. No longer a service: the airgap-controller and airgap-time hosts retired at SPRINT_20260722_025 OK-5 (2026-09-11) and are frozen at src/__Obsoleted/AirGap/
• Database: none of its own. Sealed posture is ENVIRONMENT-scoped and lives in Platform’s platform.environment_state custodian (owner ruling A2); consumers replicate it rather than calling back
• Endpoints: none. Carrier custody and posture reads are served by offlinekit-web under /api/offlinekit/v1/**

Air-gapped deployment controller, importer, and cryptographic time anchor enabling StellaOps operation in fully disconnected environments. Handles bundle import/export, trust verification, and sealed-mode enforcement. Time service provides cryptographic time anchors using Roughtime or RFC3161.

Dependencies: Authority, Concelier / Excititor, Signer / Attestor.

Aoc

• Source: src/Aoc/
• Docs: docs/modules/aoc/
• Type: CLI / Library
• Database: None
• Endpoints: None

CLI tool and Roslyn analyzers enforcing the Aggregation-Only Contract (AOC) across the platform. Validates that ingestion services preserve raw upstream data without modification, maintain full provenance chains, and never merge conflicting observations.

Dependencies: None (standalone validation tool).

Api

• Source: src/Api/
• Docs: docs/modules/api/
• Type: Library
• Database: None
• Endpoints: None

Shared API contracts, governance rules, and OpenAPI generation libraries used across all StellaOps services. Includes StellaOps.Api (core contracts), StellaOps.Api.Governance (validators), and StellaOps.Api.OpenApi (specification generation).

Dependencies: None (consumed as a library).

Attestor

• Source: src/Attestor/
• Docs: docs/modules/attestor/
• Type: Service
• Database: PostgreSQL (ProofChainDbContext, 10 SQL migrations)
• Endpoints: 6 (verdict, predicate registry, core attestor, watchlist, and more)

Transparency-logged attestation service that submits DSSE envelopes to Rekor v2, retrieves inclusion proofs, and exposes verification APIs. Accepts DSSE only from the Signer over mTLS and enforces chain-of-trust to Stella Ops roots. Includes predicate type registry, identity watchlist, and trust verdict storage.

Two supporting containers are infrastructure, not src/ modules. stellaops-tsa is the local RFC 3161 Timestamp Authority built in-repo from an OpenSSL base (devops/docker/tsa/, ADR-036) — it answers timestamp queries for EvidenceLocker/Attestor sealing; stellaops-rekor is the Rekor v2 transparency log. The .NET timestamping clients live in src/Attestor/__Libraries/StellaOps.Attestor.Timestamping and src/EvidenceLocker/__Libraries/StellaOps.EvidenceLocker.Timestamping.

Dependencies: Signer, Rekor v2, TSA (RFC 3161), Authority.

Authority

• Source: src/Authority/
• Docs: docs/modules/authority/
• Type: Service
• Database: PostgreSQL (7 SQL migrations)
• Endpoints: 4+ (authorize, token, JWKS, discovery)

On-premises OIDC/OAuth2 identity service issuing short-lived, sender-constrained operational tokens (OpToks) with DPoP and mTLS binding. Supports RBAC scopes, multi-tenant claims with header-based tenant selection, deterministic validation, console admin endpoints, and LDAP/Standard client provisioning plugins.

Dependencies: Valkey (DPoP nonce store, token caching).

Bench (archived – absorbed into Tools)

• Source: src/Tools/StellaOps.Bench/
• Docs: docs/modules/tools/
• Type: Tool
• Database: None
• Endpoints: None

Performance benchmark harnesses for critical platform subsystems including Link-Not-Merge, VEX, Notify, Policy Engine, and Scanner analyzers. Absorbed into src/Tools/.

Dependencies: None (standalone benchmarks).

Binary analysis

Shared analysis foundations remain under src/BinaryIndex/; binary and symbol workflow, metadata and persistence belong to Vulnerabilities. See the current architecture. The predecessor hosts are frozen by BIN-10. Standing-estate retirement and schema-drop authorization remain distinct from source readiness.

Cartographer (absorbed into Scanner)

• Source: src/Scanner/StellaOps.Scanner.Cartographer/ (moved from src/Cartographer/)
• Docs: Historical doc archived at docs-archive/modules/cartographer/README.md; active contract is docs/modules/scanner/
• Type: Service
• Database: None
• Endpoints: Defined in Scanner Program.cs

Infrastructure topology discovery and service mapping for container environments. Produces SBOM snapshots and topology graphs consumed by the Graph Indexer. Environment topology and promotion lanes are now owned by the Release Orchestrator. Consolidated into Scanner.

Dependencies: Graph, Scanner.

CLI

• Source: src/Cli/
• Docs: docs/modules/cli/
• Type: CLI
• Database: None
• Endpoints: None

Command-line interface for driving StellaOps workflows including scanning, policy operations, VEX/vulnerability data pulls, verification, offline kit administration, knowledge search, and migration management. Supports build-time SBOM generation via Buildx orchestration and authenticates via Authority DPoP tokens.

Dependencies: Scanner.WebService, Authority, AdvisoryAI, Policy Engine, Concelier / Excititor, Signer / Attestor, Platform.

Concelier

• Source: src/Concelier/
• Docs: docs/modules/concelier/
• Type: Service
• Database: PostgreSQL (24 SQL migrations)
• Endpoints: 9 (advisory source, air-gap, canonical advisory, federation, feed mirror, feed snapshot, interest score, mirror, SBOM)

Advisory ingestion and Link-Not-Merge (LNM) observation pipeline producing deterministic raw observations, correlation linksets, and evidence events. Acquires authoritative vulnerability advisories from vendor PSIRTs, distros, OSS ecosystems, and CERTs, persisting them as immutable observations under AOC.

Dependencies: Policy Engine, Excititor, Graph, AirGap, Feedser.

Cryptography

• Source: src/Cryptography/
• Docs: docs/modules/cryptography/
• Type: Library
• Database: None
• Endpoints: None

Pluggable cryptographic primitives supporting regional standards (eIDAS, FIPS, GOST, SM) with algorithm-agile signing operations. Plugins include HSM integration, ECDSA, and EdDSA signing profiles. All operations are deterministic and support offline operation.

Dependencies: None (consumed as a library by Signer, Attestor, and other services).

DevPortal (archived – absorbed into Tools)

• Source: src/Tools/StellaOps.DevPortal.Site/
• Docs: docs/modules/tools/
• Type: Static Site
• Database: None
• Endpoints: None

Developer portal static site providing API documentation, integration guides, SDK references, and getting-started tutorials. Absorbed into src/Tools/.

Dependencies: None (static site).

Doctor

• Source: src/Doctor/
• Docs: docs/modules/doctor/
• Type: Service
• Database: None (uses Valkey for caching)
• Endpoints: 3 (doctor, scheduler, timestamping)

Diagnostic framework for validating system health, configuration, integration connectivity, and OCI registry compatibility. Plugin-based architecture with binary analysis, notification validation, and observability probing. Integrates with AdvisoryAI knowledge search for diagnostic assistance.

Dependencies: All platform services (health check targets), external registries, AdvisoryAI.

E2E (test harness – no dossier)

• Source: src/E2E/
• Docs: none (harness code + devops/compose/docker-compose.e2e-*.yml are the contract)
• Type: Test harness
• Database: None
• Endpoints: None

End-to-end coverage harnesses: StellaOps.E2E.AnalyzerCoverage, StellaOps.E2E.NotifyChannelCoverage, StellaOps.E2E.SyntheticRepos, plus __Tests. Driven by dedicated compose files (docker-compose.e2e-analyzer-coverage.yml, docker-compose.e2e-notify-coverage.yml). Test tooling, not a shipped service; it has no container in the default stack.

Dependencies: the services under test (Scanner analyzers, Notify channels).

EvidenceLocker

• Source: src/EvidenceLocker/
• Docs: docs/modules/evidence-locker/
• Type: Service
• Database: PostgreSQL (EvidenceDbContext, 5 SQL migrations)
• Endpoints: 4 (evidence audit, evidence thread, export, verdict)

Tamper-proof, immutable evidence storage for vulnerability scan evidence, audit logs, and compliance artifacts with cryptographic sealing. Evidence is content-addressable. Once sealed, evidence cannot be modified. Supports threads, verdicts, bundle packaging, and portable bundles for offline compliance audits.

Dependencies: Attestor, Authority, object storage.

Excititor (absorbed into Concelier)

• Source: src/Concelier/ (moved from src/Excititor/)
• Docs: docs/modules/excititor/(historical reference; see docs/modules/concelier/)
• Type: Service
• Database: PostgreSQL (10 SQL migrations, separate ExcititorDbContext)
• Endpoints: 11 (attestation, evidence, ingest, linkset, mirror, mirror registration, observation, policy, Rekor attestation, resolve, risk feed)

VEX ingestion and consensus pipeline converting heterogeneous VEX statements (OpenVEX, CSAF VEX, CycloneDX VEX) into immutable observations with provenance-preserving linksets. Does not decide PASS/FAIL; supplies evidence with statuses, justifications, and provenance weights. Conflicting observations are preserved unchanged. Consolidated into Concelier; DbContext remains separate.

Dependencies: Policy Engine, Concelier, Attestor, Graph.

ExportCenter — RETIRED

• Source: folded into src/OfflineKit/ (SPRINT_20260722_025 OK-4 lifted the domain, OK-10 retired the hosts on 2026-09-12). The two composition roots and the legacy private migration chain are frozen at src/__Obsoleted/ExportCenter/
• Docs: docs/modules/export-center/— retirement stub + historical record
• Type: none. export-web and export-worker were stopped in the 2026-09-13 consolidation window; the export plane is served by offlinekit-web
• Database: the export_center schema lives in stellaops_offlinekit now. The predecessor database stellaops_exportcenter still exists and still holds its rows — dropping it and revoking role exportcenter is a separate destructive window that has not run
• Endpoints: unchanged in shape, moved in prefix — the plane mounts at /api/offlinekit/v1/**, because the bare /v1/exports paths reached export-web through the HELLO service name exportcenter, which died with it

Nothing was withdrawn. The application layer is src/OfflineKit/__Libraries/StellaOps.ExportCenter.Application and the worker runtime is …/StellaOps.ExportCenter.WorkerRuntime; both still declare StellaOps.ExportCenter.* namespaces on purpose, because the lift was byte-identical so that no consumer using had to change.

Dependencies: unchanged — Findings, Policy Engine, JobEngine, Authority, Evidence, object storage.

Extensions (absorbed into Integrations)

• Source: src/Integrations/__Extensions/ (moved from src/Extensions/)
• Docs: See Integrations architecture
• Type: IDE Extensions (non-.NET: TypeScript/Kotlin)
• Database: None
• Endpoints: None

IDE extensions for JetBrains IDEs and Visual Studio Code providing inline vulnerability information, policy status, and StellaOps workflow integration directly within the developer’s editor environment. Now lives under the Integrations module.

Dependencies: Platform API, JobEngine API, Authority.

Feedser (absorbed into Concelier)

• Source: src/Concelier/ (moved from src/Feedser/)
• Docs: docs/modules/feedser/(historical reference; see docs/modules/concelier/)
• Type: Library
• Database: None
• Endpoints: None

Evidence collection library for backport detection and binary fingerprinting supporting the four-tier backport proof system. Extracts patch signatures from unified diffs and binary fingerprints from compiled code. Consumed primarily by Concelier’s ProofService layer. All outputs are deterministic with canonical JSON serialization. Consolidated into Concelier.

Dependencies: None (consumed as a library by Concelier).

Findings

• Source: src/Findings/
• Docs: docs/modules/findings/architecture.md— the dossier; ledger event-spine detail in findings-ledger/architecture.md; the analytics-ingestion lane in vuln-correlation.md
• Type: One deployable family, two replica roles — findings-web (HTTP) + findings-worker (projections/scoring)
• Database: PostgreSQL — its own stellaops_findings, resolved only from STELLAOPS_POSTGRES_FINDINGS_CONNECTION and fail-closed without it. Four data schemas (findings, findings_security, riskengine, analytics) plus two structural ones (findings_ledger_app, findings_archive).
• Endpoints: the canonical /api/findings/v1/* surface (ledger, scoring, capabilities, alerts, vex-decisions, evidence-subgraph, security, risk aggregated-status)

Centralized findings aggregation service providing backport tracking, evidence graphs, finding summaries, reachability maps, runtime timelines, scoring, and webhook notifications. Aggregates vulnerability findings from Scanner, Policy, Concelier, and Excititor into a unified query surface. Includes a LedgerReplayHarness tool for deterministic replay testing.

The analytics.* schema is derived from the Scanner (SBOM), Attestor, and Concelier advisory streams; Platform keeps the /api/analytics/* read surface plus the rollup/materialized-view maintenance lane. Its former host findings-vulncorrelation was deleted at FND-10 (2026-08-27) along with its compose overlay — it carried no API surface and all three of its background services logged disabled at startup. The StellaOps.Findings.VulnCorrelation.Application/.Persistence libraries are kept; the ingestion work folds into findings-worker and stays unwired until the X18 re-home, because its correlation SQL still targets the dropped vuln.* schema.

Dependencies: Scanner, Policy Engine, Concelier / Excititor, Attestor.

Gateway (deleted)

• Source: (deleted) – Gateway WebService now lives under src/Router/StellaOps.Gateway.WebService/
• Docs: docs-archive/modules/gateway/ (historical reference); active contract is docs/modules/router/
• Type: (deleted)
• Database: None
• Endpoints: None

The standalone src/Gateway/ module was deleted. The canonical Gateway WebService (StellaOps.Gateway.WebService) now lives under src/Router/. The Router module owns HTTP ingress, binary protocol bridging, routing, and transport abstraction.

Dependencies: See Router.

Graph

• Source: src/Graph/
• Docs: docs/modules/graph/
• Type: Service
• Database: PostgreSQL (1 SQL migration in Graph Indexer Persistence)
• Endpoints: 3 (graph query, analytics, overlay)

SBOM dependency graph store with a rich node/edge model covering artifacts, SBOMs, components, advisories, VEX statements, and policy versions with reachability overlays. The Graph Indexer processes events from Cartographer/SBOM Service, Concelier/Excititor, and policy runs to maintain the graph.

Dependencies: Cartographer / SBOM Service, Concelier / Excititor, Policy Engine, Scanner.

Integrations

• Source: src/Integrations/
• Docs: docs/modules/integrations/
• Type: Service
• Database: PostgreSQL (IntegrationDbContext, EF Core managed)
• Endpoints: 2

Integration hub managing connections to external systems (SCM, CI, registries, secrets vaults) with health monitoring. Stores connection profiles, manages credential references, and monitors integration health. Plugins under __Plugins provide specific connector implementations.

Dependencies: Authority, external SCM/CI/Registry/Vault systems.

IssuerDirectory (absorbed into Authority)

• Source: src/Authority/ (moved from src/IssuerDirectory/)
• Docs: docs/modules/issuer-directory/(historical reference; see docs/modules/authority/)
• Type: Service
• Database: PostgreSQL (1 SQL migration, separate IssuerDirectoryDbContext)
• Endpoints: 3 (issuer, issuer key, issuer trust)

Centralized trusted VEX/CSAF publisher metadata registry enabling issuer identity resolution, key management, and trust weight assignment. Key lifecycle management validates Ed25519, X.509, and DSSE public keys with fingerprint deduplication. On startup, imports default CSAF publishers into the global tenant. Consolidated into Authority; DbContext remains separate for security isolation.

Dependencies: Authority.

Mirror — RETIRED

• Source: folded into src/OfflineKit/ at SPRINT_20260722_025 OK-10 (2026-09-12). src/Mirror/ is absent from the tree entirely — not frozen, because the whole of it moved
• Docs: docs/modules/mirror/— retirement stub + historical record
• Type: Library / Tool, unchanged in kind
• Database: None
• Endpoints: None

StellaOps.Mirror.Creator still assembles mirror bundles; it is composed by the OfflineKit family rather than standing alone. The mirror-profile planner that turns a kind = 5 export profile into a bundle plan is MirrorProfilePlanner, and the executor that would call it is OK-12 — so a mirror bundle is not yet producible end-to-end through the profile API.

Dependencies: Upstream vulnerability feeds (NVD, OSV, GHSA), Concelier.

Notifier (retired)

Merged into Notify. notifier-web merged into notify-web at NTF-5 and the notifier-worker deployable retired on 2026-09-04; the sources were frozen at src/__Obsoleted/Notifier/ on 2026-09-08 (SPRINT_20260722_015 NTF-10). Its documentation is now a pointer: docs/modules/notifier/. Read the Notify entry below.

Notify

• Source: src/Notify/
• Docs: docs/modules/notify/
• Type: Service / Library
• Database: PostgreSQL (2 SQL migrations)
• Endpoints: 2 (via WebService Program.cs)

Rules-driven, tenant-aware notification engine providing event consumption, operator-defined routing, channel-specific rendering, and reliable delivery with idempotency, throttling, and digests. The notify-web host serves the API and notify-worker runs delivery, both over the shared StellaOps.Notify.Delivery library. Secrets for channels are referenced, not stored raw.

Dependencies: Scanner / Scheduler / Excititor / Concelier / Attestor / Zastava (event sources), Slack/Teams/Email/Webhook, Authority.

OpsMemory (consolidated into AdvisoryAI)

• Source: src/AdvisoryAI/__Libraries/StellaOps.OpsMemory/ (domain library), src/AdvisoryAI/__Libraries/StellaOps.OpsMemory.Application/ (HTTP surface, served in-process by advisoryai-web). The standalone host was retired 2026-09-07 and is frozen at src/__Obsoleted/AdvisoryAI/StellaOps.OpsMemory.WebService/.
• Docs: docs/modules/advisory-ai/architecture.md section 15
• Archived docs: docs-archive/modules/opsmemory/
• Type: Service
• Database: PostgreSQL (via shared infrastructure, schema managed programmatically)
• Endpoints: 1 (OpsMemoryEndpoints)

Decision ledger capturing the lifecycle of security decisions with similarity-based suggestion retrieval for organizational learning. Uses similarity vectors to suggest relevant precedents for new situations. Deterministic with fixed similarity formulas, no randomness in ranking, and multi-tenant isolation. Consolidated from standalone src/OpsMemory/ module into src/AdvisoryAI/.

Dependencies: AdvisoryAI, Authority, Findings Ledger.

JobEngine (formerly Orchestrator)

• Source: src/JobEngine/
• Docs: docs/modules/jobengine/
• Type: Service
• Database: PostgreSQL (via shared infrastructure)
• Endpoints: 25 (approvals, audit, circuit breakers, DAG, dead letter, export jobs, first signal, health, jobs, KPIs, ledger, OpenAPI, pack registry, pack runs, quotas, governance, release control v2, release dashboard, releases, runs, scale, SLOs, sources, streams, workers)

Source and job orchestration service managing job lifecycle, rate-limit governance, DAG execution, circuit breakers, and worker coordination. Applies quotas and rate limits per tenant/jobType, manages leasing to workers, handles completion tracking with retry policies, and supports replay. SDK bridges exist for Go and Python workers. Renamed from Orchestrator. Now includes Scheduler, TaskRunner, and PacksRegistry.

Dependencies: Concelier / Excititor / ExportCenter / Policy (job producers), Valkey or NATS, Authority.

PacksRegistry (absorbed into JobEngine)

• Source: src/JobEngine/ (moved from src/PacksRegistry/)
• Docs: docs-archive/modules/packs-registry/ (historical reference; see docs/modules/jobengine/)
• Type: Service
• Database: PostgreSQL (PacksRegistryDbContext, EF Core managed, stub)
• Endpoints: Defined in JobEngine Program.cs

Centralized registry for distributable task packs, policy packs, and analyzer bundles with versioned management and integrity verification. All packs are content-addressed. Consolidated into JobEngine.

Dependencies: JobEngine, object storage, Authority.

Platform

• Source: src/Platform/
• Docs: docs/modules/platform/
• Type: Service
• Database: PostgreSQL (57 SQL migrations, stellaops shared database)
• Endpoints: Platform-owned analytics, context, environment settings, evidence thread, federation telemetry, integration/read models, setup, release control/read models, topology, and trust-signing surfaces. Score, function-map, policy-interop, and security routes retain their public URLs but are owned by Signals, Scanner, Policy Engine, and Findings.Security respectively.

Central platform service providing analytics, context management, environment settings, evidence threading, federation telemetry, integration health, release control, and topology read models. Migrates only its own database (PlatformMigrationModule, Startup band); the former central migration framework (MigrationModuleRegistry, MigrationModulePluginDiscovery, IMigrationModulePlugin) was deleted 2026-09-14 (SPRINT_20260722_021 PLT-4, DC-26) — MigrationModuleConsolidation survives only for the guided-setup wizard.

Dependencies: Authority, PostgreSQL (own database).

Plugin

• Source: src/Plugin/
• Docs: docs/modules/plugin/
• Type: Library / Framework
• Database: PostgreSQL (Plugin Registry, 1 SQL migration)
• Endpoints: None

Plugin SDK, registry, sandbox, and host framework enabling extensibility across the platform. Includes Abstractions (contracts), Sdk (development SDK), Host (lifecycle management), Registry (PostgreSQL persistence), Sandbox (isolated execution), Cli (management tool), Testing (test harness), and Samples.

Dependencies: None (framework consumed by other modules).

Policy

• Source: src/Policy/
• Docs: docs/modules/policy/
• Type: Service (Engine + Gateway)
• Database: PostgreSQL (5 SQL migrations plus demo seed)
• Endpoints: 59 (49 Engine + 10 Gateway)

Deterministic policy evaluation engine and gateway service compiling stella-dsl policy packs into verdicts by joining SBOM inventory, advisories, and VEX evidence. The Engine provides extensive coverage across advisory AI knobs, attestation reports, batch evaluation, budgets, conflicts, CVSS receipts, determinization, effective policy, merge previews, risk profiles/simulations, sealed mode, verification policy, and violation tracking. The Gateway handles admission decisions, deltas, exception approvals, gates, governance, and registry webhooks.

Dependencies: Concelier, Excititor, SBOM Service, Scanner, Authority, Scheduler.

Provenance (absorbed into Attestor)

• Source: src/Attestor/ (moved from src/Provenance/)
• Docs: docs/modules/provenance/(historical reference; see docs/modules/attestor/)
• Type: Library / Tool
• Database: None
• Endpoints: None

Provenance attestation library and CLI tool for generating and verifying supply-chain provenance records. Creates in-toto attestation statements linking build artifacts to source materials, build systems, and parameters. A separate provenance cache library exists at src/__Libraries/StellaOps.Provcache.Postgres/. Consolidated into Attestor.

Dependencies: Attestor.

ReachGraph

• Source: src/Graph/__Libraries/StellaOps.ReachGraph.Application (HTTP surface) and src/__Libraries/StellaOps.ReachGraph* (model, persistence, cache, contracts). src/ReachGraph/ was deleted at 023 GRA-10 (2026-09-08).
• Docs: docs/modules/reach-graph/
• Type: Module of the Graph service (not a deployable of its own)
• Database: stellaops_graph, schema reachgraph, converged by StellaOps.Graph.Persistence’s consolidated baseline
• Endpoints: served by graph-api; carried controllers under StellaOps.ReachGraph.Application/Controllers/

Unified reachability subgraph store providing fast, deterministic, audit-ready answers about why a dependency is reachable. Consolidates reachability data from Scanner (call graphs), Signals (runtime observations), and Attestor (PoE JSON) into content-addressed artifacts with edge-level explainability.

Dependencies: Scanner, Signals, Attestor.

Registry (Registry Token Service)

• Source: src/Registry/ (StellaOps.Registry.TokenService)
• Docs: docs/modules/registry/; autogenerated wire reference in registry-token/
• Type: Service
• Database: PostgreSQL registry_token schema (plan rules + audit) when a connection string is configured; otherwise a static in-config plan catalogue
• Endpoints: GET /token (Docker registry token exchange) + the /api/admin/plans plan-rule admin group

Docker registry bearer token service issuing short-lived tokens for private or mirrored registries with license/plan enforcement. Validates caller identity using Authority-issued tokens, authorizes requested registry scopes against a plan catalogue, and mints Docker-registry-compatible JWTs.

The registry itself is not Stella Ops source. The stellaops-registry container is the third-party zot OCI registry (ghcr.io/project-zot/zot-linux-amd64:v2.1.3, devops/compose/docker-compose.stella-infra.yml:126-128). This module (stellaops-registry-token) only mints the bearer tokens that registry accepts.

Dependencies: Authority.

ReleaseOrchestrator

• Source: src/ReleaseOrchestrator/
• Docs: docs/modules/release-orchestrator/
• Type: Service (Active Development)
• Database: PostgreSQL (planned, via Platform migrations)
• Endpoints: 1

Central release control plane for non-Kubernetes container estates governing promotion across environments (Dev, Stage, Prod), enforcing security and policy gates, and producing verifiable evidence. Contains API, agents, apps, and libraries sub-directories with 140K+ lines of production code. Owns environment topology and promotion lanes.

Dependencies: Platform, Policy Engine, Scanner, Authority.

Remediation

• Source: src/Remediation/
• Docs: docs/modules/remediation/
• Type: Service
• Database: PostgreSQL (1 SQL migration)
• Endpoints: 3

Developer-facing signed-PR remediation marketplace enabling discovery, application, and verification of community-contributed fix templates for known CVEs. Templates include unified diff content, version range applicability, and trust scores. Tracks PR submission lifecycle with attestation evidence.

Dependencies: Scanner, Signer / Attestor, Authority.

Replay

• Source: src/Replay/
• Docs: docs/modules/replay/
• Type: Service
• Database: PostgreSQL (via shared infrastructure)
• Endpoints: 2 (point-in-time query, verdict replay)

Deterministic replay engine ensuring vulnerability assessments can be reproduced byte-for-byte given the same inputs. Manages replay tokens (cryptographically bound to input digests), manifests, feed snapshots, and verification workflows. Stores content-addressed references, not actual data.

Dependencies: Policy Engine, Scanner, Concelier / Excititor.

RiskEngine — deployables retired, capability kept

• Source: src/Findings/StellaOps.RiskEngine.Core + __Libraries/StellaOps.RiskEngine.Infrastructure (libraries only — the WebService, Worker and Application projects were deleted 2026-08-27)
• Docs: riskengine/README.md(pointer) → findings/architecture.md; pre-consolidation dossier in docs-archive/modules/risk-engine/
• Type: Not a service. No compose key, no image, no HTTP surface.
• Database: the riskengine schema (risk_score_results), inside the Findings family’s stellaops_findings
• Endpoints: none — /risk-scores/* and /exploit-maturity/* were retired by owner ruling Q-2 (2026-08-25)

Deterministic, explainable risk scoring by aggregating signals from EPSS, CVSS, KEV, VEX, and fix-exposure data, with audit trails and explainability payloads. It does not make PASS/FAIL decisions; it provides scores to the Policy Engine. The scoring providers and the exploit-maturity taxonomy live in StellaOps.RiskEngine.Core and are still compiled: src/Policy/__Libraries/StellaOps.Policy.Predicates references Core directly. A read API for scores will be designed on /api/findings/v1/* when a real consumer exists.

Dependencies: Concelier, Excititor, Signals, Policy Engine.

Router

• Source: src/Router/
• Docs: docs/modules/router/
• Type: Service / Framework
• Database: None
• Endpoints: 4

Internal service transport using binary protocol (TCP/TLS/UDP) for microservice-to-gateway communication with pluggable transports. Includes a unified plugin, shared libraries, and example microservices. The StellaOps.Gateway.WebService under Router serves as both the HTTP ingress gateway and binary protocol bridge (the standalone src/Gateway/ was deleted).

Dependencies: Authority, all microservices, Valkey.

RuntimeInstrumentation

• Source: src/RuntimeInstrumentation/
• Docs: docs/modules/runtime-instrumentation/
• Type: Library
• Database: None
• Endpoints: None

Tetragon-based runtime instrumentation library for eBPF-based process and syscall monitoring. Provides integration with Cilium Tetragon enabling observation of actual process execution, file access, and network activity at the kernel level for runtime evidence collection.

Dependencies: Tetragon (eBPF runtime), Zastava / Signals (evidence consumers).

SbomService

• Source: src/SbomService/
• Docs: docs/modules/sbom-service/
• Type: Service
• Database: PostgreSQL (1 SQL migration in Lineage persistence)
• Endpoints: 5

Canonical SBOM projection, lookup, and timeline API serving deterministic, tenant-scoped SBOM data. Does not perform scanning; consumes Scanner outputs or supplied SPDX/CycloneDX blobs. SBOMs are append-only with mutations via new versions only. Owns the SBOM lineage ledger for versioned uploads, diffs, and retention pruning.

Dependencies: Scanner, Graph, AdvisoryAI, Policy Engine.

Scanner

• Source: src/Scanner/
• Docs: docs/modules/scanner/
• Type: Service
• Database: PostgreSQL (36 SQL migrations, multiple DbContexts including TriageDbContext)
• Endpoints: 77 (EPSS, observability, reachability evidence, replay, score replay, unknowns, scan, and 71 more)

Deterministic SBOM generation and vulnerability scanning engine for container images and filesystems with three-way diffs, per-layer caching, and attestation hand-off. Emits Inventory and Usage views. Does not produce PASS/FAIL verdicts. Second-highest migration count covering scans, findings, call graphs, EPSS, smart diffs, unknowns, reachability, binary evidence, secret detection, runtime observations, and score history.

Dependencies: Signer, Attestor, Authority, object storage / RustFS, SBOM Service, Concelier / Excititor.

Scheduler (absorbed into JobEngine)

• Source: src/JobEngine/ (moved from src/Scheduler/)
• Docs: docs/modules/scheduler/(historical reference; see docs/modules/jobengine/)
• Type: Service
• Database: PostgreSQL (11 SQL migrations, separate SchedulerDbContext)
• Endpoints: 8 (event webhook, failure signature, graph job, policy run, policy simulation, run, schedule, resolver job)

Re-evaluation scheduler keeping scan results current by pinpointing affected images when new advisories or VEX claims arrive. Default mode is analysis-only (no image pull). Includes event webhooks, failure signature tracking, graph jobs, policy runs/simulations, and vulnerability resolver jobs. Consolidated into JobEngine; DbContext remains separate.

Dependencies: Scanner.WebService, Policy Engine, Concelier / Excititor, Notify, JobEngine.

Sdk (archived – absorbed into Tools)

• Source: src/Tools/StellaOps.Sdk.Generator/, src/Tools/StellaOps.Sdk.Release/
• Docs: docs/modules/tools/
• Type: Library / Code Generator
• Database: None
• Endpoints: None

Client SDK generator and release SDK for producing typed API clients across multiple languages from OpenAPI specifications. Absorbed into src/Tools/.

Dependencies: Gateway / OpenAPI specs.

Signals

• Source: src/Signals/
• Docs: docs/modules/signals/
• Type: Service
• Database: PostgreSQL (6 SQL migrations)
• Endpoints: 1 (SCM webhook)

Unified evidence-weighted scoring system aggregating reachability, runtime observations, backport detection, exploit intelligence, source trust, and mitigations into a single 0-100 score. Maintains determinism, provides score decomposition with explanations, and supports SCM webhook integration for change-triggered re-scoring.

Dependencies: Scanner, Concelier / Excititor, RuntimeInstrumentation, Policy Engine.

Signer (absorbed into Attestor)

• Source: src/Attestor/ (moved from src/Signer/)
• Docs: docs/modules/signer/(historical reference; see docs/modules/attestor/)
• Type: Service
• Database: PostgreSQL (KeyManagementDbContext, 2 SQL migrations, separate DbContext)
• Endpoints: 3 (ceremony, key rotation, signer)

The only service permitted to produce Stella Ops-verified DSSE signatures over SBOMs and reports, enforcing entitlement (PoE), sender-constrained auth, and supply-chain integrity. Does not push to Rekor (Attestor does). Stateless for the hot path with keys in KMS/HSM or ephemeral (keyless mode). Supports multi-algorithm signing (ECDSA, EdDSA, eIDAS, FIPS, GOST, SM). Consolidated into Attestor; DbContext remains separate for security isolation.

Dependencies: Authority, Cryptography library, KMS/HSM.

SmRemote

• Source: src/SmRemote/
• Docs: docs/modules/sm-remote/
• Type: Service
• Database: None
• Endpoints: Defined in Program.cs

Remote service for Chinese SM2/SM3/SM4 cryptographic operations enabling sovereign crypto compliance. Allows deployments requiring SM compliance to offload operations to a dedicated service rather than requiring SM crypto libraries on every host.

Dependencies: Cryptography Plugin.Sm.

Symbols

The hub owns global symbol source/catalog management, admitted manifests, CAS metadata and resolution. See binary analysis and symbol ownership and the Vulnerabilities API. The old Symbols.Server source and its wire documentation are frozen.

TaskRunner (absorbed into JobEngine)

• Source: src/JobEngine/ (moved from src/TaskRunner/)
• Docs: docs-archive/modules/taskrunner/ (historical reference; see docs/modules/jobengine/)
• Type: Service
• Database: PostgreSQL (via infrastructure layer, stub DbContext)
• Endpoints: Defined in JobEngine Program.cs

Deterministic task pack execution engine with approvals, sealed-mode enforcement, evidence capture, and DSSE attestation for every completed run. Three-phase execution: Plan (build execution graph), optional Simulation (dry-run with gates), and Execution (verify plan hash, execute steps, stream logs). Operates offline/air-gapped. Consolidated into JobEngine.

Dependencies: JobEngine, Authority, Attestor, object storage.

Telemetry

• Source: src/Telemetry/
• Docs: docs/modules/telemetry/
• Type: Library
• Database: None
• Endpoints: None

Observability library providing OpenTelemetry-based metrics, traces, and logs with Roslyn analyzers ensuring telemetry best practices. Supports multiple pipeline profiles (default, forensic, airgap) with allow-listed exporters for sovereign readiness. Forensic archives produce signed bundles of raw OTLP records.

Dependencies: Prometheus, Tempo/Jaeger, Loki.

Tester (QA-only service – opt-in overlay)

• Source: src/Tester/ (StellaOps.Tester.WebService)
• Docs: docs/modules/tester/— dossier: tester/architecture.md; binding invariants: src/Tester/AGENTS.md
• Type: Service (opt-in QA overlay; not production-safe)
• Database: None (stateless; seed artefacts from a read-only mount)
• Endpoints: /api/v1/tester/* — fixture import and per-scenario action endpoints (e.g. audit inject-batch, Authority proxy-login, Concelier advisory import) plus POST /api/v1/tester/replay-and-compare, the determinism oracle

Dedicated QA harness service owning the fixture-injection endpoints that would otherwise leak into production modules. It must never reach a production stack: it lives in a standalone overlay (devops/compose/docker-compose.tester.yml, labelled com.stellaops.production-safe: "false") that is deliberately excluded from docker-compose.stella-ops.yml and every include: list; it only starts when an operator explicitly passes the overlay. Networks are declared external, so it refuses to come up without the base stack. It also authenticates nobody — every route is AllowAnonymous, bearer tokens are relayed unvalidated to the downstream service, tenant comes from a caller-supplied header, and proxy-login is an unauthenticated credential relay with source-IP injection. That is the harness contract, and it is why exposure is disqualifying.

Two caveats the dossier records and does not fix: only the findings scope of replay-and-compare is backed by a run-scoped upstream read (evidence-packs returns a false identical); and the isolation goal is not yet complete — Platform/Notify/Scanner still ship their embedded fixture endpoints, with Platform’s flag default-ON in the main compose.

Dependencies: Platform, Notify, Scanner, Findings, EvidenceLocker, Concelier, ReleaseOrchestrator, Timeline, Authority (the modules it drives over public REST).

Timeline

• Source: src/Timeline/
• Docs: docs/modules/timeline/
• Type: Service
• Database: PostgreSQL (1 SQL migration in Timeline.Core)
• Endpoints: 3 (export, replay, timeline)

Timeline query service providing export, replay, and timeline browsing endpoints for vulnerability history and event streams. Uses shared libraries from StellaOps.Eventing for event envelope schemas and StellaOps.Timeline.Core for core logic including critical path view.

Dependencies: All services (event sources). TimelineIndexer is now consolidated into the Timeline module (src/Timeline/).

Tools

• Source: src/Tools/
• Docs: docs/modules/tools/
• Type: CLI Tools
• Database: None
• Endpoints: None

Developer utility tools including FixtureUpdater, GoldenPairs generator, LanguageAnalyzerSmoke, NotifySmokeCheck, PolicyDslValidator, PolicySchemaExporter, PolicySimulationSmoke, RustFsMigrator, WorkflowGenerator, and a Python CERT-Bund offline snapshot tool.

Dependencies: Various (tool-specific).

Unknowns

• Source: src/Unknowns/
• Docs: docs/modules/unknowns/
• Type: Service
• Database: PostgreSQL (UnknownsDbContext, 4 SQL migrations)
• Endpoints: 2 (grey queue, unknowns)

Structured registry for tracking unresolved components, symbols, and incomplete mappings that Scanner and other analyzers cannot definitively identify. Includes a Grey Queue for lifecycle management (queueing, triage, resolution). Does not guess identities; records what cannot be determined.

Dependencies: Scanner, Signals.

Verifier (archived – absorbed into Tools)

• Source: src/Tools/StellaOps.Verifier/
• Docs: docs/modules/tools/
• Type: CLI Tool
• Database: None
• Endpoints: None

Standalone CLI tool for verifying the integrity and authenticity of signed evidence bundles produced by the platform. Absorbed into src/Tools/.

Dependencies: None (standalone verification).

VexHub — RETIRED

• Source: deleted 2026-08-05 (SPRINT_20260722_003 VULN-B1)
• Docs: docs/modules/vex-hub/— retirement stub + historical record
• Type: none (service stopped in the SPRINT_20260722_008 G1 window, 2026-08-04)
• Database: none — the vexhub schema was dropped in that window
• Endpoints: none — the B7 route swap removed every route reaching it

Superseded by the vulnerability hub, which models VEX as facts rather than statements/ observations and serves GET /api/vulnerabilities/v1/vex/{vulnerabilityId}/{productKey}. This is a narrower successor: no observation model, no per-statement signature records, no Rekor linkage.

VexLens — RETIRED

• Source: deleted 2026-08-05 (SPRINT_20260722_003 VULN-B1)
• Docs: docs/modules/vex-lens/— retirement stub + historical record
• Type: none (service stopped in the SPRINT_20260722_008 G1 window under owner ruling P8)
• Database: the vexlens schema was NOT in G1’s drop list and may still exist in stellaops_platform; dropping it is an unclaimed ops action
• Endpoints: none — the B7 route swap removed /api/v1/vexlens

SPRINT_20260722_022 EVL-1 decided a fold, and only half of it happened: consensus is covered by the hub’s consensus schema, but noise gating has no successor anywhere in the estate — G1 retired the surface instead of migrating it. The source is recoverable from git history.

Vulnerabilities (the live vulnerability plane)

• Source: src/Vulnerabilities/
• Docs: docs/modules/vulnerabilities/architecture.md
• Type: Service (vulnerabilities-web + vulnerabilities-worker)
• Database: stellaops_vuln — its OWN database (ADR-039), schemas ingest/facts/consensus/dist/runtime + the shared eventing reliability schema
• Endpoints: /api/vulnerabilities/v1/* — readiness, lookup, corpus export, EPSS, issuer submission, event catch-up

The consolidation of Concelier (incl. Feedser + Excititor) + VexHub into one tenant-free vulnerability knowledge hub. Tenant-scoped decisions do NOT live here — they live in the control plane (policy.vuln_gate_current, Findings ledger).

Currency: LIVE since the SPRINT_20260722_008 G1 cutover (2026-08-04). The old plane’s services are stopped, its vuln/vex/vexhub/concelier schemas are dropped, and its 70 gateway routes are gone. The VexHub and VexLens entries below are retirement stubs; the Concelier and Excititor entries describe a retired service whose source tree survives only because production projects still compile against parts of it.

Dependencies: Authority (auth + issuer directory), Router/Gateway. Consumers reach it via the API, events, or the corpus artifact — the only source-referenceable projects are the closed Contracts and Consensus SDKs.

VulnExplorer

• Source: (no standalone project) — merged into src/Findings/__Libraries/StellaOps.Findings.Ledger.Application/ (Endpoints/VulnExplorerEndpoints.cs, Contracts/VulnExplorer/, Services/VulnExplorerAdapters.cs) and mapped by the consolidated src/Findings/StellaOps.Findings.WebService; the standalone container was decommissioned, and the findings-ledger-web host that first absorbed this family was itself withdrawn to src/__Obsoleted/ at FND-20 (2026-08-28)
• Docs: live surface → findings-ledger/architecture.md § VulnExplorer (merged); historical dossier → docs-archive/modules/vuln-explorer/
• Type: Endpoint family inside the consolidated Findings WebService
• Database: findings schema (VEX decisions in findings.vex_decisions)
• Endpoints: /v1/vulns*, /v1/vex-decisions*, /v1/evidence-subgraph/{vulnId}, /v1/fix-verifications*, /v1/audit-bundles under vuln:view / vuln:operate / vuln:audit

Vulnerability exploration API providing rich querying, filtering, and analysis of vulnerability findings across the platform. Aggregates data from Scanner, Concelier, Excititor, Policy, and Signals to present a unified vulnerability view with concept-based navigation and evidence links.

Dependencies: Scanner, Concelier, Excititor, Policy Engine, Signals, Findings Ledger.

Web

• Source: src/Web/
• Docs: docs/modules/ui/
• Type: UI (Angular SPA)
• Database: None
• Endpoints: None

Angular single-page application providing the operator console with vulnerability dashboard, release management, policy studio, evidence browser, SBOM exploration, notification management, and administrative controls. Includes search client APIs for knowledge search integration, smart diff visualization, AI UX patterns, and competitive triage workflows.

Dependencies: Gateway (API proxy), all backend APIs.

Workflow (source retained – service dormant)

• Source: src/Workflow/
• Docs: docs/modules/workflow/ (architecture.md, analyzer.md, slot-lattice.md, api-reference.md, openapi/)
• Type: Service (dormant since 2026-07-06 — not deployed)
• Database: PostgreSQL workflow schema (retained; ConnectionStrings:WorkflowPostgres)
• Endpoints: /api/workflow/* only if the dormant WebService is explicitly hosted — no compose service, no Router route

General-purpose workflow engine: definition deployment, instance lifecycle, signal-driven task transitions, dead-letter handling, and authorization-gated task progression. The source is retained but the service is dormant — the Workflow WebService slot was removed from the compose stack on 2026-07-06 as an unreachable dead footprint (0 instances ever ran; docker-compose.stella-services.yml:2211-2212), Router exposes no /api/workflow route, and ReleaseOrchestrator/Scheduler callers were removed. The live /api/v1/workflows route belongs to ReleaseOrchestrator, not this engine. Its workflow:view / workflow:operate / workflow:admin policies are local strings, not canonical Authority scopes; reactivation needs an explicit product decision (scopes, grants, callers, compose wiring, gateway route).

Dependencies: none live today. StellaOps.Workflow libraries were referenced by StellaOps.Platform.Database (renamed StellaOps.Platform.Persistence 2026-08-18, which no longer references them as of 2026-09-14) and the OpenAPI conformance tests; re-verify with rg -n "StellaOps.Workflow" src --glob '*.csproj'.

Zastava

• Source: src/Zastava/
• Docs: docs/modules/zastava/
• Type: Service (three processes: Agent, Observer, Webhook)
• Database: None (stateless agents)
• Endpoints: Webhook endpoints, agent APIs defined in Program.cs

Runtime posture concepts are being re-scoped into RuntimeInstrumentation host agents for non-Kubernetes container estates. The former Zastava Kubernetes admission-webhook direction is retired and must not be used for new Stella Ops deployment work.

Dependencies: Scanner.WebService, Policy Engine, Signals, Attestor, Authority.

Documentation Standards

Each module folder should contain:

Use the _template/ scaffold (README.md, architecture.md, AGENTS.md) as the starting point for new module docs.