git.stella-ops.org/docs-archived/product/advisories/17-Jan-2026 - The AI Economics Moat.md

Product Advisory: AI Economics Moat

ID: ADVISORY-20260116-AI-ECON-MOAT Status: ACTIVE Owner intent: Product-wide directive Scope: All modules, docs, sprints, and roadmap decisions

0) Thesis (why this advisory exists)

In AI economics, code is cheap, software is expensive.

Competitors (and future competitors) can produce large volumes of code quickly. Stella Ops must remain hard to catch by focusing on the parts that are still expensive:

• trust
• operability
• determinism
• evidence integrity
• low-touch onboarding
• low support burden at scale

This advisory defines the product-level objectives and non-negotiable standards that make Stella Ops defensible against "code producers".

1) Product positioning (the class we must win)

Stella Ops Suite must be "best in class" for:

Evidence-grade release orchestration for containerized applications outside Kubernetes.

Stella is NOT attempting to be:

• a generic CD platform (Octopus, GitLab, Jenkins replacements)
• a generic vulnerability scanner (Trivy, Grype replacements)
• a "platform of everything" with infinite integrations

The moat is the end-to-end chain: digest identity -> evidence -> verdict -> gate -> promotion -> audit export -> deterministic replay

The product wins when customers can run verified releases with minimal human labor and produce auditor-ready evidence.

2) Target customer and adoption constraint

Constraint: founder operates solo until ~100 paying customers.

Therefore, the product must be self-serve by default:

• install must be predictable
• failures must be diagnosable without maintainer time
• docs must replace support
• "Doctor" must replace debugging sessions

Support must be an exception, not a workflow.

3) The five non-negotiable product invariants

Every meaningful product change MUST preserve and strengthen these invariants:

I1. Evidence-grade by design

• Every verified decision has an evidence trail.
• Evidence is exportable, replayable, and verifiable.

I2. Deterministic replay

• Same inputs -> same outputs.
• A verdict can be reproduced and verified later, not just explained.

I3. Digest-first identity

• Releases are immutable digests, not mutable tags.
• "What is deployed where" is anchored to digests.

I4. Offline-first posture

• Air-gapped and low-egress environments must remain first-class.
• No hidden network dependencies in core flows.

I5. Low-touch operability

• Misconfigurations fail fast at startup with clear messages.
• Runtime failures have deterministic recovery playbooks.
• Doctor provides actionable diagnostics bundles and remediation steps.

If a proposed feature weakens any invariant, it must be rejected or redesigned.

4) Moats we build (how Stella stays hard to catch)

M1. Evidence chain continuity (no "glue work" required)

• Scan results, reachability proofs, policy evaluation, approvals, promotions, and exports are one continuous chain.
• Do not require customers to stitch multiple tools together to get audit-grade releases.

M2. Explainability with proof, not narrative

• "Why blocked?" must produce a deterministic trace + referenced evidence artifacts.
• The answer must be replayable, not a one-time explanation.

M3. Operability moat (Doctor + safe defaults)

• Diagnostics must identify root cause, not just symptoms.
• Provide deterministic checklists and fixes.
• Every integration must ship with health checks and failure-mode docs.

M4. Controlled surface area (reduce permutations)

• Ship a small number of Tier-1 golden integrations and targets.
• Keep the plugin system as an escape valve, but do not expand the maintained matrix beyond what solo operations can support.

M5. Standards-grade outputs with stable schemas

• SBOM, VEX, attestations, exports, and decision records must be stable, versioned, and backwards compatible where promised.
• Stability is a moat: auditors and platform teams adopt what they can depend on.

5) Explicit non-goals (what to reject quickly)

Reject or de-prioritize proposals that primarily:

• add a generic CD surface without evidence and determinism improvements
• expand integrations broadly without a "Tier-1" support model and diagnostics coverage
• compete on raw scanner breadth rather than evidence-grade gating outcomes
• add UI polish that does not reduce operator labor or support load
• add "AI features" that create nondeterminism or require external calls in core paths

If a feature does not strengthen at least one moat (M1-M5), it is likely not worth shipping now.

6) Agent review rubric (use this to evaluate any proposal, advisory, or sprint)

When reviewing any new idea, feature request, PRD, or sprint, score it against:

A) Moat impact (required)

• Which moat does it strengthen (M1-M5)?
• What measurable operator/auditor outcome improves?

B) Support burden risk (critical)

• Does this increase the probability of support tickets?
• Does Doctor cover the new failure modes?
• Are there clear runbooks and error messages?

C) Determinism and evidence risk (critical)

• Does this introduce nondeterminism?
• Are outputs stable, canonical, and replayable?
• Does it weaken evidence chain integrity?

D) Permutation risk (critical)

• Does this increase the matrix of supported combinations?
• Can it be constrained to a "golden path" configuration?

E) Time-to-value impact (important)

• Does this reduce time to first verified release?
• Does it reduce time to answer "why blocked"?

If a proposal scores poorly on B/C/D, it must be redesigned or rejected.

7) Definition of Done (feature-level) - do not ship without the boring parts

Any shippable feature must include, at minimum:

DOD-1: Operator story

• Clear user story for operators and auditors, not just developers.

DOD-2: Failure modes and recovery

• Documented expected failures, error codes/messages, and remediation steps.
• Doctor checks added or extended to cover the common failure paths.

DOD-3: Determinism and evidence

• Deterministic outputs where applicable.
• Evidence artifacts linked to decisions.
• Replay or verify path exists if the feature affects verdicts or gates.

DOD-4: Tests

• Unit tests for logic (happy + edge cases).
• Integration tests for contracts (DB, queues, storage where used).
• Determinism tests when outputs are serialized, hashed, or signed.

DOD-5: Documentation

• Docs updated where the feature changes behavior or contracts.
• Include copy/paste examples for the golden path usage.

DOD-6: Observability

• Structured logs and metrics for success/failure paths.
• Explicit "reason codes" for gate decisions and failures.

If the feature cannot afford these, it cannot afford to exist in a solo-scaled product.

8) Product-level metrics (what we optimize)

These metrics are the scoreboard. Prioritize work that improves them.

P0 metrics (most important):

• Time-to-first-verified-release (fresh install -> verified promotion)
• Mean time to answer "why blocked?" (with proof)
• Support minutes per customer per month (must trend toward near-zero)
• Determinism regressions per release (must be near-zero)

P1 metrics:

• Noise reduction ratio (reachable actionable findings vs raw findings)
• Audit export acceptance rate (auditors can consume without manual reconstruction)
• Upgrade success rate (low-friction updates, predictable migrations)

9) Immediate product focus areas implied by this advisory

When unsure what to build next, prefer investments in:

• Doctor: diagnostics coverage, fix suggestions, bundles, and environment validation
• Golden path onboarding: install -> connect -> scan -> gate -> promote -> export
• Determinism gates in CI and runtime checks for canonical outputs
• Evidence export bundles that map to common audit needs
• "Why blocked" trace quality, completeness, and replay verification

Avoid "breadth expansion" unless it includes full operability coverage.

10) How to apply this advisory in planning

When processing this advisory:

• Ensure docs reflect the invariants and moats at the product overview level.
• Ensure sprints and tasks reference which moat they strengthen (M1-M5).
• If a sprint increases complexity without decreasing operator labor or improving evidence integrity, treat it as suspect.

Archive this advisory only if it is superseded by a newer product-wide directive.