Support

How to report bugs, ask for features, and contact the maintainers when something on the public surface is not behaving the way these pages say it should.

What belongs here

What does not belong here

The hosted service, the prompts, the validators, the routing, the retrieval corpus, the billing pipeline, the eval suite, and the internal documentation are out of scope for this repository. Issues that affect only the hosted service are handled through the customer support channel.

Reporting a bug

Use the bug issue template in .github/ISSUE_TEMPLATE/bug.yml. A useful report contains:

Reporting a security issue

Email the address listed in your customer onboarding materials. Do not open a public issue. See SECURITY.md at the repository root for the full process and the cryptographic-material policy.

Requesting a feature

Use the feature issue template in .github/ISSUE_TEMPLATE/feature.yml. Note that wire-contract changes go through the internal review process first; external contributors do not edit the wire spec directly.

Status and incidents

The status of the public surfaces is communicated through the customer support channel. This repository never includes status pages, on-call notes, or incident reports.

Enterprise escalation path

Enterprise customers use three channels in order of urgency. Open the first; if you do not hear back inside the SLA window, escalate to the next.

StepChannelUse it for
1 Support tickets — support-tickets.vedika.io Bug reports, integration questions, token or billing questions, anything reproducible.
2 Slack Connect channel Day-to-day engineering chat with your assigned CSM and SRE. Shared with the customer’s team only; nothing else from the customer’s side touches it.
3 Jira service desk Outages, security incidents, anything blocking production. Opened from the Slack channel or by emailing the address in your onboarding materials.

Include your deployment URL, the turn id from x-vedika-turn-id, and the SDK version in every ticket. A useful ticket is reproducible inside five steps.

Enterprise SLAs

Service levels are set in the agreement signed for your account. Response and resolution targets are confirmed by your account team when you sign.

Severity Definition First response Resolution target
1 — Critical Production outage or a security incident that affects end users of your app. Set in your agreement Set in your agreement
2 — High A feature is degraded for your end users but there is a workaround. Set in your agreement Set in your agreement
3 — Normal Bugs that do not affect end users, integration questions, token or billing questions. Set in your agreement Set in your agreement
4 — Low Documentation, feature requests, cosmetic issues. Set in your agreement Set in your agreement

Uptime and latency targets are part of the same agreement:

MetricTargetMeasurement window
Chat API uptimeSet in your agreementCalendar month
First-token latency (p50)Set in your agreementCalendar month
First-token latency (p95)Set in your agreementCalendar month
Token-mint latency (p95)Set in your agreementCalendar month

Severity definitions, response targets and the uptime and latency numbers are agreed with your account team when you sign.

What stays in the customer channel

The hosted service, prompts, validators, routing, retrieval corpus, billing pipeline and internal runbooks are out of scope for this repository. Issues that affect only the hosted service are handled through the customer support channel above. This page documents the boundary on purpose: the public surface is narrow by design.