LearnGrokYou need a decision that another person can read under pressure: rollback, mitigate while live, or keep monitoring. These prompts help release managers and engineering leads turn scattered deployment evidence into a short, checkable brief.
Do not begin with the final recommendation. First make the evidence comparable, then establish user impact and rollback risk. The model you are using can organise what you provide, but it cannot see your dashboards, deployment controls or live traffic unless you paste the relevant records.
Key point
Make the evidence traceable
A recommendation is only useful when each important claim points to a timestamped metric, error report, user report or change record.
1. Build one evidence record
Start with Deployment evidence register. Paste the deployment record, the metric export, alert content and error groups. Include a stable period before the deployment where you have one. Do not paste a chart image without the underlying values and timestamps.
This prompt gives you three things that are often missing from an incident channel:
- A single deployment time window.
- A distinction between a measured signal and an interpretation.
- A list of missing or contradictory evidence.
Use the register as the source document for the later prompts. If a dashboard reports percentages but a log report supplies counts, retain both. They answer different questions. A percentage may show a broad service change. A count may show whether a particular error group is growing.
Watch out
Do not use an average alone
A stable average can conceal a short period of complete failure, or a problem isolated to one region, tenant or endpoint. Keep the timestamps and segments.
2. Establish user impact separately
Run User impact assessment after the evidence register. Technical errors and user harm are related, but they are not interchangeable. A background worker can fail without affecting a core journey. Conversely, a small error group can block sign-in for a high-value user segment.
Paste support evidence, synthetic checks and product measures alongside the register. State which journeys are known to be unaffected. That comparison stops the brief from treating an untested journey as healthy.
Use the assessment when the decision hinges on scope. A rising error rate with no evidenced user impact may justify monitoring or a narrow mitigation. A confirmed failure in a core journey may justify a faster action even when the aggregate error rate looks modest.
Check
Look for an evidence chain
For every claimed user impact, you should be able to follow the chain from user journey to observed failure, timestamp and source. If a link is missing, the output should say so.
3. Test the change before you revert it
Run Recent change risk review with the deployed change list, relevant diff excerpts, configuration changes and migration details. This does not prove causation. It tests whether there is a plausible mechanism and whether rollback could make the situation worse.
Pay particular attention to changes that are not undone by reverting application code:
- Database migrations and data writes.
- Feature flags changed separately from the deployment.
- Queue consumers, retry settings and message formats.
- Cache keys, configuration values and dependency changes.
- Compatibility between newly written data and the previous application behaviour.
The review should label time correlation as time correlation. Do not promote it to a confirmed cause because the error began soon after deployment. That is a useful lead, not proof.
4. Produce the decision brief
Use Rollback decision brief when you have the three supporting documents. It imposes a fixed structure and a word limit, so the reader sees the action, reasons, risks and decision triggers without reading an incident transcript.
Choose the primary action from the three specified options. A mitigation can be a feature flag change, traffic reduction or a narrowly scoped configuration adjustment, but only include an action if the supplied material supports it. Name an owner role and a success signal for each next step.
The brief is also the record of uncertainty. Include gaps that could change the action, such as an unknown migration state or missing regional metrics. A short statement of what you do not know is more useful than a confident claim built from incomplete evidence.
For version-dependent platform behaviour, check the current xAI documentation overview before relying on a workflow feature or output format.
5. Challenge the brief before approval
Run Decision brief challenge review if the action is high risk, the evidence is incomplete, or a senior approver was not involved in the initial analysis. Paste any new metrics since the first brief. A recommendation can become stale quickly when errors are rising, mitigation is taking effect, or traffic patterns change.
Use the challenge output to revise the original brief, not to create two competing decisions. If it finds a material contradiction, update the evidence register and rerun the decision brief.
| If you see this | Do this | Do not conclude |
|---|---|---|
| Error increase without user-journey evidence | Run user impact assessment | Users are unaffected |
| New error starts after deployment | Run change risk review | The deployment caused it |
| Rollback appears simple | Check migrations, flags and data writes | Reverting code restores all state |
| Metrics improve after mitigation | Compare against baseline and segments | The incident is resolved everywhere |
Check the result before acting
A weak brief usually has one of four faults: no timestamps, no baseline, vague user impact, or a recommendation with no reversal risk. Search the output for words such as confirmed and likely. Each should have nearby evidence. Check that the action plan contains an owner role, an observable success signal and a stop condition.
Also check whether the selected action matches the stated uncertainty. If the brief says the rollback procedure is unverified, it must not present rollback as risk-free. If user impact is unknown, it must not describe a broad outage as fact.
Stop
Do not treat the brief as deployment control
The brief supports the accountable release decision. Follow your approved change, incident and rollback procedures when applying the action.
When the prompts do not work
If the output is generic, add the missing raw material rather than asking for stronger wording. Supply timestamps, metric units, the pre-deployment comparison, the exact error signature and the affected endpoint or journey. If sources conflict, preserve the conflict and ask the relevant owner to verify it.
If the recommendation remains unclear, use the decision triggers as the next investigation plan. Set a short review point, collect the named missing evidence, then rerun the evidence register and decision brief with the updated record.
