# Product Vision — Stella Ops Suite
*Evidence-grade release orchestration for containerized applications outside Kubernetes.*

> Stella Ops Suite is not “a scanner” and not “another CD tool.”
> It is a **release control plane** that produces **verifiable evidence** for every promotion decision, and uses **reachability-aware security** as a first-class gate.

---

## 1) Why this product exists

Most non-Kubernetes container estates ship using a patchwork:

- CI produces images, registries store them, scanners emit long CVE lists.
- Deployment happens via Compose/scripts/Ansible plus tribal knowledge approvals.
- Audit evidence is reconstructed from screenshots and spreadsheets.

This fails in predictable ways:

- Security noise overwhelms engineers (too many non-actionable CVEs).
- Release governance is informal (approvals are not cryptographically bound to artifacts).
- “Why was this approved / blocked?” is not replayable or defensible.
- Audits become manual, slow, and error-prone.

**Stella’s premise:** in the AI economics era, code is cheap; trustworthy operations are expensive.
Stella’s job is to make *evidence-grade releases* routine, self-service, and hard to replicate.

---

## 2) Target users and where we win

### Who Stella is for
- Teams deploying containers **without Kubernetes** (Docker hosts, Docker Compose, ECS, Nomad, scripted targets).
- Small and mid organizations that need **practical, certifiable security** without a heavy platform team.
- Regulated or audit-exposed environments, including **offline/air-gapped** operations.

### Where we intentionally win
- **Evidence-grade governance**: every promotion is backed by signed, exportable evidence.
- **Reachability-aware security**: prioritize what is actually exploitable, not what is merely present.
- **Deterministic replay**: reproduce past decisions bit-for-bit to answer auditors and incident reviews.
- **Non-Kubernetes first-class**: targets and workflows that are not an afterthought.

### Non-goals
- Replacing CI systems (Jenkins/GitHub Actions/GitLab CI remain your build engine).
- Competing as a Kubernetes-first CD product (use Argo CD / Flux where Kubernetes is the estate).
- Inventing new SBOM, attestation, or VEX formats.

---

## 3) The North Star: “Every release is provable”

A **provable release** means:

1. Every new artifact digest has evidence (SBOM + reachability + verdict) generated once and reused.
2. Every promotion decision records inputs, policy, approvals, and reasons.
3. Evidence is exportable, verifiable offline, and reproducible by replay.

---

## 4) Golden path (Verified Release)

Stella supports both “Verified” and “CD-only” modes, but it is designed to excel at Verified releases.

### Verified release flow
```mermaid
flowchart LR
  A[CI Build] --> B[Push to OCI Registry by digest]
  B --> C[Deep Scan once per digest\nSBOM + reachability + findings]
  C --> D[Create Release\nDigest bundle + provenance refs]
  D --> E[Request Promotion\nDev -> Stage -> Prod]
  E --> F[Gate Evaluation\nPolicy + security + approvals]
  F --> G{Decision}
  G -->|Allow| H[Deploy to targets\nCompose/Docker/ECS/Nomad/scripts]
  G -->|Deny| I[Block with explainable reasons]
  H --> J[Evidence Packet\nSigned + stored + exportable]
```

### CD-only mode (supported, not optimized)
Stella can orchestrate deployments while bypassing evidence gates. This exists to avoid competing in a saturated “CD-only” market and to allow gradual adoption. However, the differentiator is **evidence-grade governance**.

---

## 5) Product pillars (what we build)

### Pillar A — Release orchestration (control plane)
- Environment management and promotion workflows (Dev -> Stage -> Prod).
- Approvals, freeze windows, and separation-of-duties policies.
- Rollbacks and redeploys by immutable digest identity.
- “What is deployed where” inventory over time.

### Pillar B — Security decisioning as a gate
- Scan on build, evaluate on release, re-evaluate on intel updates.
- Reachability-aware vulnerability prioritization (reduce noise; focus on exploitable paths).
- VEX-first decisioning and policy explainability (“why blocked?” traces).

### Pillar C — Evidence & audit
- Signed evidence packets per decision: inputs, verdicts, approvals, deployment artifacts, logs.
- Exportable audit packs for auditors, incident reviews, and regulated reporting.
- Integrity guarantees (content-addressed artifacts + signatures + optional transparency logging).

### Pillar D — Determinism and replay
- Deterministic scanning and policy evaluation with replay manifests.
- Reproduce prior decisions given the same manifest, feeds, and versioned engines.
- Deterministic identifiers and ordering; UTC timestamps; canonical hashing.

