Files

StellaOps Bot dfab8a29c3 docs re-org, audit fixes, build fixes

2026-01-05 09:35:33 +02:00

24 KiB

Raw Blame History

StellaOps Moat Track — Spec Outline v0.5

Core Thesis: Stella Ops isn't a scanner that outputs findings. It's a platform that outputs attestable decisions that can be replayed. That difference survives auditors, regulators, and supply-chain propagation.

The Category Difference

Traditional scanners output findings: "CVE-2024-1234 exists in package X."

Stella Ops outputs decisions: "CVE-2024-1234 is reachable via this call path, vendor VEX says not_affected but runtime disagrees (creating a conflict the policy must resolve), and here's the signed proof chain."

This isn't a feature gap—it's a category difference.

Why Competitors Can't Easily Catch Up

Origin	Representatives	What They Optimized For	Architectural Constraint
Package Scanners	Trivy, Syft/Grype	Fast CLI, broad coverage	No forensic reproducibility; VEX is boolean; no DSSE for reachability
Developer UX	Snyk	IDE integration, fix PRs	SaaS-only; no attestation infrastructure; offline impossible
Policy/Compliance	Prisma, Aqua	Runtime protection, CNAPP	No deterministic replay; no cryptographic provenance
SBOM Operations	Anchore	SBOM storage, lifecycle	No lattice VEX; no signed reachability; no regional crypto

Retrofitting our capabilities requires fundamental rearchitecture—not just features.

Four Capabilities No Competitor Offers Together

#	Capability	What It Is	Why It's Hard to Copy
1	Signed Reachability	Every reachability graph sealed with DSSE; optional edge-bundle attestations for runtime/init/contested paths. Hybrid static + runtime.	Requires three-layer instrumentation + cryptographic binding to call paths
2	Deterministic Replay	Scans run bit-for-bit identical from frozen feeds and analyzer manifests. Decision Capsules seal all evidence.	Requires content-addressed evidence model + feed snapshotting + deterministic ordering
3	Explainable Policy (K4 Lattice VEX)	Belnap K4 logic (Unknown/True/False/Conflict) merges SBOM, advisories, VEX, waivers into single verdict with proof links.	Requires rethinking VEX from suppression to logical claims
4	Sovereign + Offline Operation	FIPS/eIDAS/GOST/SM/PQC profiles as config toggles. Sealed knowledge snapshots for air-gap parity.	Requires pluggable crypto + offline trust roots + regional compliance

Scope of this doc: (1) Decision Capsules, (2) Deterministic Replayable Scans (SRM), (3) Policy Engine & Lattice UI, (4) Sovereign Readiness (CryptoProfile + RootPack), (5) Attestation Observability Graph (AOG), (6) Procurement‑Grade Trust Statement, (7) Third‑Party Proof Channel, (8) Zastava differential SBOM + AI scheduler.

Cross‑cutting principles: offline‑first, cryptographic determinism, evidence‑bound decisions, regional crypto compliance, minimal operational friction.

0) Shared Concepts (applies to all 8)

Artifact identity: digest-first (OCI image digest, file sha256).
Canonicalization: all structured payloads (SBOM, SRM, Trust Statement JSON, VEX) are normalized via Canonical JSON (RFC‑8785‑like) prior to hashing/signing.
Signatures: DSSE envelopes; dual‑signing supported (e.g., FIPS ECDSA + GOST R 34.10; or ECDSA + SM2).
Attestation chain: each decision (scan, VEX merge, policy evaluation) yields a signed, replayable record.
Profiles & Packs: CryptoProfile (algorithm + root policy) and RootPack (trust anchors + OCSP/CRL/TSA mirrors) are versioned and importable.
Policy Unit Tests: any policy/lattice bundle ships with fixtures expected to pass during CI.

1) Deterministic Replayable Scans — SRM

Objective

Make every scan a provable, re‑executable fact. Auditors can replay; results are bit‑for‑bit reproducible.

Deliverables

SRM v0.1 schema (YAML/JSON)
Deterministic executor + stella replay
Replay diffing and result hashing

SRM (Stella Replay Manifest) — schema (abridged)

apiVersion: srm.stellaops.dev/v0.1
scan:
  id: uuid
  timestamp: ISO8601
  engine: { name: "stella-scan", version: "1.7.3", build_sha: "<sha>" }
