Key Features — Capability Cards

These capability cards summarize what makes the Stella Ops Suite distinctive, organized so evaluators, architects, and operators can scan it quickly. Each card states what a capability does and why it matters; planned items are labeled accordingly.

Core thesis: Stella Ops isn’t a scanner or a deployment tool — it’s a release control plane that produces attestable decisions that can be replayed. Security is a gate, not a blocker. Evidence survives auditors, regulators, and supply-chain propagation.

Looking for the complete feature catalog? See full-features-list.md for the comprehensive list, or FEATURE_MATRIX.mdfor tier-by-tier availability.

At a Glance

What Competitors Do	What Stella Ops Suite Does
CI/CD runs pipelines	Central release authority across environments
Deployment tools promote	Promotion with integrated security gates
Scanners output findings	Security gates output decisions with proof chains
VEX as suppression file	VEX as logical claim system (K4 lattice)
Release identity via tags	Release identity via immutable digests
Per-seat/per-project pricing	Pay for environments + new digests/day
Online-first	Offline-first with full parity

Release Orchestration (Operational)

Shipped in src/ReleaseOrchestrator/, src/Integrations/, and src/Plugin/ (verified against src/ 2026-07-28); the release-orchestrator, agent-core, and integrations-web services run in the default compose stack. Residual runtime gaps are tracked in modules/release-orchestrator/promotion-runtime-gap-closure-plan.md; anything below that is not yet shipped is labeled inline.

0. Release Control Plane

The new core capability. Stella Ops Suite becomes the central release authority between CI and runtime targets.

Capability	What It Does
Environment management	Define Dev/Stage/Prod with freeze windows and approval policies
Release bundles	Compose releases from component OCI digests with semantic versioning
Promotion workflows	DAG-based workflow engine with approvals, gates, and hooks
Security gates	Scan on build, evaluate on release, re-evaluate on CVE updates
Deployment execution	Deploy to Docker/Compose/ECS/Nomad via agents or agentless
Evidence packets	Every release decision is cryptographically signed and stored

Why it matters: Non-Kubernetes container teams finally get a central release authority with audit-grade evidence—without replacing their existing CI/SCM/registry stack.

1. Digest-First Release Identity

Tags are mutable; digests are truth. A release is an immutable set of OCI digests, resolved at release creation time.

Release: myapp-v2.3.1
Components:
  api:      sha256:abc123...
  worker:   sha256:def456...
  frontend: sha256:789ghi...

What this enables:

Tamper detection at pull time (digest mismatch = deployment failure)
Audit trail of exactly what was deployed
Rollback to known-good digests, not “latest” tags
“What is deployed where” tracking with integrity

Where it lives: StellaOps.ReleaseOrchestrator.Release; component version registry and registry-driven version sync in StellaOps.ReleaseOrchestrator.WebApi

2. Promotion Workflows with Security Gates

Security integrated into release flow, not bolted on. Promotion requests trigger gate evaluation before deployment.

Gate Type	What It Checks
Security gate	Reachable critical/high vulnerabilities
Approval gate	Required approval count, separation of duties
Freeze window gate	Environment freeze windows
Policy gate	Custom OPA/Rego policies
Previous environment gate	Release deployed to prior environment

Decision records include:

All gate results with pass/fail reasons
Evidence refs (scan verdicts, approval records)
Policy hash + inputs hash for replay
“Why blocked?” explainability

Where it lives: StellaOps.ReleaseOrchestrator.Promotion, StellaOps.ReleaseOrchestrator.PolicyGate, StellaOps.ReleaseOrchestrator.DecisionArtifact. Promotion runs via /api/v1/release-orchestrator/releases/{id}/promote; a dedicated /api/v1/promotions controller is still planned.

3. Deployment Execution

Deploy to non-Kubernetes targets as first-class citizens. Agent-based or agentless deployment to Docker hosts, Compose, ECS, Nomad.

Target Type	Deployment Method
Docker host	Agent pulls and starts containers
Compose host	Agent writes `compose.stella.lock.yml` and runs `docker-compose up`
ECS service	Agent updates task definition and service
Nomad job	Agent updates job spec and submits
SSH remote	Agentless via SSH (Linux)
WinRM remote	Agentless via WinRM (Windows)

Generated artifacts:

compose.stella.lock.yml: Pinned digests, resolved environment refs
stella.version.json: Version sticker on target for drift detection
release.evidence.json: Decision record

Where it lives: StellaOps.ReleaseOrchestrator.Deployment (target executor, compose lock generation) and the StellaOps.Agent.* projects; Docker/Compose/SSH/WinRM targets are live-verified (VM deployment gate, 2026-05-09)

4. Progressive Delivery

A/B releases and canary deployments. Gradual rollout with automatic rollback on health failure.

Strategy	Description
Immediate	0% → 100% instantly
Canary	10% → 25% → 50% → 100% with health checks
Blue-green	Deploy to B, switch traffic, retire A
Rolling	10% at a time with health checks

