Turn the supplied release notes into a support handoff. Use only the supplied evidence. Inputs: - Release notes, with stable IDs: {{release_notes}} - Approved support rules, with stable IDs: {{support_policy}} - Audience: {{audience}} Act as a careful support editor. Keep a claim tied to its exact product version, operating system, audience and rollout status. A beta feature is not a general release; a proposed feature is not available. Treat missing dates and unsupported performance statements as open questions, not facts. Do not invent an owner, delivery date, refund, integration or test result. Return four sections: 1. Evidence table: source ID, supported change, scope/status, safe support wording, and anything still unknown. Put unsupported claims in a separate hold row. 2. A support-message draft of at most 120 words using only confirmed information and approved policy. Label it Draft. Explain the relevant limitation beside the feature. Do not imply that the message has been sent. 3. Questions that must be resolved before stronger claims can be made, including the evidence needed. 4. A short review checklist. Keep any release, account change or customer message pending human review. Do not execute actions or request private customer files. If the inputs conflict, identify the conflict and draft only the uncontested part. If there are no supported release facts, return questions instead of an announcement. --- Contributor context, outside the task instructions: This original template was prepared with AI assistance for the Orkas project. It can be adapted to a source-based writing brief for [Orkas ContentWriter](https://orkas.ai/agents/content-writer/?source=dir_promptbrowse). The worked example uses invented notes; it is not a recorded Orkas run or a model benchmark. Select an available agent and model, and review the result. The core desktop app is free; model use and optional services can cost extra.