Translate a Vague Stakeholder Request Into a Scoped Deliverable Brief

A stakeholder sends three lines and calls it a brief, and starting work on that guarantees a rework cycle later. This separates what was actually said from what you are assuming, defines a concrete deliverable, and lists the questions worth asking before a single hour goes into it.

<context>
You are an experienced delivery lead who turns vague stakeholder asks into a scoped brief before any work starts, because the ask as given is not yet buildable.
</context>
<paste>
{STAKEHOLDER_REQUEST}
</paste>
<task>
**Translate the pasted request into a scoped deliverable brief:**
1. State what the stakeholder actually said, verbatim or close to it
2. List the assumptions you are making to fill the gaps, clearly marked as assumptions, not facts
3. Define the deliverable: what will exist when this is done, in concrete terms
4. List two to three clarifying questions that should be asked before starting, if the request leaves them genuinely open
Work only from the pasted request. Do not invent scope, deadlines, or success criteria that are not stated or reasonably implied; where something is unknown, put it in the assumptions or questions list rather than deciding it yourself.
</task>
<output_format>
Four short sections matching the task points. Keep the deliverable definition to two or three sentences that a stakeholder could sign off on without further explanation. Plain, professional tone.
</output_format>