Traffic routing adapters: Nginx, HAProxy, Traefik, and AWS ALB adapters are implemented; live data-plane proof against a production load balancer is not yet claimed.

Where it lives: StellaOps.ReleaseOrchestrator.Progressive and StellaOps.ReleaseOrchestrator.ProgressiveDelivery; all-at-once, rolling, canary, and A/B strategies are test- and live-VM-proven

5. Plugin System (Three-Surface Model)

Extensible without core code changes. Plugins contribute through three surfaces.

Surface	What It Does
Manifest	Declares what the plugin provides (integrations, steps, agents)
Connector runtime	gRPC interface for runtime operations
Step provider	Execution characteristics for workflow steps

Plugin types:

Integration connectors (shipped as signed plugins): SCM (Gitea, GitHub App, GitLab), CI (Jenkins), Registry (Harbor, Nexus, Docker Registry), secrets (HashiCorp Vault, Consul)
Step providers: Custom execution plugins for workflow steps
Agent types: New deployment targets
Gate providers: Custom gate evaluations (e.g. the reachability promotion gate)

Where it lives: src/Plugin/ — StellaOps.Plugin.Registry, StellaOps.Plugin.Host, StellaOps.Plugin.Sandbox, StellaOps.Plugin.Sdk

6. Doctor Self Service Diagnostics (Operational — one-click remediation still landing)

Operators can self-diagnose integrations and services. Doctor runs as a deployed service with plugin-based diagnostic packs (agent, binary analysis, compliance, environment, evidence locker, notify, operations, release, scanner, storage, timestamping) and per-check fix guidance. The one-click remediation runner (POST /api/v1/doctor/remediate + CLI verb + UI “Run Fix”) is still landing; the check catalog in the capability spec is broader than what ships today.

Where it lives: src/Doctor/ (StellaOps.Doctor.WebService, __Plugins/StellaOps.Doctor.Plugin.*) Spec: doctor/doctor-capabilities.md

Security Capabilities (Operational)

7. Decision Capsules — Audit-Grade Evidence Bundles

Every scan and release decision is sealed. A Decision Capsule is a content-addressed bundle containing everything needed to reproduce and verify the decision.

Component	What’s Included
Inputs	Exact SBOM, frozen feed snapshots (with Merkle roots), policy version
Evidence	Reachability proofs (static + runtime), VEX statements, binary fingerprints
Outputs	Verdicts, risk scores, remediation paths
Signatures	DSSE envelopes over all of the above

Why it matters: Auditors can replay any decision bit-for-bit. This is what “audit-grade assurance” actually means.

Modules: EvidenceLocker, Attestor, Replay

See modules/evidence-locker/export-format.mdand modules/evidence-locker/guides/evidence-pack-schema.mdfor audit pack structure and verification.

8. Lattice Policy + OpenVEX (K4 Logic)

VEX as a logical claim system, not a suppression file. The policy engine uses Belnap K4 four-valued logic.

State	Meaning
Unknown (bottom)	No information
True	Positive assertion
False	Negative assertion
Conflict (top)	Contradictory assertions

Why it matters: When vendor says “not_affected” but runtime shows the function was called, you have a conflict—not a false positive.

Modules: VexLens, TrustLatticeEngine, Policy

9. Signed Reachability Proofs

Proof of exploitability, not just a badge. Every reachability graph is sealed with DSSE.

Layer	What It Proves
Static	Call graph shows path from entrypoint → vulnerable function
Binary	Compiled binary contains the symbol
Runtime	Process actually executed the code path

Why it matters: “Here’s the exact call path” vs “potentially reachable.” Signed, not claimed.

Modules: ReachGraph, PathWitnessBuilder

10. Deterministic Replay

The audit-grade guarantee. Every scan produces a DSSE + SRM bundle that can be replayed.

# Six months later, prove what you knew: replay the run twice and compare
stella replay verify --manifest ./run-manifest.json

verify replays the manifest twice and emits JSON with both verdict digests, an isDeterministic flag, and the list of differences when they disagree. It exits 0 when the two replays are identical and 2 when they are not, so CI can gate on the exit code. Use stella replay diff --a <verdict-a.json> --b <verdict-b.json> to compare two verdicts you already hold, and stella replay snapshot to re-evaluate against a frozen Knowledge Snapshot.

What’s frozen: Feed snapshots, analyzer versions, policy rules, random seeds.

TLPT use: DORA TLPT scope files can bind Asset Registry v1 state, ReachGraph subgraph references, and later Replay baselines by hash so the white-team evidence path is reproducible without running offensive tooling.

TLPT product principle: Stella is white-team / evidence-side tooling only; red-team and offensive execution are out of scope.

Modules: Replay, Scanner, Policy

11. Sovereign Crypto Profiles

Regional compliance without code changes. FIPS, eIDAS, GOST, SM, and PQC profiles are configuration toggles.

