git.stella-ops.org/docs/key-features.md

# Key Features — Capability Cards

> **Core Thesis:** Stella Ops Suite 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`](full-features-list.md) for the comprehensive list, or [`FEATURE_MATRIX.md`](FEATURE_MATRIX.md) for 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 (Planned)

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

**Modules (planned):** `ReleaseManager`, `ComponentRegistry`, `VersionManager`

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

**Modules (planned):** `PromotionManager`, `ApprovalGateway`, `DecisionEngine`

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

**Modules (planned):** `DeployOrchestrator`, `Agent.*`, `ArtifactGenerator`

### 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 plugins:** Nginx, HAProxy, Traefik, AWS ALB

**Modules (planned):** `ABManager`, `TrafficRouter`, `CanaryController`

### 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:** SCM (GitHub, GitLab), CI (Actions, Jenkins), Registry (Harbor, ECR), Vault (HashiCorp, AWS Secrets)
- **Step providers:** Custom workflow steps
- **Agent types:** New deployment targets
- **Gate providers:** Custom gate evaluations

**Modules (planned):** `PluginRegistry`, `PluginLoader`, `PluginSandbox`, `PluginSDK`

### 6. Doctor Self Service Diagnostics (Planned)

**Operators can self-diagnose integrations and services.** Doctor auto-discovers installed packs,
runs deterministic checks, and prints exact CLI fixes for every failure. Output includes JSONL
evidence logs and optional DSSE summaries for audits.

**Modules (planned):** `Doctor`, `IntegrationHub`, `CLI`, `Web`
**Spec:** `docs/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 `docs/modules/evidence-locker/export-format.md` and `docs/modules/evidence-locker/guides/evidence-pack-schema.md` for 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.

```bash
# Six months later, prove what you knew
stella replay srm.yaml --assert-digest sha256:abc123...
# Output: PASS - identical result
```

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

**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. 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`

### 14. 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:** `docs/modules/scanner/operations/ai-code-guard.md`, `docs/modules/policy/guides/ai-code-guard-policy.md`

---

## Competitive Moats Summary

**Eight 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 | **Controlled Conversational Advisor** | Security |
| 8 | **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`](product/VISION.md)
- **Architecture Overview**: [`docs/ARCHITECTURE_OVERVIEW.md`](ARCHITECTURE_OVERVIEW.md)
- **Release Orchestrator Architecture**: [`docs/modules/release-orchestrator/architecture.md`](modules/release-orchestrator/architecture.md)
- **Competitive Landscape**: [`docs/product/competitive-landscape.md`](product/competitive-landscape.md)
- **Quickstart**: [`docs/quickstart.md`](quickstart.md)
- **Feature Matrix**: [`docs/FEATURE_MATRIX.md`](FEATURE_MATRIX.md)
- **Controlled Conversational Interface Advisory**: [`docs-archived/product/advisories/13-Jan-2026 - Controlled Conversational Interface.md`](../docs-archived/product/advisories/13-Jan-2026%20-%20Controlled%20Conversational%20Interface.md)