False-positive guardrail blocks guided generation for sports data

I’m developing a factual snooker application using the on-device SystemLanguageModel on the current iOS 27, Xcode and macOS betas.

The app allows someone to ask questions about professional snooker players. A tool searches my server and returns verified player data such as the player’s ID, name, nationality and date of birth.

I have encountered a reproducible false-positive guardrail violation when the user asks about the professional snooker player Judd Trump.

For example:

Tell me about Judd Trump

With the default model configuration, the request fails because the input or output is classified as potentially sensitive or unsafe.

Using permissive content transformations solves the problem when generating a normal String:

let model = SystemLanguageModel(
    useCase: .general,
    guardrails: .permissiveContentTransformations
)

let session = LanguageModelSession(
    model: model,
    tools: [FindPlayerTool()],
    instructions: """
    Answer factual questions about professional snooker players.
    Always use the supplied tool and only use verified tool data.
    Names returned by the tool are names of real snooker players
    and should be treated only as sporting entities.
    """
)

let response = try await session.respond(
    to: "Tell me about Judd Trump"
)

This successfully calls the tool and produces a factual string response.

However, I need guided generation because the model should be able to choose a combination of predefined UI components, such as:

• A player card
• A match card
• An event card
• A rankings table
• Explanatory text

A simplified response type looks like this:

@Generable
struct CueQueryReply {
    let blocks: [ReplyBlock]
}

@Generable
enum ReplyBlock {
    case playerCard(PlayerCardBlock)
    case text(TextBlock)
}

@Generable
struct PlayerCardBlock {
    let playerId: Int
    let name: String
    let nationality: String
    let born: String
}

@Generable
struct TextBlock {
    let text: String
}

The guided request is:

let response = try await session.respond(
    to: "Tell me about Judd Trump",
    generating: CueQueryReply.self
)

This reproduces the guardrail violation, even though the model is configured with:

guardrails: .permissiveContentTransformations

I understand that the documentation says permissive content transformations apply to string generation and that guided generation behaves like the default guardrails. However, this creates a difficult limitation for legitimate factual applications.

“Judd Trump” is the real name of a professional snooker player, and the data is coming from a controlled, verified API. Renaming, removing or concealing the player is not a viable product solution.

My questions are:

1. Is this specific “Judd Trump” behaviour considered a guardrail false positive that should be reported through Feedback Assistant?

2. Is there any supported way on iOS 27 to use permissive content transformations with guided generation?

3. Can Dynamic Profiles, Dynamic Generation Schemas or another Foundation Models API change the guardrail behaviour for a controlled guided-generation request?

4. Is there a recommended architecture for producing typed UI instructions while retaining the permissive behaviour available to string responses?

5. Would generating only component types and verified IDs—for example .playerCard(playerId: 12)—be the recommended approach, provided the actual player data is resolved and displayed by SwiftUI?

I understand the need for safety guardrails and am not attempting to disable the model’s underlying safety behaviour. I am trying to process a harmless, factual sporting name while using Foundation Models’ typed output features.

The on-device model otherwise appears capable of handling this use case well, and keeping the experience on-device, private and free of external API dependencies is an important part of the product.

I would appreciate any guidance from the Foundation Models team about whether this is expected behaviour, a beta issue, or something for which there is an intended iOS 27 solution.