LangSmith adopts reference_outputs for creating dataset examples

LangSmith’s [Cloud updates for October 19–26](https://docs.langchain.com/langsmith/changelog) introduce `reference_outputs` for the expected outputs stored when creating dataset examples, including bulk creation. The changelog lists the API and the Python, JavaScript, Go and Java SDKs. It does not give a separate launch day or a minimum SDK version for this change. The useful distinction is the direction of the data: these are the expected outputs a caller supplies with an example. The new creation‑field name does not replace every `outputs` field elsewhere in the example workflow.

The release notes say outputs remains a deprecated alias, so existing code using that name continues to work. A creation request containing both reference_outputs and outputs is rejected.

That gives compatibility wrappers a specific boundary. Copying an old request object and adding the new key does not provide a fallback if it leaves both fields in the request. Use one supported creation field rather than populate both.

The linked dataset how‑to still shows examples using outputs. Those examples are consistent with the retained alias; they do not establish that both names should be sent together.

For these example workflows, the [changelog](https://docs.langchain.com/langsmith/changelog) explicitly says responses, updates and multipart uploads still use `outputs`. A caller can therefore use `reference_outputs` when creating an example and still encounter `outputs` when reading the result back. Treat this as a creation‑request change, rather than perform a global property rename across serializers and response readers. Language‑specific SDK member names and version requirements should be checked against the client being used; the notice alone does not establish a new spelling or version floor for each language. Conceptual illustration of alternative API field names and a single request, created for OpenTools. This is not a LangSmith interface or a measured result.