Document ID: VIBEPACKR_ENTERPRISE_PRODUCT_SUPPORT_SLA_CUSTOMER_FACING_PROJECTION_EN
Document Class: CUSTOMER-FACING SLA PROJECTION
Status: DRAFT / LEGAL REVIEW REQUIRED BEFORE EXECUTION
Product: VibePackr
Operating Model: Single-Tenant / Customer-Controlled Environment / Non-SI
Canonical Language: English
Projection Date: 2026-08-20
1. Purpose
This Service Level Agreement defines the product support scope, incident classification, target response times, customer responsibilities, exclusions, and service boundaries for VibePackr Enterprise.
VibePackr product support is not a managed operations service, customer infrastructure SLA, systems integration service, or customer environment operation service.
2. Supported Product Scope
This SLA applies to the VibePackr Enterprise product components listed in the applicable Order Form, license, release package, or Commercial Handbook.
Supported scope may include VibePackr runtime components, Packr Engine, PackrGUI, Official Packs, official SDKs and typed contracts, validators, Integration Helper product functionality, packaging artifacts, and supported evidence or recovery mechanisms where included in the applicable product package.
Components, drafts, candidate features, historical artifacts, or future capabilities are not supported unless included in the applicable contractual product scope.
3. Deployment and Responsibility Model
VibePackr is deployed as a single-tenant product in a customer-controlled environment.
The customer or its designated operator is responsible for cloud accounts, VPCs, VMs or hosts, storage, backup, network, DNS, firewalls, identity providers, IAM, credentials, certificates, keys, monitoring, disaster recovery, and production change management.
The supplier is responsible for product support within the VibePackr product boundary. The supplier does not operate the customer environment unless separately contracted.
4. Non-SI Integration Boundary
This SLA is not a Systems Integration contract.
Unless separately agreed, the supplier is not responsible for custom adapters, custom Packs, customer workflows, ERP customization, database migration, custom APIs, IAM architecture, cloud infrastructure, or customer production cutover.
The Integration Helper, where provided, is a self-service product capability. It may assist with discovery, contract resolution, schema mapping, scaffold generation, validation, and diagnostics. It is not an SI service, and generated scaffold is not a completed production integration.
5. Official Packs and Customer Packs
Official Packs included in the applicable product scope are supported as VibePackr product components. Official Packs may be supported even where no separate per-Pack fee is charged.
Customer-authored Packs, extensions, integrations, adapters, and customer-specific code are customer or implementer responsibility. If a customer implementation exposes an underlying defect in the VibePackr SDK, contract, validator, runtime, or official schema, that product defect will be handled within product support scope.
6. Third-Party Services
Third-party cloud providers, AI model providers, source repositories, ITSM systems, identity providers, databases, APIs, operating systems, browsers, package repositories, and customer infrastructure are not warranted under this SLA.
Where VibePackr is designed to detect, block, fail over, route, bind, or project external failures, the correctness of VibePackr's documented internal product behavior remains within product support scope.
7. Incident Classification
An Incident is an event where a supported VibePackr product component fails to conform to documented or contractually defined behavior within a supported configuration.
Incident records may distinguish product defect, customer infrastructure defect, configuration issue, integration defect, third-party failure, operator error, unsupported configuration, and insufficient evidence.
Severity levels are:
| Severity | Description |
|---|---|
| Severity 1 - Critical | Critical product defect causing total supported governance runtime unavailability, widespread inability to perform documented governance workflows, confirmed material durable-state risk, or critical protected-operation governance failure. |
| Severity 2 - High | Major product defect causing substantial degradation of supported workflows, major Official Pack failure, or significant recovery, validation, or integration-helper defect. |
| Severity 3 - Medium | Partial product defect, bounded feature failure, non-critical validator issue, recoverable projection issue, or material documentation inconsistency. |
| Severity 4 - Low | Minor defect, cosmetic issue, general question, documentation clarification, or low-priority service request. |
A correct governance block is not downtime. A correct failover is not an outage. A product-caused failover may still be classified as a product defect if evidence supports that conclusion.
8. Support Workflow
Support is provided through the official support channel stated in the applicable Order Form, Commercial Handbook, or support notice.
Baseline support is asynchronous and support-bundle-first unless a separate agreement provides a different support tier.
The customer must provide reasonable evidence for diagnosis, such as product version, release identity, support bundle where available, logs, reproduction steps, environment description, configuration details, and impact statement.
Support diagnostics begin read-only where practical. Customer production mutation, source modification, credential changes, schema migration, data mutation, process termination, or destructive tests require explicit customer authority and appropriate rollback planning.
9. Recovery and Replacement Artifacts
Where supported by the applicable product package, the supplier may provide patches, corrected builds, replacement artifacts, or Golden Image replacement guidance.
Golden Replacement is a product recovery approach for replacing supported runtime artifacts while preserving durable customer assets where those assets are technically and contractually decoupled.
Recovery support does not mean the supplier operates the customer environment or assumes responsibility for customer infrastructure, customer data backup, customer deployment approvals, or customer production acceptance.
10. Response Targets
Unless the Order Form states otherwise, target initial response times are:
| Severity | Target initial response |
|---|---|
| Severity 1 | 1 business hour |
| Severity 2 | 4 business hours |
| Severity 3 | 1 business day |
| Severity 4 | 3 business days |
Response targets are targets for acknowledgement and support engagement. They are not guaranteed resolution times, customer infrastructure uptime guarantees, third-party service guarantees, or service-credit commitments unless the applicable contract expressly says so.
Business hours, holidays, region, language, named support channels, support tier, and escalation contacts are defined in the applicable Order Form or Commercial Handbook.
11. Exclusions
Unless separately contracted, this SLA excludes:
- managed operations and routine 24x7 human staffing;
- remote SSH backdoors or persistent remote administration;
- on-site support visits;
- customer cloud, network, identity, storage, backup, disaster recovery, monitoring, or production change management;
- custom integration or implementation work;
- third-party provider availability, latency, pricing, quality, quota, or model behavior;
- customer-authored Packs, adapters, integrations, workflows, policies, and source code;
- unsupported configurations;
- feature requests and integration projects;
- legal, regulatory, financial, or business outcome warranties.
12. Remedies and Contract Precedence
This SLA defines support scope and response targets. It does not independently create service credits, penalties, liquidated damages, refund rights, termination rights, liability allocation, indemnity, or damages caps.
Any service credits or remedies must be expressly stated in the Master Agreement or Order Form.
Unless otherwise stated in executed documents, precedence is:
1. Master Agreement;
2. Order Form;
3. this SLA;
4. Commercial Handbook or support guide;
5. operational runbooks and support procedures.
Operational runbooks and support procedures do not override executed contract terms or canonical product behavior.