environment:
  os_image: <digest>
  kernel: { uname: "...", cgroups: "v2" }
  cpu_features: [avx2, sse4.2]
inputs:
  image: { name: "reg/app:1.9.2", digest: "<sha>", layers: ["<sha>", ...] }
  sbom: { type: "cyclonedx@1.5", digest: "<sha>" }
  vex_set: [{ type: "openvex", digest: "<sha>" }]
  lattice_policy: { id: "corp-policy@2025-08-15", digest: "<sha>" }
rules_and_feeds:
  rulesets: [{ name: "vuln-core", version: "2025.08.30", digest: "<sha>" }]
  feeds:
    - { name: "nvd", snapshot_date: "2025-08-30", archive_digest: "<sha>" }
execution:
  mode: deterministic
  random_seed: 314159
  ordering: lexical
  heuristics: { binary_scan: true, secrets: false }
evidence:
  files_hashed: 12873
  samples: [{ path: "/usr/lib/libssl.so.3", sha256: "<sha>" }]
outputs:
  report_digest: "<sha>"   # canonical JSON root hash
  artifacts:
    - { name: "findings.json", sha256: "<sha>" }
signatures:
  - { scheme: "DSSE", CryptoProfile: "FIPS-140-3", signer: "build-ca@corp" }
  - { scheme: "DSSE", CryptoProfile: "GOST-2012",  signer: "ru-ca@corp" }
rekor: { entries: ["<uuid>", ...] }   # optional (offline allowed)

CLI & API

stella scan --image reg/app@sha256:... --srm-out srm.yaml --findings findings.json
stella replay srm.yaml --out replay.json --assert-digest <sha>
POST /v1/srm/replay → returns ok, replay_report_digest, diff (if any).

Determinism Rules

Single thread or ordered parallel with stable scheduling; sorted inputs; fixed random seed; pinned rules/feeds/policies from SRM; identical canonicalization routines.

Acceptance Criteria

Replaying SRM on a different host returns identical report_digest.
If any feed archive differs by 1 bit, replay fails with a precise diff.
SRM size ≤ 25 MB for a typical microservice image (excludes large feed archives, which may be referenced by digest and bundled as a side‑car tar).

2) Policy Engine & Lattice UI

Objective

Turn VEX merging and severity logic into programmable, testable algebra with explainability.

Trust Algebra Foundation (Implemented 2025-12)

The lattice engine uses Belnap K4 four-valued logic to aggregate heterogeneous security claims:

K4 Values: Unknown (⊥), True (T), False (F), Conflict (⊤)
Security Atoms: Six orthogonal propositions per Subject:
- PRESENT: component instance exists in artifact
- APPLIES: vulnerability applies to component (version match)
- REACHABLE: vulnerable code reachable from entrypoint
- MITIGATED: controls prevent exploitation
- FIXED: remediation applied
- MISATTRIBUTED: false positive indicator
Claim Resolution: Multiple VEX sources (CycloneDX, OpenVEX, CSAF) normalized to atoms, aggregated with conflict detection, then disposition selected via priority rules.
Implementation: src/Policy/__Libraries/StellaOps.Policy/TrustLattice/ (110 tests passing)

Model

Domain: partial order over vulnerability states: unknown < under_investigation < affected || not_affected < fixed. Cross‑product with scope: {runtime_path, build_path, optional_path} and confidence: {low, med, high}.
Merge semantics: monotonic lattice joins; conflict resolution rules prioritized by signed source trust and policy precedence.

DSL (sketch)

policy "corp-runtime" version "2025.08.15" {
  sources {
    trust_order = ["vendor:redhat", "internal:appsec", "public:nvd"]
    require_signatures = true
  }

  rules {
    when vex.statement == "not_affected"
      and evidence.entrypoint_exposes == false
      then state := not_affected with confidence := high;

    when package.is_dev_dependency == true
      then scope := optional_path;

    when cvss >= 9.0 and reachable == true
      then priority := "block";
  }

  guards {
    forbid unsigned_sources;
    forbid downgrade_of_state_below previous_state;
  }
}

UI (“Trust Algebra Studio”)

Drag‑and‑drop rule blocks, precedence editor, simulation mode on sample SBOM/VEX; policy unit tests.
Export signed .lattice.json; importable into CI.

CLI & API

stella policy lint corp-runtime.lattice.json
stella policy test --fixtures fixtures/
POST /v1/policy/evaluate → normalized decision + proof trail.

