Use one base prompt
The prompt should vary by deployment mode, not by AI agent. Codex, Claude Code, Cursor, private harnesses, and CI agents can all receive the same Kivo brief as long as the selected data boundary is explicit.
AI agents should connect Kivo, not recreate it
The prompt is for wiring Kivo into an existing application, pipeline, or worker runtime. It should not ask a customer AI agent to implement Kivo's verifier, claim report logic, credential system, or control plane.
Agent-neutral
Keep the brief about Kivo objects, endpoints, credentials, and tests. Avoid tool-specific instructions unless the harness needs them.
Boundary first
Choose Kivo API Deployment only for approved packets. Choose Enterprise Worker Deployment when raw traces or sources must stay in your environment.
Reviewer output
Ask the agent to surface Kivo claim reports, unsupported claims, request IDs, and gate verdicts instead of producing a bare API call.
Base prompt
Paste into your AI agent
You are connecting an existing product or AI workflow to Kivo.
Kivo is a claim-level source-support control plane. It creates review runs for AI-generated outputs, extracts atomic claims, maps them to supplied source evidence, verifies source support, returns a claim report, and exposes workflow status such as gate verdict and safe-use status.
Use Kivo only for claim-source verification against supplied sources. Do not describe it as a hallucination eliminator, legal approval system, medical safety system, financial approval system, hiring decision system, compliance decision system, or autonomous truth guarantee.
Do not recreate Kivo's claim extraction, source-support verifier, worker credential flow, claim-report generator, or control plane. Use Kivo-provided APIs, worker packages, credentials, and documented response objects.
First choose the deployment mode:
- Kivo API Deployment: use only when submitted packets are synthetic, sanitized, low-sensitivity, or explicitly approved for Kivo-hosted processing.
- Enterprise Worker Deployment: use when raw AI outputs, prompts, traces, source snippets, screenshots, uploads, or embeddings must stay in your environment.
Integration task:
1. Locate the server-side point where the application has an AI output, the user question or workflow context if available, supplied source evidence, citations if present, intended use, and metadata.
2. Assemble a review-run payload with ai_output, sources, intended_use, strictness, and metadata.
3. Keep Kivo credentials server-side. Never expose KIVO_API_KEY or worker credentials in browser code, mobile apps, logs, screenshots, or client-visible config.
4. Use the selected Kivo surface: hosted review-run endpoints for Kivo API Deployment, or the Kivo-provided worker package for Enterprise Worker Deployment.
5. Store the returned review_run_id, request_id, status, gate verdict, safe-use status, claim counts, unsupported-claim counts, and claim-report link or storage pointer.
6. Poll or process completion until the review run reaches completed, failed, or cancelled.
7. Surface the claim report to a human reviewer when the status is needs_review, needs_repair, blocked, contradicted, unsupported, partially_supported, or insufficient_context.
8. Add narrow tests for the integration adapter: payload construction, credential scoping, unsupported-claim handling, error responses, and the selected deployment-mode boundary.
Public hosted API endpoints for Kivo API Deployment:
- POST /v1/review-runs
- GET /v1/review-runs/{reviewRunId}
- GET /v1/review-runs/{reviewRunId}/claims
- GET /v1/review-runs/{reviewRunId}/verification-results
- GET /v1/review-runs/{reviewRunId}/claim-report
- POST /v1/imports
Implementation rules:
- Use existing project conventions, HTTP clients, environment-variable handling, logging, and test patterns.
- Treat raw sources as sensitive.
- Preserve Kivo request IDs in logs.
- Do not invent unlisted public endpoints.
- Do not silently drop unsupported claims.
- Do not let an LLM self-certify the result without stored verifier metadata.
- If the deployment mode or data boundary is unclear, stop and ask before wiring production data.Deployment add-ons
Add exactly one of these blocks after the base prompt. Do not create separate prompts for each hosting vendor unless that vendor changes the data boundary or runtime constraints.
Kivo API Deployment
Use this deployment mode: Kivo API Deployment.
Wire the integration to KIVO_API_BASE_URL and a scoped server-side KIVO_API_KEY. Submit approved review packets to POST /v1/review-runs, poll GET /v1/review-runs/{reviewRunId}, and fetch claims, verification results, and the claim report after completion.
Assume submitted ai_output, supplied source content, citations, and workflow metadata may be processed by Kivo-hosted services under the approved deployment terms. Do not use this path for sensitive production traces unless hosted processing has been explicitly approved.Enterprise Worker Deployment
Use this deployment mode: Enterprise Worker Deployment.
Do not send raw AI outputs, prompts, traces, retrieved context, source snippets, screenshots, uploads, or embeddings to Kivo-hosted review-run endpoints. Keep raw packets in your environment, run the Kivo-provided worker package there, write detailed claim reports to your storage, and send only metadata, counts, verdicts, hashes, request IDs, worker version, policy version, redacted failure categories, and storage pointers to Kivo.
If the worker package, run-scoped credential, storage target, or job-spec format is not available, list the missing setup inputs instead of creating a substitute worker or bypassing the data boundary.Deployment choice
| Question | Use Kivo API Deployment when | Use Enterprise Worker Deployment when |
|---|---|---|
Can raw AI outputs and supplied sources leave your environment? | Yes, the packet is synthetic, sanitized, low-sensitivity, or explicitly approved. | No, raw content must remain in your cloud, VPC, storage, queue, or controlled compute. |
Where should detailed claim reports live? | Kivo-hosted app/API is approved for the review artifacts. | Detailed reports must be written to your storage. |
What should the AI agent connect? | Server-side calls to create review runs, poll status, and retrieve claim reports. | The Kivo-provided worker package, your storage output, and metadata-only Kivo reporting. |
If the answer is unclear
Start with synthetic or sanitized examples. Do not ask an AI agent to route sensitive production traces through the hosted API while the deployment mode is still undecided.