Profile	Use Case
FIPS-140-3	US federal
eIDAS	EU qualified signatures
GOST-2012	Russian Federation
SM2	People’s Republic of China
PQC	Post-quantum readiness

Modules: Cryptography, CryptoProfile

12. Offline Operations (Air-Gap Parity)

Full functionality without network. Offline Update Kits bundle everything needed.

Component	Offline Method
Feed updates	Sealed bundle with Merkle roots
Crypto verification	Embedded revocation lists
Transparency logging	Local transparency mirror

Modules: AirGap.Controller, TrustStore

13. Reproducible Build Evidence Bundles (Planned)

Every released binary should carry verifiable build evidence. Stella defines a Repro Bundle profile that combines SLSA v1 provenance, in-toto link metadata, DSSE signatures, and optional Rekor anchoring with offline parity.

Fail-closed controls:

Reject non-canonical paths, JSON ordering, and archive metadata outside policy.
Require pinned toolchain digests (@sha256:...) and deterministic build settings.
Require DSSE-signed provenance and in-toto link evidence before promotion.
Apply evidence-based release gates (score thresholds, Rekor freshness, build-link digest binding, and k-of-n DSSE signer requirements) per lane policy.
Enforce Source Track governance signals in provenance policy (review quorum, no-self-merge, protected branch, status checks, and source policy hash binding).

Modules: Attestor, ReleaseOrchestrator, EvidenceLocker, AirGap, Policy

Docs: modules/attestor/repro-bundle-profile.md, modules/release-orchestrator/workflow/evidence-based-release-gates.md

14. Controlled Conversational Advisor

Ask Stella with guardrails. Operators can query evidence and receive cited answers while tool actions remain policy-gated and audited.

Key controls:

Chat Gateway quotas and token budgets per user/org.
Scrubber for secrets/PII and allowlisted tool calls only.
Immutable audit log for prompts, redactions, tool calls, and model fingerprints.

Modules: AdvisoryAI, Policy, Authority, CLI, Web, Gateway

15. AI Code Guard for AI-Assisted Code

Catch security, IP, and license risks in AI-assisted changes. Fast guard checks run on code diffs and produce evidence for deterministic policy gates.

Key controls:

Secrets and unsafe API detection with new vs pre-existing classification.
Snippet similarity against allowlist and denylist corpora.
License hygiene on dependency diffs and long snippet attribution.
Overrides with audit (issue link, expiry, role-based approval).

Modules: Scanner, Policy, CLI, Integrations, Attestor, Web

Docs: modules/scanner/operations/ai-code-guard.md, modules/policy/guides/ai-code-guard-policy.md

16. SBOM and Attestation Hot Lookup Plane

Keep hot lookups sub-second without turning OLTP into an analytics warehouse. Stella keeps full SBOM/attestation payloads in CAS/object storage and projects query-critical fields into a partitioned PostgreSQL hot-lookup plane.

Key controls:

Narrow relational keys for exact matching (payload_digest, canonical SBOM hash, insertion time).
JSONB search slices for component/VEX triage queries with bounded index scope.
Time partitioning for deterministic retention and cheap partition-drop cleanup.
Separation of concerns: replay/audit blobs stay in CAS; analytics stays in analytics.* and can be exported to external columnar systems when needed.

Modules: Scanner, Attestor, Policy, Analytics

Where it lives: the monthly-partitioned scanner.artifact_boms projection (Scanner storage baseline migration) and the SBOM evidence endpoints in StellaOps.Scanner.WebService

Docs: modules/scanner/sbom-attestation-hot-lookup-profile.md

Competitive Moats Summary

Nine capabilities no competitor offers together:

#	Capability	Category
1	Non-Kubernetes Specialization	Release orchestration
2	Digest-First Release Identity	Release orchestration
3	Security Gates in Promotion Flow	Release orchestration
4	Signed Reachability Proofs	Security
5	Deterministic Replay	Security
6	Sovereign + Offline Operation	Operations
7	Reproducible Build Evidence Bundles	Security
8	Controlled Conversational Advisor	Security
9	AI Code Guard for AI-Assisted Code	Security

Pricing moat: No per-seat, per-project, or per-deployment tax. Limits are environments + new digests/day.

Quick Reference

Key Documents

Product Vision: docs/product/VISION.md
Architecture Overview: docs/ARCHITECTURE_OVERVIEW.md
Release Orchestrator Architecture: docs/modules/release-orchestrator/architecture.md
Competitive Landscape: docs/product/competitive-landscape.md
Quickstart: docs/quickstart.md
Feature Matrix: docs/FEATURE_MATRIX.md
SBOM/Attestation Hot Lookup Profile: docs/modules/scanner/sbom-attestation-hot-lookup-profile.md
Controlled Conversational Interface Advisory: docs-archive/product/advisories/13-Jan-2026 - Controlled Conversational Interface.md