Acceptance Criteria

Given same inputs, policy evaluation yields identical decision + proof trail hash.
UI can round‑trip DSL ⇄ JSON with no semantic drift.
Policy pack signature required to run in “enforced” mode.

3) Sovereign Readiness — CryptoProfile + RootPack

Objective

Drop‑in regional cryptography (Russia/China/EU/US) with offline operation.

CryptoProfile (attached to every signature/attestation)

{
  "id": "GOST-2012@v1",
  "algorithms": {"sign":"GOST R 34.10-2012","hash":"GOST R 34.11-2012","cipher":"GOST 34.12-2015"},
  "key_policy": {"curve":"id-tc26-gost-3410-2012-256","hsm_required": true},
  "time_stamping": {"tsa": "rootpack://ru/tsa1"},
  "roots": ["rootpack://ru/trustanchors/gost-ca1"]
}

RootPack

Tarball containing: trust anchors, intermediate CAs, OCSP/CRL snapshots, TSA profiles, policy constraints (e.g., no cross‑sign with foreign roots), and region metadata.
Installed via: stella rootpack import rootpack_ru_v1.tar.gz.

Dual‑Signing & Guardrails

Policy flags like allow_dual_signing FIPS+GOST, forbid_sm2_for_us_exports (example only).
Enforcement happens at signing time and verification time.

Acceptance Criteria

Offline verification using RootPack succeeds; online OCSP disabled per policy.
Mis‑profiled signatures are rejected with explicit reason codes.
Dual‑signed DSSE verifies under both profiles when allowed.

4) Attestation Observability Graph (AOG)

Objective

Make trust observable. Expose SLIs/SLOs for cryptographic posture & policy compliance.

Data Model

Nodes: {artifact, sbom, policy, vex, srm, signature, rootpack, runtime_instance}
Edges: derived_from, signed_by, evaluated_by, replayed_by, runs_as

Metrics (OpenTelemetry/Prometheus)

stella_trust_sli{service,env} = fraction of running pods whose image has a valid SRM‑backed attestation chain under the active policy.
stella_attestation_latency_seconds (P50/P95) from build to verified‑ready.
stella_policy_drift_events_total (increment when running policy != signed policy).
stella_exception_without_proof_total (must be 0).
stella_replay_success_ratio (per week).

SLO Example

Trust SLO ≥ 99.9% measured hourly; error budget resets monthly.

Interfaces

stella aog export --format otlp
GET /v1/aog/graph?artifactDigest=... → subgraph JSON (with signed edge proofs).
Grafana dashboards (packaged).

Acceptance Criteria

AOG can reconstruct the full trust lineage for any running pod in ≤ 2s (p95) on a 1k‑service cluster.
Metrics cardinality bounded (service/env/policy only).

5) Procurement‑Grade “Trust Statement”

Objective

One board‑ready artifact that unifies security posture across vendors; machine‑readable twin for ERP/GRC.

Outputs

PDF (human): signed, watermark, controlled fields for vendor name/version/date, summary graphs, SLOs, exceptions with PCE (proof‑carrying exceptions).
JSON (machine): normalized schema below; DSSE‑signed; includes SRM and policy references.

{
  "schema": "trust-statement.stellaops.dev/v1",
  "vendor": {"name": "Acme","product":"Payments API","version":"1.9.2"},
  "build": {"image_digest":"sha256:...","srm_digest":"sha256:..."},
  "policy": {"id":"corp-runtime@2025-08-15","digest":"sha256:..."},
  "summary": {
    "trust_sli": 0.9992,
    "exceptions": 1,
    "open_findings": {"critical":0,"high":2,"medium":4,"low":12}
  },
  "exceptions": [{
    "id":"EXC-2025-0912",
    "reason":"not_affected-via-vex",
    "proof_digest":"sha256:...",
    "expiry":"2026-01-15"
  }],
  "signatures": [{ "CryptoProfile":"FIPS-140-3" }]
}

Integrations

Push connectors: SAP Ariba, ServiceNow, Archer, Jira (webhooks or SFTP in offline flows).
CLI: stella trust-statement generate --srm srm.yaml --policy corp-runtime.lattice.json --out acme-1.9.2.trust.json --pdf.

Acceptance Criteria

