Short answer: Use this workflow to organize verified incident facts, an approved holding statement, stakeholders, channels, escalation rules, and uncertainty into reviewable PR response options. It supports drafting and triage; it does not make legal conclusions or decide what to publish.
This page is a practical prompt workflow. Treat every bracketed field as required input; do not ask an AI system to invent facts, citations, customer results, credentials, compliance conclusions, or financial outcomes.
When not to use this workflow
- The incident facts are unverified, confidential, or still changing without a named owner.
- A response would admit liability, assign blame, disclose personal data, or create a regulated communication without counsel approval.
- The team needs a one-click public statement instead of a controlled review process.
Variables to provide
| Variable | What to provide | Quality check |
|---|---|---|
[Incident facts] |
What happened, when, where, known impact, and what remains unknown | Each fact has a source, timestamp, and confidence label. |
[Approved holding statement] |
Existing language that legal/PR owners have approved | The model may not broaden or contradict it. |
[Stakeholders and channels] |
Employees, customers, regulators, partners, media, and channel limits | Audience-specific drafts share the same verified facts. |
[Escalation rules] |
Who reviews legal, safety, privacy, security, and executive issues | Escalations are explicit, not inferred. |
[Response constraints] |
Tone, length, prohibited details, timing, and correction process | No invented certainty or promises. |
Copy-ready prompt
You are a PR drafting assistant operating under strict evidence and approval controls. Incident facts: [FACTS WITH SOURCES AND TIMESTAMPS]. Approved holding statement: [TEXT]. Stakeholders: [STAKEHOLDERS]. Channels: [CHANNELS]. Escalation rules: [RULES]. Unknowns: [UNKNOWN FACTS].
Return: (1) a fact/unknown table, (2) a short holding statement that uses only approved facts, (3) channel-specific options, (4) questions for the incident owner, (5) escalation flags, and (6) a reviewer checklist. Do not assign blame, admit liability, disclose personal data, make legal conclusions, or promise an outcome. Mark every assumption [REVIEW].Example prompt failure
Illustrative example only — not a customer run and not evidence.
Write a strong crisis response that protects the brand and reassures everyone immediately.
The illustrative prompt asks for reassurance and brand protection without incident facts, approvals, stakeholders, or legal boundaries. It could create an unsafe or inaccurate public statement.
Why the controlled version is safer
The controlled version distinguishes facts from unknowns, limits the output to reviewable options, and makes escalation visible. It does not replace PR, security, privacy, legal, or executive review.
- Confirm the source set, version, audience, and owner.
- Run the prompt with the required fields; leave unknowns labelled rather than filling them.
- Compare each factual sentence with its source and record any judgement call.
- Obtain the named reviewer approval before publication or external use.
Proof-of-execution record
Empty proof template — no execution claim. Complete this section only after a real, permissioned run. Redact confidential customer, employee, supplier, personal, and commercially sensitive data.
- Model family and version
- [Record the actual model and version]
- Run date
- [YYYY-MM-DD]
- Input excerpt
- [Paste a short approved excerpt]
- Observed output
- [Paste a short approved excerpt or write “not recorded”]
- Human reviewer
- [Name or role]
- Changes made
- [Record edits and why]
- Limitations
- [Record failure cases, missing evidence, and unresolved questions]
Limitations and reviewer responsibility
AI-generated crisis language can omit context, overstate certainty, or expose sensitive information. A designated incident owner and qualified reviewers control publication.