A useful brief without sharing more information than needed

The original request: too many files, too little explanation

Imagine a company that needs to coordinate the preparation of sales proposals. Its first impulse is to share a folder of quotations, messages and customer documents. Anyone receiving it would have to reconstruct what happened, guess what concerns the team and distinguish an exception from the usual way of working.

The folder may contain names, prices, comments or terms that are unnecessary for understanding the difficulty. Yet it may omit something essential: who approves a change and how the next person learns about it. Before selecting files, write the question they should help answer. Here it is: why does a proposal return for review when it seemed ready?

The shareable version: a short journey with fictional data

The brief could describe an invented situation: someone requests Service A; the team prepares a proposal; a condition then changes and nobody recognizes which version should be reviewed. Keep the sequence, roles and point of uncertainty. Replace the customer’s identity and amounts with fictional values, explicitly labelled as such.

This example is not a real Wiwo case or a description of a contracted feature. It is discussion material. It makes the need understandable without attributing invented data to the business or providing access to original documents.

• Situation: a modification requires review of an already prepared proposal.
• People: the person receiving the request, the person preparing the response and the person confirming the terms.
• Difficulty: it is unclear which version should move forward.
• Question: what information does each person need to recognize and review a change?

What to retain so the example remains useful

Simplifying does not mean removing every difference. If a review depends on the type of service, retain that relationship. If a change must be discussed with someone else, explain when that person participates. An example that removes the source of the difficulty can look clear while no longer helping people understand the work.

You can accompany the journey with a blank template or a reviewed diagram. Explain what each field represents and what was omitted. If using a screenshot, also check messages, notes and secondary details. Removing a name does not establish that everything else is appropriate to share. When uncertain, a simpler fictional representation may be enough to begin.

Separate context, samples and access

Naming a tool helps explain where work happens; it does not require sharing a password. Describing the categories used can clarify a problem without supplying an entire database. Keep three things separate: describing context, showing an example and authorizing a review of information or systems.

Identify who can decide about each material. If a later evaluation needs additional information, ask what it contributes, who would use it and which authorization is required. Wiwo publishes principles of human control, permissions and testing in its AI safety plan. Their application to the project must be agreed alongside the review’s scope.

Check whether someone else understands the problem

Ask a colleague to read the brief and explain what happens, where work stops and what needs clarification. If they can only name a desired tool, the situation may be missing. If they need the customer’s identity to understand the journey, consider whether that identity matters or whether a relevant condition was left unexplained.

Date the material and identify what is current, what is fictional and what is only illustrative. This kind of brief gives Wiwo useful context for identifying questions about software, development or integration. The first conversation can focus on the difficulty and reserve other materials for when there is a specific reason to review them.