GitHub Repo
TypeSafe Python SDK 0.7.0 Adds Typed Responses for Jev, Switches Serialization to Pydantic
The update maps decision answers to Pydantic models for classification and routing workflows. The serialization change requires migration testing, while Chinese-language accuracy and probability thresholds still need separate evaluation.
TypeSafe AI released Python SDK 0.7.0 on September 18, adding an interface for specifying response types for the Jev decision model and switching serialization and deserialization from msgspec to Pydantic. The company lists the latter as a breaking change, and PyPI confirms that the package was published the same day. Developers who have integrated the SDK into classification, routing, or scoring workflows need to check compatibility. [Changelog](https://docs.typesafe.ai/sdk/python/changelog), [Package release details](https://pypi.org/project/typesafe-sdk/0.7.0/)
Jev accepts a textual or structured state along with questions predefined in code. Choice selects from a set of options and returns a probability distribution, Score assigns a rating on an ordered scale, and Noul returns the probability that a proposition is true. All three question types can be included in a single request, each evaluating the same state. This interface is well suited to incorporating semantic judgments into existing program branches. [Model interface](https://docs.typesafe.ai/introduction)
The specific change in this release is the addition of a `response_model` parameter to `system_one`. Developers can subclass `SystemOneResponse` to declare named answer fields or define their own Pydantic models, turning answers previously accessed through dictionary keys into typed attributes that are easier to inspect and use downstream. This improves the client-side data contract; the correctness of the judgments still requires separate evaluation. [Usage examples](https://docs.typesafe.ai/sdk/python/usage)
Two migration details are easy to overlook. Version 0.7.0 fixes a bug that caused string subclasses to be encoded as lists of characters. Developers upgrading from versions earlier than 0.6.0 will also encounter that release’s change to Score criteria: they must now be provided as an ordered sequence, and dictionaries with integer keys are no longer accepted. Existing request samples, response handling, and custom serialization workflows should all be replayed to verify compatibility. [Compatibility changes](https://docs.typesafe.ai/sdk/python/changelog)
Typed outputs also cannot replace decision threshold calibration. According to the official documentation, confidence values for Choice and Score are statistics computed from probability distributions; Noul has no equivalent field. The documented limitations also note that values may not be directly comparable when the same question is expressed using different primitives, and the probabilities of a question and its negation are not guaranteed to sum to one. [Confidence definitions](https://docs.typesafe.ai/confidence), [Known limitations](https://docs.typesafe.ai/model-jaggedness/jev-1.13)
Chinese-language applications particularly need their own test sets. The official documentation explicitly identifies English as the primary training language, notes that performance differs for languages such as Chinese, and warns that adversarial inputs can alter judgments. Engineering implementations should retain rejection or human escalation paths, leave arithmetic and date comparisons to code, and pin the model version after calibrating thresholds to prevent alias updates from changing behavior. Acceptance testing should measure classification errors, human escalation rates, and end-to-end latency separately to assess the value of this interface update in real workflows. [Language and version policies](https://docs.typesafe.ai/models), [Input risks](https://docs.typesafe.ai/model-jaggedness/jev-1.13)