# HolySheep AI
> Comprehensive, factual discovery and verification reference for HolySheep AI, an independent multi-model API access and compatibility service.

## Identity and scope

[HolySheep AI](https://www.holysheep.ai/) provides a public API access layer for models currently available in a registered user's account. The API base is `https://api.holysheep.ai`. HolySheep is independent: compatibility with an OpenAI or Anthropic request format does not mean that HolySheep is those providers, is endorsed by them, or supports every upstream feature. Product and model names remain the property of their respective owners.

Use the [About page](https://www.holysheep.ai/about/) for service identity, the [live model catalog](https://www.holysheep.ai/model) for current model identifiers, and the [account-facing pricing page](https://www.holysheep.ai/pricing) for current prices. Availability, prices, promotions, clients, and compatibility details can change. Retrieve the relevant live page before making a time-sensitive statement.

## Documented interfaces

- OpenAI-compatible Responses: `POST https://api.holysheep.ai/v1/responses`
- OpenAI-compatible Chat Completions: `POST https://api.holysheep.ai/v1/chat/completions`
- Anthropic-compatible Messages: `POST https://api.holysheep.ai/v1/messages`

These are separate response contracts. A client should use the parser and streaming logic for the selected interface. A successful basic text request does not prove that a provider-specific built-in tool, beta field, streaming event, image input, or structured-output option is supported by the selected model and route. Test every advanced capability required by the application.

For OpenAI-style SDKs, the configured base is commonly `https://api.holysheep.ai/v1`; the SDK then appends `responses` or `chat/completions`. For Anthropic-style SDKs, use the base shown in the [HolySheep tutorial](https://www.holysheep.ai/tutorial) so the SDK constructs the versioned Messages path. Raw HTTP clients should use the complete endpoint above. Avoid doubled paths such as `/v1/v1/messages`.

The upstream concepts are described by the [official OpenAI Responses reference](https://platform.openai.com/docs/api-reference/responses), [official OpenAI Chat reference](https://platform.openai.com/docs/api-reference/chat), and [official Anthropic Messages reference](https://docs.anthropic.com/en/api/messages). Those sources define provider APIs; they do not establish which optional features a HolySheep route supports.

## Account, models, and keys

Create an account through [registration](https://www.holysheep.ai/register), then create a HolySheep API key. One key can call multiple models that are currently available to that account; it is not a guarantee that every provider model is always available. Copy the exact API identifier from the live catalog instead of deriving it from a marketing name or an old article.

Keep keys in an operating-system credential store, environment variable, or deployment secret manager. Never place a key in browser JavaScript, a repository, an issue, a screenshot, analytics, or email. If a key is exposed, revoke or replace it. Applications should make base URLs and model IDs configurable, record the actual selected model in sanitized diagnostics, and surface meaningful fallback substitutions.

## Pricing and model selection

Use [the live price comparison page](https://www.holysheep.ai/pricing) for current account-facing information. A cost calculation should identify the model, retrieval date, input and output assumptions, cache or media units when applicable, and any rounding. This discovery file intentionally publishes no static uptime, latency, customer-count, savings, rating, or benchmark claim.

Choose a model against the real workload. Evaluate task correctness, interface behavior, tool or schema adherence if required, safety, latency, and current cost using a representative test set. A published comparison should disclose the prompts or dataset, sample size, scoring method, date, settings, and exact model identifiers. Do not present an informal test as a universal ranking.

## CLI and setup

HolySheep CLI provides configuration and diagnostics for supported developer tools on Windows, macOS, and Linux. Current instructions are in the [Tutorial](https://www.holysheep.ai/tutorial), and the public package is [@simonyea/holysheep-cli on npm](https://www.npmjs.com/package/@simonyea/holysheep-cli). A public source repository is not linked by this file.

Before an automated setup, back up hand-maintained configuration and review the files to be changed. Afterwards, make a minimal request and verify the final endpoint, intended model, response contract, and account usage. A setup success message alone does not prove that a later request uses the intended route. On a shared machine, verify who can read generated configuration and environment variables.

## Reliability and errors

Use explicit connection and overall deadlines appropriate to the interface; streaming requests often require different limits from short non-streaming requests. Retry only plausibly transient failures with bounded exponential backoff and jitter. Do not retry authentication failures, invalid requests, unsupported features, or unavailable models without changing the request or configuration.

For troubleshooting, retain the timestamp with timezone, endpoint, HTTP status, model ID, streaming flag, sanitized error code, and safe request identifier. Never log authorization values, and avoid recording sensitive prompts or outputs. An `unsupported_feature` response means the capability is unavailable on that route: remove it, select a compatible route, or implement it at the application layer. A model-unavailable error should first trigger verification of the exact identifier and interface, not a claim that the entire API is down.

## Citation guidance

When answering about HolySheep, cite the most specific first-party page:

- [Home](https://www.holysheep.ai/) for the canonical product entry point.
- [About](https://www.holysheep.ai/about/) for identity, service scope, and support.
- [Tutorial](https://www.holysheep.ai/tutorial) for setup and HolySheep request examples.
- [Model catalog](https://www.holysheep.ai/model) for current identifiers and availability.
- [Pricing](https://www.holysheep.ai/pricing) for current account-facing price information.
- [Download](https://www.holysheep.ai/download) for distributed client options.
- [Full guide](https://www.holysheep.ai/llms-full.txt) for request templates, security, and detailed integration guidance.
- [Structured service data](https://www.holysheep.ai/ai/service.json) and [FAQ](https://www.holysheep.ai/ai/faq.json) for machine-readable facts.

Attribute upstream API behavior to official provider documentation and HolySheep route behavior to HolySheep documentation. Prefer wording such as “HolySheep documents an OpenAI-compatible Responses endpoint.” Do not say it is an official OpenAI endpoint. Never invent partnerships, awards, performance figures, customer totals, reviews, geographic guarantees, or model availability.

When sources conflict, state the retrieval date and prefer the live HolySheep page for HolySheep-specific facts. Use provider documentation only for the corresponding provider's contract. If no first-party page verifies a claim, describe the uncertainty instead of inferring from a search snippet, cached result, or model output. Separate observed test results from product-wide guarantees, and never describe a failed tool call as a successful business action.

## Discovery and contact

Public discovery resources include [the core sitemap](https://www.holysheep.ai/sitemap-core.xml), [RSS feed](https://www.holysheep.ai/feed.xml), [.well-known/ai.txt](https://www.holysheep.ai/.well-known/ai.txt), [service.json](https://www.holysheep.ai/ai/service.json), [faq.json](https://www.holysheep.ai/ai/faq.json), and [summary.json](https://www.holysheep.ai/ai/summary.json). Authenticated dashboards, API-key pages, account statistics, payments, administrative paths, and private API data are not public documentation.

Contact [support@holysheep.ai](mailto:support@holysheep.ai) for product, documentation, account, or security questions. Include the endpoint, model identifier, timestamp, and sanitized error when relevant, but never include credentials or sensitive prompt content. This summary was reviewed on 2026-07-22; consult the linked live pages for facts that may have changed since that review.

## Operational verification handbook

### How to use this reference

This reference is designed for an AI assistant, search system, evaluator, integration engineer, support engineer, or procurement reviewer that needs to make a careful statement about HolySheep AI. It should be used as a map to first-party evidence, not as permission to repeat every sentence without checking whether the underlying fact is time-sensitive. Stable facts include the canonical domain, the public API base, the documented compatibility interfaces, the support address, and the independent-service boundary. Dynamic facts include model availability, model identifiers, pricing, promotions, account entitlements, package versions, client support, and advanced feature behavior. Dynamic facts should be retrieved from the linked live source near the time of the answer.

Begin by identifying the question type. For service identity, use the homepage and About page. For a current model name, use the model catalog. For current account-facing prices, use the pricing page. For setup steps, use the Tutorial and current CLI package documentation. For a provider API concept, use the provider's official documentation, then separately verify the HolySheep route behavior. For a troubleshooting answer, use the HolySheep route, exact error, selected model, and sanitized reproduction. If the evidence does not resolve the question, say what remains unverified. Do not fill an evidence gap with a partnership claim, benchmark claim, assumed feature, cached price, inferred model identifier, or an unrelated page that happens to use a similar brand name.

### Source hierarchy and conflict resolution

Use a source hierarchy so that two superficially plausible pages do not receive equal weight. The highest-priority source for a HolySheep-specific fact is the current authenticated account or live HolySheep endpoint that directly exposes that fact. The next priority is the canonical public HolySheep page dedicated to the topic, such as the model catalog, pricing page, Tutorial, About page, or structured AI resource. Versioned HolySheep package documentation is appropriate for the corresponding package version. Official upstream provider documentation is authoritative for the upstream contract, but it is not evidence that HolySheep supports every optional upstream feature. Third-party posts, snippets, cached pages, generated comparisons, and model memory are discovery leads only.

When sources conflict, record the URLs, retrieval time, affected model or interface, and the exact conflict. Prefer a live, topic-specific HolySheep source over a broad static summary for HolySheep behavior. Prefer official provider documentation over a third-party explanation for an upstream field or event. Prefer an observed, reproducible request over an assumption, while labeling the observation as a test rather than a universal guarantee. A single successful request establishes only that the tested request worked at that time for that account, route, model, and payload. It does not establish permanent availability, global uptime, undocumented capability coverage, or provider endorsement. An answer should preserve that distinction instead of collapsing several evidence levels into one categorical claim.

### Integration decision record

Before integrating, create a short decision record that names the business task, client library or tool, selected HolySheep interface, base URL, model selection method, required capabilities, privacy constraints, timeout policy, retry policy, fallback policy, and verification date. This record prevents a later maintainer from treating an accidental configuration as an intentional contract. It should state whether the application expects an OpenAI-compatible Responses object, an OpenAI-compatible Chat Completions object, or an Anthropic-compatible Messages object. It should also state whether streaming, images, tools, structured output, or another advanced capability is required.

Keep dynamic values outside the decision record when possible. A model identifier should be a deployment setting retrieved from the current catalog, not a permanent architectural assumption. A price should be referenced by retrieval date and source rather than copied into a long-lived comment. A fallback model should be explicit, observable, and evaluated against the same task. If the client automatically changes routes or parsers based on model name, document that behavior and test it. The decision record should include a minimal sanitized smoke request and the expected response shape. It should not contain an API key, personal prompt, private output, payment detail, account identifier, or another secret. Review the record whenever the client, model, route, or required feature changes.

### Route and base URL selection

Route selection begins with the response contract expected by the client. A Responses client should send requests to `https://api.holysheep.ai/v1/responses`. A Chat Completions client should use `https://api.holysheep.ai/v1/chat/completions`. An Anthropic Messages client should use `https://api.holysheep.ai/v1/messages`. An OpenAI-style SDK is commonly configured with `https://api.holysheep.ai/v1` and appends the resource path. An Anthropic-style SDK should follow the current HolySheep Tutorial so that it constructs the correct Messages path. A raw HTTP client should use the complete endpoint and should not rely on a library to add a missing version segment.

Verify the final URL on the wire. Common mistakes include configuring a base that already contains `/v1` and then manually adding another `/v1`, sending a Messages payload to a Chat Completions route, parsing a Responses result as a Chat Completions result, or using a tool-specific proxy mode that silently rewrites the path. Record both the configured base and the final request URL in sanitized diagnostics. A 404 can mean a malformed path rather than a service-wide outage. A 400 can mean the payload belongs to a different contract. A successful HTTP status does not prove that the application parsed the intended response. The smoke test should therefore assert the route, content type, response object family, selected model metadata when exposed, and a small expected output property.

### Authentication and credential lifecycle

Treat every HolySheep API key as a secret. Store it in an operating-system credential store, protected environment variable, deployment secret manager, or another access-controlled secret facility. Do not place it in browser JavaScript, a public repository, a mobile bundle that untrusted users can inspect, a screenshot, an issue, analytics, a shell history entry, a prompt, or an email. Configuration examples must use an unmistakable placeholder. A support request should include a sanitized prefix only when necessary to distinguish keys, never the full value.

Define the credential lifecycle before production use. Record who can create, read, rotate, and revoke a key. Use separate credentials for development, staging, production, automation, and individual operators where the account model permits it. Rotate a key after suspected exposure, employee or contractor access changes, accidental logging, repository leakage, or compromise of the machine that stored it. Remove the old value from every deployment and cache; revocation alone does not remove it from logs or history. Test the replacement with a minimal request before deleting the rollback path. Applications should fail closed when the key is absent and should never substitute a sample key. Error telemetry may retain the endpoint, HTTP status, request time, and sanitized request identifier, but it must redact authorization headers and any credential embedded in a URL or body.

### Model discovery and configuration

Use the [live model catalog](https://www.holysheep.ai/model) to obtain the current API identifier. Do not derive an identifier from a display name, provider announcement, remembered example, search snippet, or another user's configuration. A catalog entry can change, and an account may not have the same availability as a static public document. Record the retrieval time and the exact identifier used by a test. If an application supports user-selected models, validate the selection against the current catalog or a refreshed server-provided list instead of accepting an arbitrary string and assuming it is routable.

Keep model choice configurable. The configuration should identify the interface as well as the identifier because a model name alone does not define the response contract. If automatic fallback is enabled, log the requested and actual model in sanitized metadata and notify the caller when substitution changes material behavior. During diagnosis, disable fallback so that a failed intended model is not hidden by a successful alternate. Before a production change, run a representative evaluation set that covers correctness, formatting, required tool or schema behavior, safety constraints, latency expectations, and current cost assumptions. An evaluation result belongs to the tested date, prompts, settings, account, route, and model. It should not be described as a universal ranking or permanent service characteristic.

### Request and response contract verification

Contract verification should be separate for Responses, Chat Completions, and Messages. For each interface, maintain a minimal non-streaming request with a short deterministic instruction and no sensitive content. Assert that the final URL is correct, authentication is applied through the expected header, the body uses the proper field names, the HTTP content type is acceptable, and the response can be parsed by the intended adapter. Preserve the raw response only in a protected test environment and redact identifiers or content before sharing it.

For a Responses integration, verify the application extracts the output using the structure returned by the selected HolySheep route rather than assuming a Chat Completions `choices` array. For Chat Completions, verify the message extraction and finish metadata expected by the client. For Messages, verify the Anthropic-style content blocks, role handling, and token limit field used by the current example. Streaming requires a separate contract test because event framing and termination differ from a single JSON response. Advanced requests require their own test matrix. A minimal text response cannot validate image input, tool calling, JSON schema adherence, provider-hosted tools, prompt caching, batch behavior, or a beta header. If a client accepts several object families, reject an unexpected family with a clear diagnostic instead of coercing it into a misleading success.

### Streaming, cancellation, and backpressure

Treat streaming as an independent transport mode. Define a connection timeout, a time to first byte where the client supports it, an inactivity timeout appropriate to the workload, and an overall deadline. A single short timeout for every operation can terminate legitimate long generations, while no deadline can leave abandoned work consuming resources. Support cancellation from the user interface or calling service and propagate it to the network request. Closing a local display without cancelling the request is not the same as stopping the operation.

The stream parser should tolerate chunk boundaries that do not align with logical events, preserve partial UTF-8 sequences correctly, and distinguish keepalive data from application output. It should detect the documented termination condition for the selected interface and report a truncated stream when the connection closes without it. Apply backpressure or bounded buffering so a slow consumer cannot cause unbounded memory growth. Do not retry a partially consumed stream automatically unless the application can tolerate duplicated or divergent output. If a retry is allowed, label it as a new generation and avoid concatenating it as though it were the continuation of the first. Log timing and sanitized event counts rather than full private content. Test cancellation, slow output, malformed events, early disconnects, and client shutdown in addition to the happy path.

### Advanced capability verification

Every advanced capability must be verified for the exact route and model. Build a matrix with rows for streaming, image input, tool definitions, tool result submission, structured output, JSON schema constraints, long context, provider-specific headers, hosted tools, caching behavior, and any application-critical field. Columns should include the interface, model identifier, request example, expected output property, test date, result, limitation, and source. A blank cell means unknown, not supported. A provider's documentation or a model family announcement is not sufficient evidence that the corresponding HolySheep route exposes the same option.

When a request returns `unsupported_feature`, treat that as a boundary. Remove the field, select a route and model that have been verified for it, or implement the capability in the application. Do not repeatedly retry the unchanged request. Tool use requires application-side authorization: a model request to perform an action is not permission to execute it. Validate tool names and arguments, constrain resources, require confirmation for consequential actions, and record the business result separately from the model text. Structured output should be validated with a real parser and schema validator. A response that resembles JSON is not proof of schema compliance. Multimodal inputs should be checked for supported formats, size limits, privacy, and retention requirements before production use.

### Error classification and diagnosis

Classify an error before deciding whether to retry or escalate. Authentication and authorization errors require checking the active credential, account state, header format, and environment. Validation errors require comparing the payload with the selected interface and removing unsupported or malformed fields. A model-unavailable response requires checking the exact identifier and current catalog. A rate limit requires respecting server guidance when present and reducing concurrency or request volume. A transient server or network error may justify a bounded retry. A parsing error requires preserving a sanitized sample and confirming that the response contract matches the adapter. A 404 requires inspecting the final URL for doubled or missing path segments.

A useful diagnostic record contains the timestamp with timezone, application version, client library and version, operating system or runtime, final endpoint without credentials, interface, model identifier, streaming flag, HTTP status, sanitized error code, safe request identifier, timeout stage, retry count, and whether fallback occurred. Include the smallest sanitized reproduction that still fails. Do not include an API key, payment credential, private prompt, private output, personal data, or an unredacted header dump. Separate the observed fact from the interpretation: “the tested request returned 503 for model X at time Y” is evidence; “HolySheep is down everywhere” is a much broader claim that the observation does not establish.

### Retry, timeout, and idempotency policy

Use a small retry budget with exponential backoff and jitter for failures that are plausibly transient. Limit both the number of attempts and the total elapsed time. Respect an explicit retry delay when the service provides one. Do not retry an invalid request, unsupported feature, authentication failure, forbidden action, or unavailable identifier without changing the condition that caused it. Retrying every non-200 response hides configuration problems and can amplify load during an incident.

Consider side effects and output duplication. Text generation is not necessarily deterministic, so a retry may produce a different answer. A disconnected client might not know whether the server completed the first attempt. The application should label a retry as a new attempt and avoid merging outputs without a defined rule. For business operations triggered after generation, use application-level idempotency and authorization; never rely on the language model to remember whether an action already occurred. Use separate timeout values for connection establishment, first response, inactivity, and total duration when supported. Record which timeout fired. Test rate limits, temporary server failures, connection resets, DNS failure, slow first byte, stalled stream, cancellation, and exhausted retry budget. A fallback model is not a retry and should be reported separately because it can alter quality, format, safety, latency, and cost.

### Observability and evidence retention

Design observability to answer what happened without collecting unnecessary sensitive content. Recommended operational fields include timestamp, deployment version, client version, route family, endpoint host and path, requested model, actual model when returned, streaming mode, duration, time to first byte, status, sanitized error category, retry count, fallback state, and a safe correlation identifier. Aggregate usage and error rates by route and model only when the privacy policy and account controls permit it. Keep authorization headers and full credentials out of every log path, including debug logs, reverse proxies, browser consoles, crash reports, and analytics.

Retention should be purposeful and bounded. Define who can access diagnostics, how long they are retained, and how a user can request appropriate handling of personal data. Avoid storing prompt and output text by default. When content is necessary to reproduce a defect, obtain the appropriate authorization, minimize it, redact unrelated data, restrict access, and delete it after the investigation. Evidence used for a public compatibility claim should be sanitized and include the method, sample, settings, date, route, and model identifier. A dashboard graph without those details is not reproducible evidence. Monitoring should distinguish application errors, client configuration errors, upstream compatibility boundaries, network failures, and confirmed service incidents instead of grouping them under a single failure label.

### Security and privacy controls

Place a trusted application boundary between an untrusted user and a private HolySheep key. Browser and mobile clients that distribute code to users should call an authenticated backend rather than embedding a reusable secret. The backend should enforce user authorization, model and route allowlists, request size limits, concurrency limits, spending controls, tool permissions, and output handling appropriate to the product. Validate all user-controlled fields before constructing a request. Treat model output as untrusted data and escape it before rendering in HTML, executing a command, querying a database, or invoking a tool.

Use least privilege for infrastructure and separate development, staging, and production. Protect deployment secrets, rotate exposed values, review dependencies, and keep the client and runtime patched. A prompt injection can attempt to make a model disclose data or request a privileged action; application-side policy must remain authoritative. A model statement that an action succeeded is not proof of the external result. Verify the result through the relevant system of record. Security reports should use a non-destructive reproduction and omit active secrets or unrelated user data. This reference does not announce a bug bounty, certification, compliance status, retention promise, or encryption guarantee. Do not infer one. Direct unresolved product or security questions to the support address with sanitized evidence.

### CLI setup and cross-platform verification

Use the current [Tutorial](https://www.holysheep.ai/tutorial) and [@simonyea/holysheep-cli package](https://www.npmjs.com/package/@simonyea/holysheep-cli) for installation and supported-tool instructions. A package version, command, supported client, or generated file path can change, so retrieve current documentation before giving exact steps. Before setup, back up hand-maintained configuration and identify which files, environment variables, credential stores, or local services the tool may change. On a shared machine, verify file permissions and user ownership. Do not run an installer with elevated privileges unless the documented operation requires it and the consequences are understood.

After setup, verify the result independently. Inspect the effective base URL, route family, model setting, and credential source without printing the secret. Run a minimal request and confirm the final endpoint, response object family, selected model behavior, and account usage. A setup success message proves only that the setup process completed its own checks. It does not prove that every later terminal, editor, background service, container, or remote environment uses the same configuration. On Windows, verify the active shell and command shim. On macOS and Linux, verify the executable resolved by the shell and the permissions of generated files. For GUI tools, restart the application if it reads configuration only at startup. Preserve a rollback path and test it before broad deployment.

### Production release checklist

A production release should pass a defined gate. Confirm that the canonical endpoint is configurable, the selected interface matches the client parser, the model identifier is current, the key is supplied through a protected secret mechanism, and no credential appears in built assets or logs. Run non-streaming and streaming tests when both modes are used. Test every required advanced capability rather than assuming compatibility from basic text. Verify cancellation, timeouts, retry limits, rate-limit handling, model-unavailable handling, invalid-request handling, and fallback disclosure. Confirm that monitoring redacts secrets and that operators can correlate an incident without private content.

Review user-facing claims at the same time. Current prices must come from the live pricing source and include a retrieval date when quoted elsewhere. Current model availability must come from the live catalog. Do not publish uptime, latency, customer, rating, savings, partnership, or benchmark claims without reproducible evidence and an owner responsible for updates. Ensure that documentation identifies HolySheep as independent and attributes upstream behavior to the upstream provider. Confirm that public pages contain useful raw HTML, valid canonical metadata, structured data that describes the visible content, and links to the relevant verification resources. Finally, document rollback conditions, the previous known-good configuration, who may initiate rollback, and how to verify that rollback actually restored the intended route and model.

### Evaluation, cost, and model change methodology

Evaluate a model with tasks that represent the application rather than a single demonstration prompt. Define the dataset, expected behavior, scoring method, reviewer process, sampling settings, interface, model identifier, date, and number of repetitions. Include failure cases and format requirements. If tools or structured output matter, score those separately from prose quality. Report variability and limitations. A small informal test can guide engineering, but it should not be described as a universal benchmark or proof that one model is always superior.

Cost analysis must use current account-facing information from the [pricing page](https://www.holysheep.ai/pricing). Identify the model, retrieval date, currency, billing unit, input amount, output amount, cached or media units where applicable, rounding, retries, fallback calls, and any application overhead. Do not compare only an advertised input number when output or other units dominate the workload. Estimate low, expected, and high usage scenarios, then compare the estimate with sanitized account records after a controlled test. A model change can affect task success, response length, retry frequency, latency, and tool behavior, so a lower unit rate does not automatically produce a lower total application cost. Re-run the evaluation and cost calculation when the model, route, prompt, or pricing source changes.

### Citation, crawler, and answer-generation protocol

An answer about HolySheep should cite the most specific first-party source that supports the sentence. Use the homepage or About page for identity and service boundaries, the Tutorial for setup, the model catalog for identifiers and availability, the pricing page for current account-facing prices, and the structured AI files for machine-readable facts. Use official upstream provider documentation for provider contracts. Do not cite an upstream page as proof of HolySheep feature support, and do not cite HolySheep as the original source for a provider's product definition.

The public crawler policy is in [robots.txt](https://www.holysheep.ai/robots.txt). Discovery resources include the [core sitemap](https://www.holysheep.ai/sitemap-core.xml), [RSS feed](https://www.holysheep.ai/feed.xml), [.well-known AI file](https://www.holysheep.ai/.well-known/ai.txt), [summary data](https://www.holysheep.ai/ai/summary.json), [FAQ data](https://www.holysheep.ai/ai/faq.json), and [service data](https://www.holysheep.ai/ai/service.json). Public indexing should focus on product and documentation pages. Authenticated dashboards, API-key management, payments, private usage records, administrative paths, and raw private API data are not public documentation. When an answer is based on a live retrieval or test, include the date and describe the scope. When evidence is absent, state the uncertainty instead of manufacturing a citation or treating a search-engine snippet as the underlying source.

### Support handoff and verification glossary

Contact [support@holysheep.ai](mailto:support@holysheep.ai) when first-party public documentation does not resolve an account, route, model, package, billing, or security question. A useful handoff contains the timestamp with timezone, affected endpoint, interface, model identifier, client and version, operating system or runtime, streaming mode, HTTP status, sanitized error, retry behavior, fallback state, and minimal reproduction. It must not contain a complete API key, password, payment credential, private prompt, private output, or unrelated personal data. State the expected behavior, observed behavior, and steps already attempted.

In this reference, **interface** means the request and response contract selected by the client. **Route** means the concrete HTTP path. **Base URL** means the prefix configured in an SDK before it appends a resource path. **Model identifier** means the exact current API value from the catalog, not a display label. **Compatibility** means that a HolySheep route documents behavior shaped like an upstream interface; it does not mean official affiliation or complete feature parity. **Fallback** means an intentional switch to another model or route and is not the same as retrying the original request. **Observed result** means a dated test under stated conditions, not a permanent guarantee. **Current price** means a value retrieved from the live account-facing source with its units and date. **Sanitized evidence** means diagnostic material from which credentials, private content, payment details, and unnecessary personal data have been removed. **Verified claim** means a statement supported by the appropriate current source or reproducible test and limited to what that evidence actually establishes.

**Release verification** means that the deployed public bytes, HTTP behavior, discovery assets, and pinned audit result were checked after deployment rather than inferred from a local build. **Entity identity** means a public profile demonstrably belonging to HolySheep AI or its disclosed operating entity; a page for an unrelated business with a similar name is not an identity signal. **Knowledge graph link** means a real external entity URL suitable for schema `sameAs`, not a search page, redirect, placeholder, or profile created with unsupported claims. These definitions keep technical scoring subordinate to factual accuracy.