Status & Incident Management Procedure

Last updated 5 October 2026 · Effective 5 October 2026

This procedure describes how WholeStack classifies production incidents, enforces capability-level containment without a redeploy, and verifies resolutions against our deterministic spine.

1. Incident Classification & Response SLAs

WholeStack classifies production events into three operational severity tiers:

Severity P1 (Critical): Platform unavailability, database connection loss, breach of tenant isolation boundaries, or compiler inability to produce verified builds.
Triage SLA: 30 minutes · Containment SLA: 1 hour · Status updates: Every 30 minutes until resolved.
Severity P2 (Major): Third-party provider degradation (e.g. hosting or model inference provider timeout), verification queue backlog, or billing webhook delays.
Triage SLA: 2 hours · Containment SLA: 4 hours · Status updates: Hourly.
Severity P3 (Minor): Non-blocking localized defect, transient retryable failure, or cosmetic dashboard discrepancy.
Triage SLA: 1 business day · Resolution target: Next regular deployment cycle.

2. Operational Containment via Capability Kill Switches

To prevent localized bugs from causing state corruption or total platform downtime, WholeStack uses dynamic capability-level kill switches. These allow operators to disable an affected capability (for example, a generated record deletion mutation or an external integration) at runtime without requiring a code recompilation or application redeploy.

When a kill switch is active, the disabled capability immediately fails closed and returns HTTP 503 Service Unavailable with code CAPABILITY_DISABLED.
All other application capabilities, read surfaces, and unaffected workflows continue operating normally.
Once the defect is diagnosed and patched, the kill switch is released dynamically.

3. Reporting an Incident & Quoting Build IDs

To report an incident, outage, or critical defect, email support@wholestack.ai (or security@wholestack.ai for security disclosures).

Mandatory Requirement: Every support or defect report must include your Build ID or Support Reference ID (e.g. SUPPORT-ws-...), which is displayed in your Studio proof panel and receipt.

WholeStack is a deterministic software factory: we ship proof, not code. The Support ID pulls your application’s entire verifiable provenance chain:

The sealed contract hash (intent-lock.json)
The generated artifact hash
The exact verification run identifier
The cryptographic evidence bundle hash (proof-bundle.json)
The authoritative ShipGate verdict

Reports submitted without a Build ID cannot be verified against the deterministic compiler spine.

4. Resolution & Provenance Verification

Under WholeStack’s manufacturing laws, no incident resolution is considered complete until verified by automated proof:

The reported defect must be reproduced with an automated regression test.
A candidate build must be regenerated through the deterministic compiler spine.
The candidate must pass all 11 Artifact Fidelity invariants and execute the live runtime did-chain.
ShipGate must issue a cryptographically signed SHIP verdict with zero false SHIPs.

Only upon issuance of a passing proof receipt is the incident closed and the capability restored.

5. Live Status & Readiness Health

Platform service health and readiness probes are accessible at /api/ready, and customer build provenance chains can be inspected via /api/support/chain.