KALEIDOSCOPE SUPPORT POLICY
REVIEW DRAFT - NOT FOR PRODUCTION USE

Last updated: August 22, 2026

This draft describes proposed standard support for a local Kaleidoscope
product. It creates no service-level agreement, warranty, maintenance promise,
or public support claim. Production support begins only when a supported
release, staffed intake channel, business hours, and plan terms are published.

1. COVERED PRODUCTS

Standard support may cover:

- the current generally available public manager, SDK wrappers, integrations,
  and agent skill;
- the proprietary engine object-code package under a valid entitlement; and
- the operating systems, architectures, package managers, and host versions
  explicitly listed in the production compatibility table.

A separate order or paid support plan controls if it states different scope,
response times, hours, or remedies.

2. NOT COVERED

Unless a written plan says otherwise, standard support excludes:

- release candidates, local staging builds, test-signed artifacts, nightly
  builds, source snapshots, and refusal-only packages;
- unlisted platforms, host versions, custom forks, modified binaries, or
  packages whose integrity cannot be verified;
- third-party services, models, frameworks, or operating systems except for
  reasonable interoperability diagnosis;
- user-authored prompts, memory content, business logic, data recovery, or
  backup administration;
- incidents caused by credential compromise, unsupported configuration,
  failure to install an available fix, or use contrary to documentation;
- consulting, architecture design, migrations, custom integrations, and
  performance tuning; and
- security research, which must use the private security-reporting channel.

3. SUPPORT CHANNEL

Before production, publish one authenticated support portal or monitored email,
the operating legal entity, business hours and time zone, supported languages,
and escalation process. Public issues may be used for non-sensitive
Apache-licensed SDK defects after a public repository exists, but must never
contain credentials, private engine material, exploit details, or user memory
data.

4. INFORMATION TO PROVIDE

A support request should include:

- product and exact version;
- operating system, architecture, package manager, and relevant host version;
- package and executable digests where available;
- a concise expected-versus-observed description;
- reproducible steps using non-sensitive test data;
- redacted error output and diagnostics; and
- recent relevant changes.

Users must review diagnostics before sharing them. Remove local paths, account
identifiers, provider keys, tokens, memory content, prompts, queries, results,
and vault coordinates. Support may refuse unsafe uploads and ask for a minimal
redacted reproduction.

5. SEVERITY GUIDANCE

Proposed severity levels are:

- Severity 1: verified security incident, data-loss risk, or complete outage of
  a supported production use with no workaround;
- Severity 2: major supported function unavailable or severely degraded, with
  material impact and no reasonable workaround;
- Severity 3: limited defect with a workaround or moderate impact; and
- Severity 4: question, documentation issue, compatibility request, or feature
  request.

Kaleidoscope may reclassify a request based on verified impact and scope.

6. PROPOSED RESPONSE TARGETS

For standard support during published business hours, proposed non-binding
initial-response targets are:

- Severity 1: 1 business day;
- Severity 2: 2 business days;
- Severity 3: 5 business days; and
- Severity 4: 10 business days or best effort.

A response is an acknowledgement and triage action, not necessarily a fix.
No restoration, resolution, uptime, or response SLA applies unless a written
paid plan expressly provides one. These targets require staffing confirmation
before production.

7. FIXES AND WORKAROUNDS

Support may provide documentation, configuration guidance, a workaround, an
upgrade recommendation, or a product fix. Security and compatibility fixes may
be delivered only in the current release. Kaleidoscope does not promise to
backport a fix or maintain compatibility with an unpinned third-party host.

8. VERSION LIFECYCLE

Only versions in the production support table are covered. Proposed default:
the current release and the immediately preceding minor release remain eligible
for standard support for 90 days after replacement. Kaleidoscope should give at
least 90 days' notice before ending ordinary support where practicable, but may
end support sooner for legal, security, third-party platform, or emergency
reasons.

No lifecycle period applies to prereleases. A separate long-term-support plan
must be stated in writing.

9. USER RESPONSIBILITIES

Users are responsible for:

- maintaining verified backups and testing restoration;
- controlling device, profile, credential, and vault access;
- using supported platforms and installing fixes within a reasonable time;
- preserving a safe minimal reproduction;
- obtaining rights and consents for data they process; and
- maintaining a reasonable business-continuity plan.

Support activity does not authorize Kaleidoscope to access or delete a local
vault. Remote access, if ever offered, requires separate informed consent,
least privilege, a defined session, and an audit trail.

10. PRIVACY AND CONFIDENTIALITY

Support data is handled under the production privacy notice and applicable
order. Support personnel should access only the minimum data necessary and must
not use customer memory content, prompts, queries, or results for advertising
or model training without a separate explicit opt-in.

11. REQUIRED PRODUCTION COMPLETION

Before this policy becomes effective, confirm:

- legal entity, support channel, staffing, hours, and time zone;
- supported products, versions, platforms, packages, and host pins;
- plan tiers, entitlements, targets, exclusions, and any remedies;
- data-handling, secure upload, retention, and deletion procedures; and
- escalation ownership for security, privacy, billing, and account recovery.

END OF REVIEW DRAFT