### Pillar E — Self-service operations (Doctor-first)
- Self-diagnostics (“Doctor”) to remove dependency on vendor support.
- Offline-first posture; explicit allowlists; strict validation; predictable failure modes.
- A product that can reach meaningful production adoption without a sales/support org.

---

## 6) Design principles and invariants (non-negotiable)

### Invariant 1 — Digest-first release identity
A release is a **bundle of OCI digests** (component -> digest mapping), never mutable tags.

- Tags may be accepted as inputs but must be resolved to digests at release creation time.
- Downstream operations (promotion, deployment, rollback) operate on digests.
- Digest mismatch at pull time is a hard failure (tamper signal).

### Invariant 2 — Evidence-first decisions
Every promotion/deployment emits an immutable evidence record.

Evidence must capture:
- Who: authenticated identity and authorization context
- What: release bundle, target environment(s), target selection
- Why: policy outcome, approval chain, decision reasons
- How: generated artifacts and execution traces
- When: deterministic timestamps and ordering

### Invariant 3 — Deterministic replay
Given the recorded manifest (inputs + versions), Stella must reproduce:
- scan outputs,
- policy outcomes,
- gate reasons,
- and decision records.

### Invariant 4 — Offline-first operation
Core decisions must not require external network access.
External feeds are mirrored; verification and replay must work offline.

### Invariant 5 — Pluggable edges, stable core
Integrations and target types are plugins. The orchestration and evidence core remains stable.

Plugins may provide:
- connector logic (SCM/CI/registry/secrets),
- workflow step types,
- target/agent types,
- Doctor checks.

### Invariant 6 — No “feature gating”
Capabilities are not tier-gated.
Commercial limits (when relevant) apply only to **scale units** such as:
- environments (governance boundaries),
- new digests deep-scanned per month (evidence generation),
- fair-use constraints on exceptional bandwidth/support consumption.

---

## 7) Security and evidence invariants (carryover from scanning heritage)

1. Artifact identity is content-addressed (SHA-256 digests).
2. SBOMs and key evidence artifacts are signed (in-toto DSSE envelopes).
3. Provenance is attached via attestations, not implied via tags or CI logs.
4. Explainability is required: findings must connect to packages/paths/symbols when available.
5. Exploitability over enumeration: VEX and reachability drive actionability.
6. Air-gap posture is first-class: mirrors, offline kits, and offline verification flows.

---

## 8) Competitive positioning (category definition)

### What we are not
- **Not a pure scanner**: scanners find issues; Stella governs releases with evidence.
- **Not a generic CD tool**: CD tools deploy; Stella is a release authority with proof.

### Where alternatives typically stop
- Scanners: produce findings, but do not produce release-level evidence chains.
- CD tools: provide deployments, but security is bolt-on and audit evidence is manual.
- Registries: store artifacts, but are not a governance and decision system.

### Stella’s moat
- Digest-first release identity + signed evidence chain + deterministic replay
- Reachability-aware decisioning bound to promotion workflows
- Offline-first and sovereign crypto posture
- Self-service operability (Doctor-first) designed for small teams

---

## 9) Roadmap framing (outcome-driven)

This vision is delivered in phases, but the category remains consistent:

1) **Evidence foundation**: deep scan, policy, determinism, evidence export, Doctor maturity  
2) **Release control plane**: environments, promotions, approvals, decision records  
3) **Deployment execution**: non-Kubernetes targets, rollback, artifacts, verification checks  
4) **Progressive delivery**: canary/A-B/blue-green where practical for non-K8s estates  
5) **Ecosystem depth**: integrations/connectors, plugin surface hardening, docs, ops kits  

---

## 10) Glossary (canonical terms)

- **Environment**: governance boundary (policy + config + approvals + targets)
- **Release**: immutable bundle of digests (component -> digest)
- **Promotion**: moving a release between environments
- **Gate**: policy check that blocks/allows promotion
- **Evidence packet**: signed bundle of decision inputs/outputs suitable for export and verification
- **Deterministic replay**: re-running a decision with the same manifest to reproduce outputs

---

## Change log

| Version | Date | Note |
|---|---:|---|
| v3.0 | 2026-01-17 | Reframed as evidence-grade release control plane; added Doctor-first and CD-only framing; removed pricing specifics. |
| v2.0 | 2026-01-09 | Pivot to release control plane; scanning becomes gate. |
| v1.4 | 29-Oct-2025 | Initial principles, golden path, policy examples, JSON skeletons |
| v1.3 | 12-Jul-2025 | Expanded ecosystem pillar, added metrics/integrations |
| v1.2 | 11-Jul-2025 | Restructured to link with WHY; merged principles |
| v1.1 | 11-Jul-2025 | Original OSS-only vision |
| v1.0 | 09-Jul-2025 | First public draft |