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 · scheduler + packsregistry → jobengine · signer + provenance → attestor · feedser + excititor → concelier · riskengine → findings · issuer-directory → authority · policy-engine → policy · airgap-controller → airgap · registry-token → registry · findings → findings-ledger.
• 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/AirGap/
• Docs: docs/modules/airgap/
• Type: Service
• Database: PostgreSQL (1 SQL migration)
• Endpoints: 1 (AirGapEndpoints)

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/ as of Sprint 212.

Dependencies: None (standalone benchmarks).

BinaryIndex

• Source: src/BinaryIndex/
• Docs: docs/modules/binary-index/
• Type: Service
• Database: PostgreSQL (BinaryIndexDbContext, 5 SQL migrations)
• Endpoints: Defined in WebService Program.cs

Vulnerable binaries database enabling detection of vulnerable code at the binary level, independent of package metadata, using fingerprint claims and delta signatures. Addresses unreliable package version strings (backports, custom builds, stripped metadata).

Dependencies: Scanner, Concelier.

Cartographer (absorbed into Scanner – Sprint 201)

• 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 per Sprint 201.

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/ as of Sprint 212.

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 – Sprint 203)

• 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 per Sprint 203; DbContext remains separate.

Dependencies: Policy Engine, Concelier, Attestor, Graph.

ExportCenter

• Source: src/ExportCenter/
• Docs: docs/modules/export-center/
• Type: Service
• Database: PostgreSQL (1 SQL migration)
• Endpoints: 15 (profile management, export runs, distribution, status, download)

Evidence and policy overlay packaging service producing reproducible, deterministic export bundles in multiple formats (JSON, SARIF, offline kit). Enforces AOC guardrails and produces deterministic manifests with optional signing and distribution to OCI registries or object storage.

Dependencies: Findings Ledger, Policy Engine, JobEngine, Authority, Attestor, object storage.

Extensions (absorbed into Integrations – Sprint 214)

• 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 – Sprint 203)

• 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 per Sprint 203.

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

Findings

• Source: src/Findings/
• Docs: docs/modules/findings-ledger/— module map in architecture.md; the analytics-ingestion worker in vuln-correlation.md
• Type: Service (3 HTTP hosts) + worker (1)
• Database: PostgreSQL — four owned schemas: findings (Ledger), findings_security (Security), riskengine (RiskEngine), analytics (VulnCorrelation)
• Endpoints: 8 (backport, evidence graph, finding summary, reachability map, runtime timeline, runtime traces, scoring, webhook)

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.