JSON validates against schema; PDF and JSON hashes match the DSSE statement.
ERP ingest POC: Ariba/ServiceNow field mapping validated.

6) Third‑Party Proof Channel

Objective

Create a publisher ecosystem for upstream proofs: SBOM, VEX, and VDR (Vulnerability Derivation Reason).

Publisher Model

Identity: publishers obtain a Publisher Certificate (could be verified via RootPack‑anchored CA or cross‑signed).
Submission: stella ledger publish --type {sbom|vex|vdr} --artifact <digest> --file proof.json --sign.
Moderation & Revocation: CRL‑like Proof Revocation List (PRL) with signed reasons.

VDR (schema sketch)

{
  "schema":"vdr.stellaops.dev/v1",
  "artifact":"sha256:...",
  "cve":"CVE-2025-12345",
  "claim":"not_affected",
  "method":"entrypoint_unreachable|abi_mismatch|dead_code",
  "evidence_refs":[{"type":"symbol_map","digest":"sha256:..."}],
  "publisher":"redhat://rhel",
  "signatures":[...]
}

Consumption

Policies can prioritize publisher channels by trust level.
AOG shows which proofs originated from which publishers.

Acceptance Criteria

At least one upstream (e.g., base image vendor) can publish and your policy can consume & rank it.
PRL revokes a proof and AOG reflects the change within 5 minutes.

7) Zastava — differential SBOM + AI enrichment scheduler

Objective

Produce entrypoint‑aware differential SBOMs and continually re‑enrich new/old SBOMs with AI context and exposure‑aware prioritization.

Concepts

dSBOM: SBOM that reflects effective dependency set for a specific ENTRYPOINT/CMD and runtime flags (e.g., --server.urls, DOTNET_...).
Scheduler: rescans old SBOMs when: (a) new CVE feeds arrive, (b) new VEX/VDR appear, (c) policy changes, or (d) AI models learn new exploitability signals.

Pipeline

Static slice: infer reachable packages from entrypoint (e.g., .NET Kestrel vs CLI tool).
Runtime slice (optional): collect process tree, open sockets, and imported modules at startup in a shadow run or mirrored traffic.
Diff: dSBOM = SBOM ∩ (static_reachable ∪ runtime_observed).
AI Enrichment: Zastava annotates each finding with context weights (exposed/not exposed, network scope, RBAC, secrets proximity).
Plan: produce PRs (Dockerfile base bump, package pin, k8s Service change).
Scheduler:
- stella zastava schedule --query 'service=payments AND env=prod' --interval 6h
- Triggers re‑evaluation and emits updated SRM + Trust deltas.

dSBOM format (addon)

{
  "schema":"cyclonedx+stella-diff@1.0",
  "base_sbom":"sha256:...",
  "entrypoint": ["/app/bin/Release/net10.0/app.dll"],
  "cmd": ["--urls","http://127.0.0.1:8080"], 
  "static_reachable": ["pkg:nuget/Kestrel@*", "pkg:nuget/System.Data@*"],
  "runtime_observed": ["pkg:rpm/openssl@3.0.9"],
  "excluded_paths": ["/usr/share/docs/**"],
  "digest":"sha256:..."
}

Kestrel example (priority logic)

If Kestrel present but Service is ClusterIP and no Ingress, deprioritize; if LoadBalancer/NodePort with 0‑RTT TLS disabled, prioritize.
Zastava produces an explainable card: “Priority lowered due to non‑exposed runtime path; evidence: kubectl get svc, netstat, policy rule #42.”

Acceptance Criteria

Changing ENTRYPOINT produces a different, signed dSBOM and updated priorities.
Scheduler updates stale SBOMs and issues signed deltas without network access (when RootPacks + feed mirrors are available).

Cross‑Cutting Security & Compliance

Sanctions & Guardrails: per‑profile constraints (e.g., forbid dual‑signing across certain jurisdictions). Policy‑enforced at sign/verify time.
HSM Integrations: PKCS#11 providers for each profile (FIPS, GOST, SM2).
Data handling: SRMs and Trust Statements may contain paths and hashes; optional redaction profiles for vendor sharing.

Interfaces Summary (CLI)

# Scans / Replay
stella scan --image <digest> --srm-out srm.yaml
stella replay srm.yaml --assert-digest <sha>

# Policy & Lattice
stella policy lint corp.lattice.json
stella policy test --fixtures fixtures/
stella policy sign --profile FIPS-140-3

