This Support Policy describes support for the Judgment platform. Support access depends on your plan and the Services covered by your agreement. Enterprise response targets apply only when an Order Form or signed agreement expressly incorporates this policy. Your signed agreement or Order Form controls any conflicting support terms.
Capitalized terms not defined here have the meanings given in your applicable Terms of Service or Cloud Services Agreement.
Scope and limitations
What support covers
We help customers use Judgment’s documented platform features and investigate problems with Judgment-controlled components. This includes:
- Account access, organization configuration, usage and billing questions.
- SDK setup, authentication and documented integrations with Judgment.
- Trace ingestion, evaluations and other platform workflows that are not working as documented.
- Product defects, release guidance and application-level troubleshooting.
Work that needs a separate agreement
Custom agent development, bespoke integrations, prompt or judge design, evaluation strategy, migrations and ongoing operation of customer infrastructure require a separately agreed scope unless included in your Order Form. Standard support does not include developing or debugging customer application code unrelated to a Judgment defect, or repairing a third party’s service.
We will help identify whether a reported problem comes from Judgment, an integration or another system. These scope limits do not exclude investigation and correction of defects in Judgment-controlled components, including our side of a documented integration.
Support by plan
Plan | Support access | Response targets |
|---|---|---|
Pro | Asynchronous help with covered platform, account and billing questions, provided on a best-effort basis. | Pro includes best-effort support, without guaranteed response times, resolution times or uptime. |
Enterprise | Support for the Services and coverage identified in your Order Form or signed agreement. | The enterprise targets below apply only where this policy is expressly incorporated, subject to any agreed exceptions. |
Requests should come from a member of the customer’s organization who is authorized to work with Judgment on the issue. For account-access problems, contact us from the email address associated with the account where possible.
Where to get support
Email contact@judgmentlabs.ai to request support. You can use the support request template below.
Slack
Contact us in the Slack support channel designated for your organization.
You may also use another support channel we designate for your organization. Direct messages to individual team members, sales conversations and social media are not designated support channels.
We record receipt when your first message about the issue reaches a designated support channel. Response time is measured from that point, counting only support hours. Forwarding the message, creating a ticket or reporting the same issue through another designated channel does not reset the clock.
Support request template
Email contact@judgmentlabs.ai using the template below. Include the details you have; additional information can follow during triage. Missing details do not delay initial triage or pause any applicable initial-response target.
To: contact@judgmentlabs.ai
Subject: Support request — [Organization] — [Short issue summary]
Organization: Affected project or environment: What happened: Impact on your work: When it started (include time zone): Steps to reproduce (if known): Recent changes or workaround (if any): Relevant request/trace IDs or redacted logs (if available):
When we support you
Hours and holidays
Support hours are 9:00 AM–7:00 PM Pacific Time, Monday through Friday. Pacific Time follows the applicable daylight-saving change. A business hour is one hour within this window; a business day is ten support hours.
Holiday exclusions apply only to dates identified in your Order Form or otherwise agreed with you in writing. If no holiday dates have been agreed, the normal weekday support hours apply.
How response time is measured
The initial-response clock starts when your first message about the issue reaches a designated support channel and counts only support hours. Requests received outside support hours start counting at the next opening. Unused time carries into the next support day; the clock does not restart overnight, over a weekend or on an agreed holiday.
For example, a request with a 30-minute response target received at 6:50 PM Pacific on Friday has used ten minutes of that target when support closes at 7:00 PM. The remaining twenty minutes run from 9:00 AM on the next support day, making the target 9:20 AM Monday if Monday is not an agreed holiday.
A first response means Judgment acknowledges the issue, confirms the initial severity and starts triage. An automated receipt alone does not count. Missing diagnostic information does not pause the initial-response clock.
After the first response, if necessary information or customer-approved access is missing, we may pause the affected mitigation or resolution work after telling you what is needed. That work resumes when the information or access is provided. Work that does not depend on it continues during support hours.
These support-clock rules do not extend or suspend separate security-incident notification obligations under your agreement or applicable law.
Enterprise response targets
Severity | Target first response |
|---|---|
Critical | 30 minutes during support hours |
High | 1 business hour |
Medium | 1 business day |
Low | 2 business days |
These targets concern the initial response. The update, mitigation and resolution targets for each severity are described below.
Issue severity
Severity is determined by customer production impact, business impairment, breadth of affected users and workloads, availability of a workaround, and risk to data or security. Judgment and Customer should reassess severity as new information becomes available during triage.
Critical
Production outage or business-critical impairment with no workaround.
Examples: Production service is down, customers cannot use core workflows, trace ingestion or evaluations are unavailable, data loss/corruption is suspected, or there is an active security incident.
- Target update cadence: Every 30–60 minutes during support hours until mitigated.
- Target mitigation / workaround: Continuous effort during support hours until service is restored or risk is contained.
- Target final resolution: Root-cause fix or corrective action plan after mitigation.
High
Production business impaired, but not a full outage; no reasonable workaround exists.
Examples: Critical workflows are severely degraded, core APIs are failing for a subset of users, severe latency/backlog affects production usage, or a deployment causes major customer impact.
- Target update cadence: Every 2–4 hours during support hours during active work.
- Target mitigation / workaround: Same business day where feasible.
- Target final resolution: Prioritized fix, rollback, or remediation plan.
Medium
Partial impairment, degraded non-critical functionality, or production issue with an acceptable workaround.
Examples: Intermittent failures, non-critical feature broken, delayed jobs with workaround, isolated integration issue, documentation gap blocking setup.
- Target update cadence: Daily or as material updates are available.
- Target mitigation / workaround: 2–3 business days where feasible.
- Target final resolution: Scheduled fix, documented workaround, or agreed backlog item.
Low
General question, minor defect, cosmetic issue, enhancement request, or advisory support.
Examples: How-to questions, configuration clarification, minor UI issue, best-practice review, roadmap or feature request.
- Target update cadence: As needed.
- Target mitigation / workaround: Best effort.
- Target final resolution: Best effort, roadmap consideration, or documentation update.
Mitigation, restoration and resolution
Mitigation means customer impact is reduced or contained, for example through a rollback, configuration change, scaling action, workaround, or feature disablement.
Restoration means the affected service or workflow is back within acceptable operating bounds.
Final resolution means the durable fix, root-cause remediation, documentation update, or mutually agreed closure path is complete.
Escalation procedures
- Judgment support performs initial triage, confirms severity, assigns an incident owner, and pulls in Judgment engineering for Critical, High, security-sensitive issues, and complex production-impacting defects.
- Critical incidents trigger immediate engineering escalation, dedicated incident ownership, and continuous work during support hours until mitigation or containment.
- High incidents trigger priority engineering review and may be escalated to incident mode if impact expands, no workaround exists, or mitigation is not progressing.
- Executive or leadership escalation should occur for extended Critical/High incidents, suspected data loss, security incidents, missed customer commitments, or material launch risk.
- During active incidents, Judgment should provide clear status updates with current impact, actions taken, next steps, owner, and next update time.
Shared responsibility
Judgment supports the platform, SDKs, APIs and other components we provide, including investigating and addressing defects in Judgment-controlled components.
You manage your own applications, integrations and the settings you control.
We work with your team to identify the source of an issue and coordinate troubleshooting across our respective systems.
Where troubleshooting requires access to your systems or data, that access should be approved by you, limited to what is necessary and for how long it is needed, and used only for agreed support work.
Uptime and service availability
Support response targets describe when we respond to a request. They do not establish a percentage uptime guarantee or promise that an issue will be resolved within a fixed time.
Any uptime commitment, availability measurement, downtime exclusions, maintenance treatment, service credits or related remedies must be expressly set out in a separate service level agreement or your Order Form or signed agreement. This Support Policy does not add an uptime guarantee or service-credit program.
Existing availability commitments and remedies in your signed agreement continue to apply according to that agreement.