Review draft — not in force. This document has not been reviewed by legal counsel. It is a source-controlled draft published for inspection and comment. It is not in force, is not an offer or a contract, does not create any obligation or commitment, and does not describe terms that currently govern any product, service, or relationship. Kaleidoscope is not publicly released; the governing terms will be published separately with a production release. Do not rely on this text.
In development Kaleidoscope is not publicly released. Nothing here installs
from a registry yet — see what is available.
Support policy (review draft)
Proposed standard support terms; prereleases and test-signed packages remain unsupported and no service level exists without a separate written plan.
Download the plain-text source.
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