This playbook gives work-safe language for turning ambiguity into a small explicit contract.

Use it when work becomes unclear because ownership, evidence, decision rights, or next steps are being diluted across people, meetings, systems, or vague requests.

The goal is not to blame people.

The goal is to restore an accountable workflow:

  • clear request
  • clear evidence
  • clear owner
  • clear decision
  • clear next trigger

For the broader communication model, see the Stakeholder Communication Framework.

The Accountability Contract

Every meaningful work item should answer five questions.

Question Meaning
What is the request? The concrete thing being asked for.
Why does it matter? Business impact, risk, blocker, or dependency.
Who owns the next action? The named person or team responsible for the next move.
What evidence supports it? Logs, links, data, screenshots, notes, docs, decisions, or examples.
What is the trigger? Deadline, approval, next check-in, escalation point, or completion condition.

If one of these is missing, the work is vulnerable to ambiguity.

Response Pattern

Most responses follow the same structure:

1. Acknowledge the request.
2. Name the missing variable.
3. Propose a bounded next step.
4. Create a written trigger.

Unfiltered Upstream Directive

Use this when a manager or stakeholder passes down a broad instruction without enough context to execute safely.

Signals:

  • “Leadership wants us to look into this.”
  • “Can you just make this better?”
  • “We need to optimize the process.”
  • “Put something together.”

Risk: the executor absorbs the missing strategy, priority, and success criteria.

Priority Clarification

Thanks for sending this over. To make sure I prioritize correctly, my current top items are:

- [Priority 1]
- [Priority 2]

Should this new request take precedence over those, or should I slot it after them?

Success Criteria

I can pick this up. Before I start, I want to confirm the target outcome so we do not spend time solving the wrong problem.

What are the 2-3 success criteria expected here?

My current assumption is:

- [Assumption 1]
- [Assumption 2]
- [Assumption 3]

Bounded Interpretation

Since the scope is broad, here is my proposed interpretation for the first pass:

- [Scope item 1]
- [Scope item 2]
- [Scope item 3]

If this looks right, I will proceed with this scope. If there is a different priority, please correct it before [time/date].

Vague Handoff

Use this when work is passed between people or teams without explicit acceptance.

Signals:

  • “I dropped it in the folder.”
  • “Let me know if you need anything.”
  • “This is with the other team now.”
  • “We discussed it on the call.”

Risk: both sides believe the other side owns the next action.

Ownership Confirmation

To make sure this does not fall between teams, can we confirm the next owner?

My understanding:

- Current status: [status]
- Next action: [action]
- Owner: [person/team]
- Target date: [date]

Please confirm or correct.

Acceptance Trigger

Based on the evidence below, this appears to sit with [team/person]:

- Evidence: [link/log/example]
- Boundary: [system/process/contract]
- Impact: [affected records/users/process]

Can [team/person] confirm ownership of the next action by [date/time]?

Group Dilution

Use this when a decision is spread across a large group without a named decision owner.

Signals:

  • large CC lists
  • recurring alignment meetings without decisions
  • committees with no decision log
  • “no objections” treated as approval

Risk: silence becomes fake agreement and nobody owns the outcome.

Decision Owner

Can we pause and name the decision owner for this?

The decision appears to be:

- [decision needed]

The options I see are:

- Option A: [summary]
- Option B: [summary]
- Defer until: [date/condition]

Who owns the final call?

Explicit Approval

To avoid treating silence as approval, can we capture the decision explicitly?

Decision needed:

- [decision]

My proposed default is:

- [recommended option]

Please reply with approve, reject, or defer by [date/time].

Repeat Low-Context Help Requests

Use this when peers repeatedly ask for live help without showing prior effort, despite existing documentation.

Signals:

  • “Can we jump on a quick call?”
  • “Can you show me again?”
  • “I am stuck” with no error, draft, or screenshot
  • repeated questions already covered in the wiki

Risk: your time becomes the default support layer for avoidable issues.