# Crypto Sovereign
stella rootpack import rootpack_ru_v1.tar.gz
stella attest sign --profile GOST-2012 --in srm.yaml
stella attest verify --profiles GOST-2012,FIPS-140-3

# AOG
stella aog export --format otlp
stella aog graph --artifact <digest>

# Trust Statement
stella trust-statement generate --srm srm.yaml --policy corp.lattice.json --pdf out.pdf --json out.json

# Third-Party Proof Channel
stella ledger publish --type vdr --artifact <digest> --file vdr.json --sign
stella ledger revoke --id <proof-id> --reason "superseded"

# Zastava
stella zastava diff-sbom --image <digest> --entrypoint "<cmd>" --out dsbom.json
stella zastava enrich --sbom dsbom.json --findings findings.json
stella zastava schedule --query 'env=prod' --interval 6h

Success Metrics (per pillar)

SRM: ≥ 99% of production images have SRM attached; Replay Success Ratio ≥ 0.99 weekly.
Policy/Lattice: 100% of exceptions carry proof; policy test coverage ≥ 90% on top CVE classes.
Sovereign: RootPacks for RU/CN/EU/US verified; dual‑signing working in CI; offline verification median < 200 ms.
AOG: Trust SLO ≥ 99.9%; lineage lookup p95 ≤ 2s.
Trust Statement: Accepted by at least one ERP (pilot); generation time ≤ 15s.
Third‑Party Channel: ≥ 3 upstream publishers integrated; PRL revocations flow to AOG within 5 minutes.
Zastava: dSBOM reduces non‑reachable high/critical findings by ≥ 35% without raising exposure incidents.

Risks & Mitigations

Crypto complexity: profile misuse → strict guardrails + default safe profiles, strong linting.
Cardinality/telemetry blow‑ups: AOG label hygiene + sampling.
Vendor adoption (Proof Channel): seed with your own base images and internal frameworks; provide SDKs and reference publishers.
Determinism regressions: CI runs replay tests on golden SRMs; any drift fails the build.

Competitive Landscape (Jan 2026)

Based on source-code audit of Trivy v0.55, Grype v0.80, Snyk CLI v1.1292, plus documentation review of Prisma, Aqua, and Anchore.

The Nine Structural Gaps We Exploit

#	Capability	Industry Status	Stella Ops Advantage	Module(s)
1	SBOM Fidelity	Static artifact, order-dependent, varies per run	Deterministic per-layer digests + Build-ID mapping; binary crosswalk	`Scanner`, `SbomService`, `BinaryIndex`
2	VEX Handling	Boolean suppression or absent	K4 lattice (Unknown/True/False/Conflict) with trust weighting	`VexLens`, `TrustLatticeEngine`, `Excititor`
3	Reachability	"Runtime context" badge (coarse)	Three-layer call-path proofs (static + binary + runtime) with DSSE	`ReachGraph`, `PathWitnessBuilder`
4	Backport Detection	Version string checks	Four-tier: distro feeds → changelog → patches → binary fingerprints	`Feedser`, `SourceIntel`, `BinaryIndex`
5	Smart-Diff	File-level/hash comparison	Semantic risk deltas ("exploitability dropped 41%")	`MaterialRiskChangeDetector`
6	Triage UX	Loud lists, duplicated root causes	Quiet queue + one finding per root cause + evidence panel	UI + canonical finding keys
7	Unknowns	Hidden/suppressed	First-class state with bands, decay, policy budgets	`UnknownStateLedger`, `Policy`
8	Attestations	Cosign-only or absent	in-toto/DSSE chain for scans, VEX, reachability, fixes	`Attestor`, `Signer`
9	Offline	Partial cache, degraded signals	Full parity with sealed snapshots + regional crypto	`AirGap.Controller`, `CryptoProfile`

Why Competitors Plateau (Architectural)

Competitor Class	Origin	Why They Can't Easily Catch Up
Trivy/Syft/Grype	Package scanners	No forensic reproducibility in architecture; evidence model is row-based, not content-addressed; VEX is filter, not logic
Snyk	Developer UX	SaaS-only means offline impossible; no attestation infrastructure; reachability is language-limited
Prisma/Aqua	Policy/compliance	No deterministic replay; no cryptographic provenance; verdicts aren't portable
Anchore	SBOM operations	No lattice VEX; no signed reachability graphs; no regional crypto profiles

