The brief

A brief is everything collected from the client at the start. Not a summary — brief here means the dossier, not the length.

It decides nothing.

The briefing is not yours to sequence — writing it down is

The client briefs you when they brief you: a meeting, a document, a corridor conversation, a demonstration that changes direction. That always comes first, and you do not control it.

What you control is whether it gets written down before you start specifying. That is the step people skip, because the briefing feels like it already happened — and it did. It happened into a meeting note, a slide deck, a project tracker and four people's memory.

Three failures follow, and they are the three this artefact exists to prevent:

• You cannot tell what the client asked for from what you decided. A request to study something becomes a built feature, and months later nothing distinguishes it from a requirement.
• You cannot tell what is missing. With no consolidated picture of the client's own process, a step of theirs that your specification never implements goes unnoticed.
• Assumptions harden by repetition. A number nobody marked as assumed reads as a fact by its fourth appearance.

So the rule is not "brief before specification" — that is trivially true and not yours to arrange. It is: consolidate the briefing into a document before you specify from it.

Status

The brief answers why the product is what it is. It never says what the product must do. It is a versioned snapshot, and it becomes non-normative the moment a specification is accepted. State that inside the brief itself — see artefacts and authority.

What succeeds the brief

The brief is discovery input. Once its claims have been tested and the domain is approved, promote the stable picture into two authorities:

• the product reference owns actors, cross-module concepts, module boundaries, journeys and vocabulary;
• each module reference owns its domain detail and normative functional requirements.

Do not keep polishing the brief until it resembles either one. Its provenance is valuable precisely because it preserves what was learned before design decisions were made.

Provenance is metadata, not a section

Every factual item carries its source inline: source · date · who said it. A provenance section at the end — a list of documents consulted — becomes an unmaintained bibliography nobody updates. A short legend near the top, declaring the marks used throughout, is a different thing and is worth having.

[Workflow officiel]   a document the client handed over
[CR 16/06/2026]       a meeting record, dated
[FFK 07/2026]         our own decision — NOT a client request
[verified 02/08]      checked against a public source, with the date
[to confirm]          assumed, never confirmed

The marks that earn their keep are the last two. [FFK] is what lets you find, months later, that a whole feature came from an internal arbitration nobody asked for. [to confirm] is what stops an assumption hardening into a fact by repetition.

The nine blocks

1 — Purpose, measures, and what would make us stop

The driver, the policy intent behind it, how success is measured, and what would make the honest answer be don't build this.

Measures are where briefs are weakest. A project with no agreed measure of success is judged on the impression left by a demonstration. If the client has none, propose them and mark them unconfirmed — an unanswered table is louder than a silence.

2 — Actors, authority and outcomes

Two families, and do not force them into the same shape.

Those who do the work — users, operators. Each gets:

current behaviour → desired observable outcome → measure

Those who govern — sponsors, regulators, integrators, the client's IT department. Each gets their concern, obligation, or decision authority. Forcing a sponsor into a behaviour-change sentence is consultancy theatre.

Use one provisional name per person throughout the brief. When the product reference is accepted, its actor list becomes the controlled vocabulary for all modules. Do not let customer, requester and account holder become three names for one person.

Record who you did not meet. A brief written entirely from internal stakeholders describes an internal process, and its external journey is a guess.

3 — The current world

The end-to-end service as it works today: channels, hand-offs, delays, workarounds, and who is involved beyond the client. Not an inventory of systems — the journey.

Then, explicitly: what this description does not cover. Delays, exception paths, what happens to an incomplete case, who chases a stalled one, and the annual volume are the five things missing from almost every handover document.

4 — Scope boundaries

In · out · adjacent. Without stated non-goals, dependencies quietly become features.

Adjacent is the one people skip and the one that saves you: the neighbouring journeys that touch the product without belonging to it.

5 — Candidate responses

Not "what we build". Naming this block after the solution turns discovery into confirmation of something already assumed.

Every capability stays a hypothesis until it traces to an actor and an outcome from block 2. A capability tracing to nothing is either a missing outcome or a capability nobody needs.

Mark the origin of each. A client asking you to study something, answered by building it, is a common and expensive drift — and it is invisible unless this column exists.

6 — Constraints, obligations and dependencies

Legal and regulatory, imposed technology, hosting and data residency, language, accessibility, budget, deadline. Then what you depend on others to provide, and its state.

Mark which dependencies genuinely block design. Most do not, provided the values they carry are treated as administered data — which is what block 8 is for.

7 — Vocabulary

The client's own words, from the client's own documents, before anything is renamed.

Then, separately, the words you introduced that the client does not use. Each may be defensible; none is theirs. This list is the honest starting point of every later naming argument, and it is the difference between a considered rename and a drift nobody noticed.

8 — Volatility and invariants

Every number, list, threshold and name the client stated. This is the block that stops those values being carved into the specification.

The brief proposes an invariant; it never decrees one. A brief that writes "may never break" has started specifying, which is exactly what it forbids itself. The column is a question raised, and a second column says whether the client has answered it.

Where no invariant can honestly be proposed — because the client has not said whether the thing even exists — write that, rather than inventing one.

This does not duplicate block 6. A constraint records what was heard; this classifies its architectural volatility. And a value with no invariant is a hole — free prose here gets filled selectively and omits precisely the uncomfortable ones, which is why it is a table.

Close the block with what is not volatile and must never become so: who may read what, separation of duties, audit integrity, identity. See the configurability boundary.

9 — Open decisions, risks, and who settles them

Each with who decides, and since when. This block feeds the living open-questions document, which then owns them.

Run every candidate through the questions pass before writing it here. Most are configuration and belong in block 8 instead.

Then the risks — with what would reduce each. A risk without a mitigation is a complaint.

Versioning

A brief is a versioned snapshot, not a living document. Accepted before specification starts, and revised when what you know changes.

A revision records a change in what we learned, never a change in what we decided.

If the change is a decision, it belongs to the open questions or the specification. Without this rule the brief accretes decisions and becomes the shadow specification again.

Magnitude and cause are two different columns. Magnitude is the size of the change; cause is who produced it. You can learn something major without the client saying anything — discovering the client's organisation is not the shape you assumed is a major revision caused by you.

Carry a revision table with version · date · what we learned · magnitude · cause. Cause is client or us, and it is the column that tells a reader in a year whether the product moved because the client moved, or because you finally checked something.

Header block: Version · Status (Draft | Accepted | Superseded by x.y) · Date · Client · Supplier.

How this canvas fails

The completeness illusion. Nine boxes invite nine filled boxes. Teams copy workshop opinions into facts, promote requested features to commitments, and accumulate open questions nobody ever closes.

Three counters:

• an empty block with a stated reason beats a padded one — "no requester was ever met" is worth more than an invented persona;
• every open decision carries who decides, or it is not a decision, it is a worry;
• the brief is accepted and dated. An unaccepted brief is a working note, and calling it a brief lends it an authority nobody granted it.