Q for developers

Release an integration

Check deployment compatibility, permissions, recovery and evidence before serving real users.

Use this checklist when moving from the synthetic examples to a provisioned Q environment. Local fixtures qualify the HTTP contract; they do not establish model accuracy, hosted capacity or durable worker recovery.

Match the deployed contract

  • Record the deployment’s API root, /v1/capabilities and /v1/openapi.public.json. Check availability, stability, scopes and feature gates for every operation you call.
  • Use the SDK support matrix and a matching published package or explicitly qualified local archive. This source snapshot does not prove publication.
  • Check migration guidance and deprecation policy. Keep a rollback path for your client changes.

Prove access boundaries

  • Keep Q credentials on your backend. Map the authenticated application user to authorised tenant resources; test a denied resource and a different user as well as the successful case.
  • Confirm corpus permissions, data governance, outbound destinations and the scopes required for your selected capabilities.
  • Configure real application sessions, CSRF protection and distributed limits for browser clients. The loopback proxy is an example, not a production identity provider.

Prove recovery and completion

  • Persist mutation keys and receipts before dispatch; simulate an interrupted response and recover the original work without creating a duplicate.
  • For durable agents, qualify the actual Temporal service/worker, approval handling, cancellation, deadlines and replay through a restart. A workflow ID alone is not proof of completion.
  • For answers, consume final revisions and inspect evidence, citations and quality. Exercise unavailable retrieval as well as no relevant evidence.
  • For artifacts/webhooks, confirm storage permissions, download integrity and receiver behaviour. Retry/replay using the delivery contract.

Observe real operating conditions

Measure representative quality, latency, capacity and spend using your permitted corpus and providers. Review service objectives and diagnostics, but do not treat candidate targets as a contractual SLA. Qualify alert ownership, receiver delivery, retention and recovery in the actual environment.

Record who approved each requirement and where the evidence is stored. Q operators can use the platform qualification register for the corresponding platform gates. If a requirement is unresolved, keep it visible with an owner and closure condition.

On this page