A decisions register gives you one place to see what was agreed, who must act, and what proof is still missing. Use these prompts if you coordinate delivery across teams and need to chase work without reopening every meeting note and chat thread.
Key point
Record the proof, not just the promise
A decision is not ready to close because somebody says it is progressing. Record the evidence that confirms it.
1. Start with the right source set
Choose the prompt based on the state of the work:
| If you have | Use | What you get |
|---|---|---|
| One fresh meeting record | Create a register from one meeting | A first register and a list of gaps |
| Several sources that overlap | Merge decisions across sources | One current view, duplicates and conflicts shown separately |
| A register plus this week's updates | Update the weekly chase list | Revised rows and a prioritised list of contacts |
| A register you do not trust | Audit a register before escalation | Supported corrections and precise escalation questions |
Paste the source text in date order where you can. Label each item with its meeting date, chat date, or document version. A short chat update such as “approved” is not useful unless the prompt can see what was approved and by whom.
If the bundle is too large to review reliably in one pass, split it by workstream or reporting period. Behaviour with large source bundles is version-dependent, so check the current guidance in the xAI documentation overview before setting your process.
Watch out
Do not combine unlike decisions
“The team discussed a new launch date” and “The sponsor approved 15 October” are different records. The first may be an unresolved point. The second is a decision.
2. Keep the register fields consistent
Use the same meaning for each field each week. This stops the register becoming a list of vague status statements.
- Decision or required decision: write the outcome, not the conversation topic. Use “Approve supplier onboarding route” rather than “Supplier onboarding”.
- Owner: name the accountable person or team. A meeting chair is not automatically the owner.
- Due date: record the decision deadline or delivery date, not the date somebody mentioned it.
- Dependency: name the thing that must happen first, such as security review approval or a confirmed staffing allocation.
- Evidence needed: specify what closes the item. Examples include an approved change request, published report, test sign-off, or written confirmation in the project channel.
- Unresolved point: state the missing fact or conflict in one sentence. Do not hide it in the next action.
The prompts use Not stated and Unassigned deliberately. They make missing information visible to the person who can fix it. Replacing either with a likely answer makes the register look healthier than it is.
3. Review the register before you send chasers
Read every High priority row and every row marked Blocked. Check the source reference or quoted evidence before you contact someone. Then make sure the chase asks for one concrete outcome: confirmation of an owner, a date, an approval, or the named evidence.
Check
A useful chase can be answered
If your chase says “Any update?”, rewrite it. Ask for the missing decision, date, named owner, or evidence item instead.
Look for these common errors before distribution:
| What you see | Why it is wrong | What to do |
|---|---|---|
| A row has an owner but no source assignment | The owner may be an assumption | Set the owner to Unassigned and ask for confirmation |
| A row is marked complete with no proof | Progress has been mistaken for closure | Change it to Pending and request the listed evidence |
| Two rows describe the same approval | Chasers may go to different people | Merge them and retain both source references |
| A deadline says “Friday” | It cannot be checked later | Convert it only if the source date makes it certain, otherwise ask |
| A chat message contradicts the meeting note | The current position is unclear | Put the conflict in Unresolved point and escalate it |
4. Use the output in the delivery rhythm
After each decision-making meeting, create or update the register on the same day. Before the weekly delivery review, run the update prompt with new notes, chat updates and reports. Send the resulting chase list to the people named in it, rather than forwarding the entire register.
Keep the full register as the working record. Use the escalation brief only for issues that need a decision from a sponsor, programme lead, or accountable team. This separates ordinary follow-through from problems that require authority.
Note
Keep source references short but traceable
A meeting date plus speaker name, a chat date plus channel, or a document section is usually enough for someone to verify the row quickly.
5. When the output does not work
Do not repair a weak result by guessing. First check whether the source text contains the missing fact. If it does, paste the relevant excerpt again with its date and use the audit prompt. If it does not, leave the field unresolved and ask the named meeting owner or delivery lead.
If the register produces too many rows, ask whether it is recording actions rather than decisions. Actions belong in a delivery plan unless they prove, enable, or resolve a decision. If it produces too few rows, check for decisions stated in chat replies, document comments, and meeting follow-ups that were not included in the source bundle.