Context Before Call

I cannot jump on a call right now, but we can probably handle it async.

Can you send:

- the exact error or behavior
- what you already tried
- the doc/wiki section you followed
- what result you expected vs what happened

Once I have that, I can point you to the right fix or doc update.

Wiki-First Response

This is covered in the wiki here: [link].

The relevant section is [section name]. Please try those steps first and reply in this thread with the exact step where the result differs from the doc.

Show Me The Draft

Happy to help you get unstuck.

Please share the current draft / query / screenshot / error first, and point me to the part that is blocking you. I can review from there.

Interactive Help Boundary

I will talk you through it so you can own the next one.

Can you share your screen and drive? I will guide from the doc and we can update the wiki if any step is missing.

Meeting Drift

Use this when a sync expands into live debugging, one-to-one coaching, or unfocused status reporting.

Signals:

  • daily standup turns into deep-dive debugging
  • many people listen while two people solve a narrow problem
  • decisions are discussed but not recorded
  • the same blockers return every meeting

Risk: group time is spent without creating durable decisions or next actions.

Move Deep Dive Offline

This sounds like a focused deep dive between [person/team] and [person/team].

To protect the broader group's time, can we take that part offline and come back with the outcome / next action?

Force Decision Shape

Can we pause and name the decision we need from this discussion?

I hear the options as:

- Option A: [summary]
- Option B: [summary]
- Defer until: [date/condition]

Who is the decision owner for this?

End With Triggers

Before we close, I want to confirm the action list:

- [Owner] will [action] by [date]
- [Owner] will [action] by [date]
- [Owner] will [action] by [date]

I will capture this in the notes unless anyone wants to correct it.

Throughput Problems

Use this when someone repeatedly communicates that they are busy, helping others, or blocked by competing priorities, but no meaningful deliverable reaches completion.

The useful distinction is activity vs verified output.

Signals:

  • many status updates, few completed artifacts
  • same task remains in progress across multiple days
  • blockers are vague or reported late
  • stakeholder side requests are not on the board
  • no PR, ticket update, document change, query result, or handoff

Ask For The Artifact

Can you link the current artifact for this?

I want to understand what changed today and what still needs to happen before handoff.

Convert Blocker Into Owner

To make the blocker actionable, can we capture:

- blocked item:
- blocking dependency:
- owner to resolve:
- decision needed:
- target time:

Without that, it is hard to tell whether this is blocked, deprioritized, or still in progress.

Force Priority Decision

[Name] mentioned they are currently helping with [Task B], which affects delivery of [Task A].

Can we confirm which item takes priority today?

- Option 1: [Task A] remains priority, [Task B] waits
- Option 2: [Task B] takes priority, [Task A] moves to [new date]

Once confirmed, I will update the board so the status is visible.

End-Of-Day Throughput Check

For EOD status, can we separate activity from output?

- completed artifact:
- still in progress:
- blocker:
- owner of blocker:
- next trigger:

This will make tomorrow's priority call easier.

Escalation Template

Use this when a request is blocked because ownership, decision, or priority remains unclear.

Current blocker: [short description]

What I know:

- [fact/evidence]
- [fact/evidence]
- [fact/evidence]

What is unclear:

- [missing owner / missing decision / missing acceptance criteria]

Recommended next step:

- [specific action]

Decision needed:

- [decision]

Owner needed:

- [person/team]

Target trigger:

- [date/time/event]

Daily Evidence Block

Use this in a daily note, issue update, or agent memory.

- Accountability trail
  - Request:
  - Evidence:
  - Owner:
  - Decision needed:
  - Next trigger:
  - Risk if unresolved:

Agent Reference

When using this playbook as agent context:

  1. Identify the missing variable: request, evidence, owner, decision, or trigger.
  2. Choose the shortest script that restores that variable.
  3. Keep the wording work-safe and non-personal.
  4. Prefer written context before live calls.
  5. Preserve an evidence trail.