Support Policy (commercial baseline)
This is a software-only support policy template for Helix Desktop/CLI + Teams deployments. It is intended to be procurement-friendly and easy to operationalize.
Scope
In scope:
- Helix Desktop/CLI behavior, deterministic artifact generation, offline verification.
- Helix Teams/Registry (RBAC, artifact store, proof URLs, audit export, metrics/health endpoints).
- Deterministic reproductions using provided bundles, receipts, and support bundles.
Out of scope (unless explicitly contracted):
- Customer-specific infrastructure and IdP configuration (beyond “best effort” guidance).
- Tuning third-party dependencies (Kubernetes distributions, object stores, proxies).
- Any real‑world biological procedures (Helix is in‑silico only).
Support channels
- Primary: a customer-specific email or ticketing endpoint (defined in your contract)
- Escalations: named escalation contacts (defined in your contract)
- Security: follow
SECURITY.md
Severity levels
Helix uses a simple severity model:
- Sev0: service/data integrity incident (data loss, signature/receipt integrity failure, auth bypass)
- Sev1: core workflow broken (cannot run packs, cannot fetch/verify, Teams unusable)
- Sev2: degraded behavior or partial outage (intermittent failures, performance regression)
- Sev3: minor issues (cosmetic UI, docs gaps, non-blocking bugs)
Response targets (business time)
These targets are intended for enterprise contracts; adjust per tier.
| Severity | First response | Mitigation plan | Target fix / workaround |
|---|---|---|---|
| Sev0 | 1 hour | 4 hours | 48 hours |
| Sev1 | 4 hours | 1 business day | 5 business days |
| Sev2 | 1 business day | 2 business days | next patch release |
| Sev3 | 3 business days | next sprint | scheduled |
What we need to debug quickly (receipts, not vibes)
Preferred artifacts (in order):
- The artifact bundle directory/zip (or proof URL + receipt id)
- A support bundle (
helix support bundle --out helix_support_bundle.zip) - The exact command line / config used (or the
session.helix.jsonfrom the bundle)
Support bundles are designed to be redacted by default (see observability policy docs).
Upgrade policy
- Supported: additive Teams DB schema upgrades (new tables/columns/indexes).
- Not guaranteed: downgrades (older binaries may not understand newer DB rows/columns).
- Releases include reproducible checksums/SBOMs and are intended to be verifiable offline.
Maintenance window and release cadence
Default posture:
- Patch releases as needed for Sev0/Sev1 issues.
- Regular release train for feature work (cadence negotiated per customer).
Data handling
- Helix is offline-friendly; verification does not require trusting Helix services.
- When customers share support artifacts, we treat them as confidential and store them per contract.