Stella Ops capabilities and product focus
Updated 2026-09-30 to the accepted product vision. This page explains intended outcomes and their acceptance boundaries. It is not a claim that all listed behavior is deployed or complete.
Governed releases for an existing toolchain
Stella’s promise is to connect an existing CI-produced artifact to a governed release on a self-hosted non-Kubernetes runtime, safe recovery and evidence that can be checked later, including offline.
| Capability | Customer outcome | Required boundary |
|---|---|---|
| Immutable release identity | Know which artifact, application version, configuration and scripts were requested for which environment and targets. | Tags, entered commit text and scan completion alone do not prove CI provenance or target state. Preserve identity across multi-component release changes. |
| Security and policy decisions | Understand relevant findings, VEX disposition, reachability coverage and the reason to allow or block. | Pin input/policy versions; expose missing, unknown, stale and unavailable evidence. A missing call path does not prove absence of exploitable behavior. |
| Scoped contribution and approval | Contributors request changes to owned services; authorized actors decide and operate them. | Enforce tenant, service, environment and revision boundaries. Approval, exception, signing and deployment grants are distinct. |
| Deployment observation and recovery | See actual target progress and recover failed or interrupted operations. | Distinguish dispatch from completion; name the observer and checked properties. Retry and rollback require actual owner outcomes. |
| Evidence custody and completion | Retrieve proof of the finalized decision and its authorization. | Decision persistence, signing and durable evidence completion are separate states. Bind the exact revision; preserve failure and retry evidence. |
| Independent verification and replay | Check exported evidence without depending on a live Console session. | State whether the check proves integrity, signer trust or decision recomputation. Include exact inputs and trust material; expose missing/invalid data. |
| Changed-risk response | Understand how new advisories, VEX or exception expiry affect deployed software. | Keep the historical decision intact and distinguish it from current risk. Remediation and exception grants need their own records. |
| Self-hosted operation | Install, upgrade, restore and maintain the system within customer-controlled infrastructure. | Measure effort and failure recovery on the supported profile. Offline operation needs usable refresh/export/verification procedures. |
Where the contracts live
- Architecture and current owners, service inventory and physical database ownership.
- Promotion policy boundary and promotion evidence boundary.
- User roles and permission boundaries.
- Dated capability verification. Re-run a row’s verification against current source/deployment before using it as a capability claim.
What must be proved next
The governed release and proof program prioritizes trustworthy decisions, real delivery/recovery, independent proof and repeatable operation. Its 14 acceptance scenarios include restricted roles, negative controls, changed risk and install/upgrade/restore. These are outstanding acceptance requirements.
The first profile is a Docker/Compose estate with two environments and a multi-component application under one operator. Existing capability in other profiles is not withdrawn by choosing this acceptance scope.
Product constraints
- Existing CI remains the build engine. Use supported standard SBOM, VEX and attestation formats and digest-bound artifacts.
- Self-hosted and offline-first operation, operator-controlled key custody and regional crypto plugins remain design constraints. Crypto algorithm/profile availability does not establish certification, regulatory compliance or universal format interoperability.
- Logical tenants share one operator trust boundary. Shared SaaS for unrelated adversarial tenants is outside the current architecture.
- Offline verification may remain CLI-first. A new browser verifier is not required to complete the product outcome.
Breadth we are deferring
New asset discovery, framework effectiveness scoring, broader federation, risk-budget/SLO engines, quota forecasting, extra dashboards and marketplaces follow core journey acceptance. Unsupported controls and fabricated history should be withdrawn while useful working data and operations remain available. Retired SBOM Lake analytics are not an outstanding backend commitment.
The older feature catalogue is a historical inventory, not a source of current availability or commercial entitlement. Use the offer guide for commercial authority and the roadmap for outcome priorities.