Capability Gap Matrix

Capability	Trivy	Grype	Snyk	Prisma	Aqua	Anchore	Stella
Deterministic replay	No	No	No	No	No	No	Yes
VEX lattice (K4)	Boolean	Boolean	None	None	Limited	Limited	Full
Signed reachability	No	No	No	No	No	No	DSSE
Binary backport detection	No	No	No	No	No	No	Tier 1-4
Semantic risk diff	No	No	No	No	No	No	Yes
Unknowns as state	Hidden	Hidden	Hidden	Hidden	Hidden	Hidden	First-class
Regional crypto	No	No	No	No	No	No	Yes
Offline parity	Medium	Medium	No	Strong	Medium	Good	Full

Where We're Ahead (Unique)

Deterministic replay — Bit-for-bit reproducibility with stella replay
K4 lattice VEX — Conflict detection, not suppression
Signed reachability — DSSE graphs + edge bundles
Smart-Diff — Semantic risk deltas
Unknowns modeling — Bands, decay, policy budgets
Regional crypto — FIPS/eIDAS/GOST/SM/PQC as config

Where Competitors Lead (For Now)

Area	Leader	Our Response
Mass-market UX	Snyk	Focus on power users who need proofs
SaaS onboarding	Snyk, Prisma	Offer both SaaS and self-hosted
Ecosystem breadth	Trivy	Depth over breadth; evidence quality over coverage
Marketplace integrations	All	Prioritize based on customer demand

References

Competitive Landscape: docs/market/competitive-landscape.md
Claims Index: docs/market/claims-citation-index.md
Moat Strategy: docs/market/moat-strategy-summary.md
Proof Architecture: docs/modules/platform/proof-driven-moats-architecture.md

90‑Day Moat‑First Milestones

SRM v0.1: schema, deterministic executor, CLI replay, golden tests.
Policy Engine MVP: DSL + evaluator + UI simulation; policy unit tests; signed policy packs.
CryptoProfile/RootPack MVP: FIPS + GOST working; dual‑signing; offline verify.
AOG MVP: lineage service + OTLP exporter + Grafana pack; Trust SLI.
Trust Statement MVP: JSON + PDF; ServiceNow ingest POC.
Proof Channel alpha: publisher identity + VDR schema + local ledger; PRL.
Zastava α: diff-sbom + exposure heuristics for .NET Kestrel; scheduler with offline mirrors.

24 KiB Raw Blame History Unescape Escape

StellaOps Moat Track — Spec Outline v0.5

The Category Difference

Why Competitors Can't Easily Catch Up

Four Capabilities No Competitor Offers Together

0) Shared Concepts (applies to all 8)

1) Deterministic Replayable Scans — SRM

Objective

Deliverables

SRM (Stella Replay Manifest) — schema (abridged)

CLI & API

Determinism Rules

Acceptance Criteria

2) Policy Engine & Lattice UI

Objective

Trust Algebra Foundation (Implemented 2025-12)

Model

DSL (sketch)

UI (“Trust Algebra Studio”)

CLI & API

Acceptance Criteria

3) Sovereign Readiness — CryptoProfile + RootPack

Objective

CryptoProfile (attached to every signature/attestation)

RootPack

Dual‑Signing & Guardrails

Acceptance Criteria

4) Attestation Observability Graph (AOG)

Objective

Data Model

Metrics (OpenTelemetry/Prometheus)

Interfaces

Acceptance Criteria

5) Procurement‑Grade “Trust Statement”

Objective

Outputs

Integrations

Acceptance Criteria

6) Third‑Party Proof Channel

Objective

Publisher Model

VDR (schema sketch)

Consumption

Acceptance Criteria

7) Zastava — differential SBOM + AI enrichment scheduler

Objective

Concepts

Pipeline

dSBOM format (addon)

Kestrel example (priority logic)

Acceptance Criteria

Cross‑Cutting Security & Compliance

Interfaces Summary (CLI)

Success Metrics (per pillar)

Risks & Mitigations

Competitive Landscape (Jan 2026)

The Nine Structural Gaps We Exploit

Why Competitors Plateau (Architectural)

Capability Gap Matrix

Where We're Ahead (Unique)

Where Competitors Lead (For Now)

References

90‑Day Moat‑First Milestones

24 KiB

Raw Blame History