FilePart (as part of ContentPart) uses a single type: "file" with an overloaded data field (DataContent | URL, further expanded in #13816). In contrast, file content within ToolResultOutput already uses distinguishable types: file-data, file-url, file-id, etc.

This inconsistency causes practical problems:

• A string value in data is always assumed to be base64. Using it for anything else (e.g. a URL string) is brittle or requires hacky workarounds. See feat(provider/openai): full implementation for Files API file-ids and urls in Images, PDFs, across Chat and Responses #7804 for prior workaround, plus this was a real constraint Add support for uploading media files (e.g. images, audio, documents) via abstraction with new top-level API #12995 where we wouldn't be able to support a string-based provider reference because of this.
• Providers must inspect the runtime type of data (string vs URL vs Uint8Array) to determine intent, rather than matching on a discriminated type field.

Proposal

• Split FilePart into multiple discriminated types, mirroring what ToolResultOutput already does.
• Maintain the current types (e.g. "file") as deprecated parts of the union, which can be auto-mapped to the new discriminated types.
• In the provider spec, we can make this change potentially without maintaining that back compat layer, because it has much lower exposure on the ecosystem, and helps keep the spec simple.

Note: This affects both packages/provider-utils/src/types/content-part.ts and packages/ai/src/prompt/content-part.ts.

Aside: we should also consider getting rid of the file vs image distinction, because an image is simply a file with a specific media type. That's a separate change though, potentially to implement before this one.