Integration template
Scope the workflow in enough detail to ship.
Use this template to define the first production workflow, align stakeholders, prepare the source package, and measure whether Distil improves quality, cost, or throughput.
1. System classification
Choose the closest operating environment so the first workflow uses the right inputs and acceptance checks.
- Retail commerce
- Marketplace or social platform
- Support or customer-success operation
- Education or research workflow
- Engineering system
- Multimodal source-preparation workflow
2. Business outcome
Write the target outcome as a concrete, measurable job.
- Improve product-page quality.
- Reduce support handle time.
- Summarize source-heavy research materials.
- Prepare a safer software-change context.
- Detect changing topic or sentiment signals.
3. source package definition
Define exactly what raw material enters the workflow. A useful source package should be bounded, repeatable, and mapped to the downstream job.
{
"workflow": "priority SKU product-page improvement",
"sources": [
"catalog record",
"recent reviews",
"Q&A",
"return reasons",
"support snippets",
"search queries",
"optional product or shelf images"
],
"refresh": "nightly or when review/return volume crosses threshold",
"max_raw_tokens": 40000,
"owner": "merchandising operations",
"sensitive_fields_to_exclude": ["payment data", "private account identifiers"]
}
4. Endpoint sequence
Pick the smallest public sequence that supports the job. Distil performs source preparation inside the managed service.
/v1/compress: large source packages, including text, documents, images, audio, and video.
/v1/context/run: task-specific answers from a hosted context handle.
5. Request template
Use task-aware fields so the hosted context supports what the workflow actually needs. The public /v1/compress body accepts text and/or mixed sources; media normalization runs inside the managed Distil pipeline.
{
"text": "<optional source notes>",
"sources": [
{"type": "document", "name": "policy.pdf", "text": "<document text>"},
{"type": "image", "name": "shelf.jpg", "data": "<base64>"},
{"type": "audio", "name": "call.m4a", "data": "<base64>"}
],
"video": {"name": "walkthrough.mp4", "mime": "video/mp4", "data": "<base64>", "duration_seconds": 120},
"task": "Prepare hosted context for the target workflow.",
"rubric": [
"Preserve required facts",
"Separate source facts from interpretation",
"Keep uncertainty visible"
],
"must_preserve": [
"policy limits",
"citations",
"return reasons",
"failure messages",
"customer commitments"
]
}
6. Hosted context contract
Define what a usable hosted context must support before another system relies on it. Customer applications store the handle and consume task-specific outputs.
- Required facts and identifiers.
- Source counts and time window.
- Evidence examples or citation anchors.
- Known uncertainty and missing material.
- Downstream action or handoff shape.
7. Handle and refresh strategy
Reuse hosted context handles so the same source material is not processed repeatedly.
- Store
context_handle, expires_at, package version, workflow name, and review criteria version.
- Handle key: workflow + package version + task/review criteria version.
- Refresh on source change, time window, or business event.
- Store raw source references separately from handle metadata.
- Expire handles when policy, pricing, or source ownership changes.
Hosted context lifecycle and runtime contract
- Access boundary: a handle can be run or deleted only by the same account and exact API key that created it. A replacement key cannot access prior handles; revoke the old key when rotating credentials.
- Scopes: use
compress:write for /v1/compress, /v1/context/run, and handle deletion.
- Retention: handles are accessible for 365 days by default and return
expires_at. Create a new version when sources or the quality contract change.
- Deletion:
DELETE /v1/context/{context_handle} removes a handle early at no credit charge.
- Idempotency: every successful hosted-context request creates a new immutable handle. Keep a customer-side package version and review criteria version to avoid duplicate work.
- Runtime:
/v1/context/run runs the requested task against the hosted handle and reports account-visible usage.
- Output: optional
output_contract, style, and max_output_tokens fields control the task-specific output. Output tokens are bounded from 256 to 6,000 and default to 1,600.
- Errors: retry 429 and 5xx responses with bounded exponential backoff. Do not retry validation, ownership, or expiration errors unchanged.
8. Downstream handoff
Specify where the task output goes after Distil: dashboard, automation, review queue, answer generator, or enterprise tool.
Handoff rules:
- Use the task output as the primary context.
- Do not invent missing facts.
- Preserve uncertainty labels.
- Escalate to raw source when exact wording, policy, legal, medical, financial,
security, or high-impact details are required.
9. Output boundary
Define what the workflow should receive from each run. Keep the hosted context behind the handle and return only the task-specific evidence needed for the workflow.
Output rules:
- Do not return downloadable hosted context state.
- Return only task-necessary facts, uncertainty labels, citations, and actions.
- Reject requests that ask to reveal, decode, export, or reconstruct hosted context state.
- Log that output validation passed before delivery.
10. Quality contract
Quality is the gate. A smaller request only matters if the resulting workflow stays reliable enough for production.
{
"required_checks": [
"all must-preserve facts present",
"no unsupported claims",
"citations or source anchors preserved when available",
"uncertainty is labeled",
"output schema validates"
],
"human_review": [
"first 50 production cases",
"all high-impact decisions",
"all low-confidence recognition matches"
],
"fallback": "use the customer-controlled raw-source baseline when the candidate fails the quality contract"
}
11. Cost scenario
Estimate value from the actual workflow, not a generic compression claim.
- Package size and update cadence.
- Expected activation pattern.
- Monthly source packages.
- Account-visible credits.
- Repeated work avoided.
- Review and operations cost.
12. Observability
Instrument the workflow from first request through downstream result.
- Endpoint used first.
- Credits consumed per workflow run.
- Handle readiness and activation behavior.
- Output validation pass/fail reason.
- Validation pass/fail reason.
- Fallback rate.
- Human correction rate.
13. Security and privacy
Minimize source material before it enters any automated workflow.
- Exclude payment secrets and private account identifiers.
- Mask or remove fields not needed for the task.
- Log request metadata, not raw source packages.
- Restrict access to raw source fallbacks.
- Define retention for hosted handles and customer-visible task outputs.
14. Enterprise operational readiness
Confirm the operating contract before production traffic begins.
- Rate limits are per API key in a rolling one-minute window; isolate services with separate scoped keys.
- Measure p50, p95, and p99 latency on the customer's own payload distribution.
- Set alerting for 429, validation, service, and billing failures.
- The public API does not include a contractual SLA, configurable data residency, or dedicated throughput commitment.
- Document required region, support response, throughput, retention, and incident-reporting terms during enterprise onboarding.
15. Rollout plan
Expand only after the measured workflow improves.
- Offline replay on historical examples.
- Internal review dashboard.
- Limited production cohort.
- Automatic use for low-risk passing cases.
- Continuous sampling against raw-source baseline.
16. Acceptance checklist
- The source package is bounded and repeatable.
- The endpoint sequence is minimal for the job.
- The hosted context preserves required facts.
- The downstream handoff labels uncertainty.
- The handle key includes workflow, package version, and review criteria version.
- Retention, deletion, key rotation, and duplicate-request behavior are tested.
- The output boundary is validated before delivery.
- The quality contract has deterministic checks and human review rules.
- The cost model uses account-visible credits, downstream usage, and review cost.
- The fallback path is tested before production launch.
- SLA, residency, throughput, support, and incident terms are either accepted as public limitations or covered by an enterprise agreement.
Tip: the best first workflow is usually one with repeated large inputs, obvious human review cost, and a clear baseline answer or decision to compare against.