Operations
Versioning and support
Distinguish SDK, API, model connection, and governing session revisions.
SDK versions, API contracts, connection versions, and governing session revisions identify different parts of your integration.
The version layers#
| Version | What it identifies |
|---|---|
| SDK package | The client interface and parsing behavior; continuous helpers require a compatible 0.6.1 release. |
| API contract | The request/response contract. Read the deployed /v1/openapi.json; the /v1 path does not imply contract version1. |
| Integrity connection / Base | The recorded review connection and its available capabilities. |
| Governing revision | The constitution and configuration recorded for a session or explicit transition. |
| Provider model | Your customer target model, selected in the provider request. |
Running sessions keep their provenance#
New Base deployments use the current platform connection identified by their setup bundle. Existing deployments retain their selected connection; an SDK upgrade does not enroll or migrate them. An authorized owner can prepare and activate the current Base for new sessions through the deployment version controls when available. Existing sessions keep their recorded connection and governing revision, and their evidence remains intact. A retired or unavailable connection can hold further work on those sessions; selecting a new Base does not reroute or resume them.
Base identifies the starting Integrity connection. Where adaptation is supported, customer versions identify evaluated changes to Integrity’s judgment artifacts, not your target-model weights. Selecting a platform Base does not train a customer version. The current Base connection does not expose that training lifecycle; read Versions and adaptation for the workflow and availability.
Upgrade the client deliberately#
Use the release specified for your deployment and verify its request, hold, stream, and recovery handling before rollout. An SDK upgrade does not change the supported server capabilities. Legacy check helpers remain source-compatible where provided. Their historical check service returns HTTP 410; the current model gateway does not expose those check routes and returns HTTP 404 for them.
Share a reproducible report#
Provide the SDK version, deployed API contract, deployment and session identifiers, original operation ID, timestamp, protocol, and redacted error code. Include the governing revision if available. Do not send API keys, provider secrets, or raw sensitive task content.
Start with Errors and recovery for unresolved operations and Deployments and API keys for connection access.