StellaOps.Findings.VulnCorrelation.WebService is the module’s worker host (no gateway route): it owns and auto-migrates the analytics.* schema and derives it from the Scanner (SBOM), Attestor, and Concelier advisory streams. It was relocated out of Platform by SPRINT_20260703_001 (PAC-5); Platform keeps the /api/analytics/* read surface plus the rollup/materialized-view maintenance lane. Deployed via the opt-in overlay devops/compose/docker-compose.findings-vulncorrelation.override.yml.

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

Gateway (deleted – Sprint 200)

• 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 in Sprint 200. 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 – Sprint 216)

• 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 per Sprint 216; DbContext remains separate for security isolation.

Dependencies: Authority.

Mirror

• Source: src/Mirror/
• Docs: docs/modules/mirror/
• Type: Library / Tool
• Database: None
• Endpoints: None

Vulnerability feed mirror and distribution utility for offline operation and reduced latency. Produces bundles for air-gapped distribution with cryptographic verification. Primary component is StellaOps.Mirror.Creator for assembling mirror bundles.

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

Notifier

• Source: src/Notifier/
• Docs: docs/modules/notifier/
• Type: Service
• Database: None (uses Notify’s persistence layer)
• Endpoints: 14 (escalation, fallback, incident, localization, observability, operator override, quiet hours, rule, security, simulation, storm breaker, template, throttle, notify API)

Notifications Studio host application composing the Notify toolkit libraries into a full-featured notification management service. Provides 73+ routes covering escalation policies, fallback routing, incident tracking, localization, security controls, simulation testing, storm breaking (anti-spam), and more.

Dependencies: Notify libraries, Authority, Slack/Teams/Email/Webhook channels.

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. Foundation library consumed by the Notifier host application. 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/ (library), src/AdvisoryAI/StellaOps.OpsMemory.WebService/ (service)
• 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/ per Sprint 213.

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 (Sprint 221). Now includes Scheduler, TaskRunner, and PacksRegistry (Sprint 208).

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

PacksRegistry (absorbed into JobEngine – Sprint 208)

• 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 per Sprint 208.

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. Owns the migration consolidation framework (MigrationModuleRegistry, MigrationModulePluginDiscovery, MigrationModuleConsolidation).

Dependencies: Authority, all modules (migration coordination), PostgreSQL.

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 – Sprint 204)

• 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 per Sprint 204.

Dependencies: Attestor.

ReachGraph

• Source: src/ReachGraph/
• Docs: docs/modules/reach-graph/
• Type: Service
• Database: PostgreSQL (1 SQL migration in shared library)
• Endpoints: Defined in Program.cs

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

• Source: src/Findings/StellaOps.RiskEngine.* (consolidated into Findings, Sprint 207)
• Docs: docs-archive/modules/risk-engine/
• Type: Service
• Database: PostgreSQL (via shared infrastructure)
• Endpoints: 1 (exploit maturity)

Risk scoring runtime computing deterministic, explainable risk scores by aggregating signals from EPSS, CVSS, KEV, VEX, and reachability data. Produces audit trails and explainability payloads for every scoring decision. Does not make PASS/FAIL decisions; provides scores to the Policy Engine. Supports offline operation via factor bundles.

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 in Sprint 200).

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 – Sprint 208)

• 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 per Sprint 208; 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/ as of Sprint 212.

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 – Sprint 204)

• 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 per Sprint 204; 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 (absorbed into BinaryIndex – Sprint 202)

• Source: src/BinaryIndex/StellaOps.Symbols.* (moved from src/Symbols/)
• Docs: docs/modules/binary-index/architecture.md(Symbols section)
• Type: Service
• Database: None (content-addressed storage)
• Endpoints: 1 (symbol source)

Symbol resolution and debug information management service for native binary analysis. Maps symbols to packages, manages debug information, and supports stripped binary analysis. Includes marketplace architecture for community-contributed symbol sources and offline symbol stores. Consolidated into BinaryIndex per Sprint 202.

Dependencies: Scanner, BinaryIndex.

TaskRunner (absorbed into JobEngine – Sprint 208)

• 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 per Sprint 208.

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/ as of Sprint 212.

Dependencies: None (standalone verification).

VexHub

• Source: src/VexHub/
• Docs: docs/modules/vex-hub/
• Type: Service
• Database: PostgreSQL (1 SQL migration)
• Endpoints: 1 (VexHubEndpointExtensions)

VEX document hub providing centralized management, distribution, and integration of VEX statements across the platform. Stores VEX statements from various sources and distributes data to Excititor for processing.

Dependencies: Excititor, IssuerDirectory, Authority.

VexLens

• Source: src/VexLens/
• Docs: docs/modules/vex-lens/
• Type: Service
• Database: PostgreSQL (1 SQL migration)
• Endpoints: 2 (export, VexLens)

VEX consensus viewer and analysis service providing issuer-aware VEX statement evaluation with export capabilities. Evaluates VEX statements from multiple issuers, computes consensus views considering trust weights and provenance, and integrates with IssuerDirectory for owner manifest resolution.

Dependencies: Excititor, IssuerDirectory, Policy Engine.

VulnExplorer

• Source: (no standalone project) — merged into src/Findings/StellaOps.Findings.Ledger.WebService/ (Endpoints/VulnExplorerEndpoints.cs, Contracts/VulnExplorer/, Services/VulnExplorerAdapters.cs); the standalone container was decommissioned in SPRINT_20260408_002 and its compose slot is commented out (docker-compose.stella-services.yml:1651)
• Docs: live surface → findings-ledger/architecture.md § VulnExplorer (merged); historical dossier → docs-archive/modules/vuln-explorer/
• Type: Endpoint family inside the Findings Ledger 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 are still referenced by StellaOps.Platform.Database and the OpenAPI conformance tests.

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.