# Changelog

This changelog records the documented source baseline. A version number identifies a contract or package; it does not establish that a hosted deployment is live, that packages have been published to a registry, or that execution has been authorized.

## SDK 2.1.0 — API v2 contract refresh

**SDK packages:** TypeScript `@klineo/liquidity-os-sdk` 2.1.0 and Python `klineo-liquidity-os` 2.1.0  
**API contract:** 2.0.0 at `/api/liquidity-studio/v2`  
**Current coverage:** 238 operations and 332 schemas in the generated OpenAPI contract

This client release refreshes the generated SDKs for the current API v2 contract. Relative to SDK 2.0.0, it adds:

- `getPartnerPreparationReceiptRecovery` in TypeScript and `get_partner_preparation_receipt_recovery` in Python for `GET /partner-preparation-receipts/{partnerId}`.
- The `PartnerPreparationReceipt` type for the verified committed preparation receipt.
- The `PartnerPreparationReceiptRecovery` type, which distinguishes `ACCEPTED` with a receipt from `UNRESOLVED` without a receipt.

The recovery operation retains interactive authentication and current actor-scoped bilateral preparation authority. An `UNRESOLVED` result is not proof that the original operation failed or that creating another preparation is safe. Follow the operation's contract and retain the original operation key when recovering an uncertain submission.

The API contract version remains 2.0.0, and the API base path remains `/api/liquidity-studio/v2`. SDK 2.1.0 does not enable execution, change custody authority, or bypass review. Registry publication and hosted availability are separate release steps; use the reviewed repository release or supplied source artifact.

## API 2.0.0 and SDK 2.0.0 — initial documented baseline

**API prefix:** `/api/liquidity-studio/v2`  
**OpenAPI:** 3.1.0  
**TypeScript package:** `@klineo/liquidity-os-sdk`  
**Python package:** `klineo-liquidity-os` / import `klineo_liquidity_os`

No public release date is assigned by this page. Use the release artifacts and installation instructions associated with the SDK repository you are using.

### Contract and client coverage

- Generated clients expose the v2 operations for intent and capital planning, simulation studies, strategy definitions, proposal workspaces, launch and unlock planning, market quality, treasury, evidence, and developer resources.
- Requests support organization binding, bearer credentials, operation-specific idempotency keys, strong `If-Match` preconditions, and cursor query parameters.
- OAuth client-credentials exchange is available for provisioned service clients. A service token can use only the operations and scopes it is authorized for; interactive human commands retain their separate authorization requirements.
- Clients support JSON responses, binary report responses, and structured API errors. The API contract preserves atomic amounts as strings.
- The generated OpenAPI contract is available from the v2 API at `/openapi.json`, relative to its base URL.

### Application and evidence workflows

The source also includes supported public project observations, tenant-private saved projects, Health and Research workflows, Candidate Review, immutable Decision Packs, project-control evidence, custody evidence, treasury reconciliation, assumptions, and historical scenario projections.

These workflows retain their evidence and authority limits. A public observation does not verify project ownership. A historical treasury projection does not prove spendable current cash. A completed review record does not create a financial approval or onchain transaction.

### Release posture

The committed v2 manifest is inactive and declares shadow feature states, a paused emergency state, autonomy level `0`, no automated execution, no live BOT rollout, and no external EVM V3 write adapters. Deployed component addresses, release commitments, accepted gate evidence, and signatures must be supplied through the release process before live authority can be established.

The underlying Studio v1 API remains a separate contract at `/api/liquidity-studio/v1`. Its runtime, automation, and funding checks still apply. V2 documentation does not imply that a v2 SDK is a drop-in client for every v1 route.

## Versioning and upgrades

Pin an SDK version and review the associated OpenAPI changes before upgrading. Check required fields, operation names, response shapes, scope requirements, and concurrency preconditions. Refresh generated types when the contract changes; do not manually edit generated client files.

For execution or evidence integrations, also check the runtime release status and the exact referenced resource versions. A compatible SDK upgrade cannot renew expired evidence or authorize a disabled feature.

Future entries should identify actual released artifacts, accepted environments, compatibility changes, and known limitations. Planned work is described on the [roadmap](/resources/roadmap/).