Carried over from #126 and originally requested by @agarcher.
Applications need a sound, idiomatic Sorbet typing experience for structured-output responses, including typed access to nested application-owned models after response parsing. The existing SDK keeps response parsed fields broad because callers can supply different structured-output models.
The earlier OpenAI::BaseModel Tapioca compiler from #364 treated the proposed implementation as the requested outcome. Its generated reader signatures claimed nested model values even though directly constructed or assigned SDK transport models deliberately preserve caller-provided hashes. #385 attempted to reconcile that mismatch with additional runtime coercion, but architecture review established that retrofitting SDK transport models into an application typing framework is the wrong abstraction. The unreleased compiler is being removed separately while retaining the independent load-order and nullable-array fixes.
Desired outcome
- Give applications a supported, idiomatic way to use their own strongly typed structured-output models and obtain correctly typed nested values from parsed API responses.
- Evaluate purpose-built application modeling tools, such as an optional Sorbet
T::Struct integration that derives JSON Schema and hydrates responses at the structured-output boundary; do not treat this example as an approved public API.
- Preserve SDK transport-model construction and assignment semantics, caller-provided raw request identity, and existing generated request-model behavior. Do not introduce global nested coercion or reader signatures that contradict runtime values.
- Keep
sorbet-runtime optional and define dependency loading, supported schema/model features, validation or hydration errors, and compatibility guarantees before selecting a public API.
- Cover representative nested models, arrays, nilability, enums, and unions where the selected design supports them.
- Add public-boundary regression coverage for both Chat Completions and Responses structured-output flows, together with construction/assignment and generated-signature checks that prove static types match runtime behavior.
The underlying customer need remains open; the compiler implementation from #364 is not the desired architectural direction.
Carried over from #126 and originally requested by @agarcher.
Applications need a sound, idiomatic Sorbet typing experience for structured-output responses, including typed access to nested application-owned models after response parsing. The existing SDK keeps response
parsedfields broad because callers can supply different structured-output models.The earlier
OpenAI::BaseModelTapioca compiler from #364 treated the proposed implementation as the requested outcome. Its generated reader signatures claimed nested model values even though directly constructed or assigned SDK transport models deliberately preserve caller-provided hashes. #385 attempted to reconcile that mismatch with additional runtime coercion, but architecture review established that retrofitting SDK transport models into an application typing framework is the wrong abstraction. The unreleased compiler is being removed separately while retaining the independent load-order and nullable-array fixes.Desired outcome
T::Structintegration that derives JSON Schema and hydrates responses at the structured-output boundary; do not treat this example as an approved public API.sorbet-runtimeoptional and define dependency loading, supported schema/model features, validation or hydration errors, and compatibility guarantees before selecting a public API.The underlying customer need remains open; the compiler implementation from #364 is not the desired architectural direction.