The brief is where real-world insight should enter the system

Most teams add real-world insight after the writing has begun. I am increasingly interested in what happens when you move it one step earlier.

A writer gets a brief.

The audience is defined. The key message is there. The questions the page should answer have been agreed. There may already be SEO or GEO recommendations, links to existing content, a format, a deadline and a reasonably clear sense of what the finished thing needs to do.

Then the writer starts researching.

Somewhere later in the process, somebody remembers there is a customer quote, an event transcript, a practitioner interview or a useful conversation that could make the page stronger. The evidence gets added to the draft. A quotation appears in the middle. A statistic gives the introduction more authority. A real example makes an otherwise generic section feel more grounded.

All useful.

But by then, most of the important editorial decisions have already been made.

The content team has already decided what the problem is, what the answer should broadly contain and which questions are worth asking. The evidence is being used to support the answer rather than to test whether the answer was framed properly in the first place.

I have been doing something slightly different recently.

I have been taking live briefs that are already part of an agreed content plan and comparing them with what I have heard from practitioners, customers, experts and people dealing with the subject in the real world.

Not to create another strategy. Not to turn every conversation into another article. Not to rewrite the whole brief.

Just to ask a much more useful question:

What have we learned from the real world that should change this brief before somebody writes it?

The intervention is often tiny.

I think the implications are larger.

A brief is a bundle of assumptions

A content brief can look completely sensible and still describe a cleaner version of the problem than the one people actually experience.

That is not necessarily a failure. Somebody has to create a first model of the subject. A good brief gives the writer direction, protects the reader from a sprawling article and creates alignment before production begins.

The problem is that the document can start to look more authoritative than the knowledge behind it.

A brief might say the reader needs to understand what information to keep, how a process works and what they need to do next. All of that may be correct. But when you talk to people actually going through the process, a different set of questions can appear.

Is my information complete enough to continue? What happens when something does not fit neatly? What am I expected to check myself? Where does somebody else need to get involved? How do I know I have actually finished the step I think I have finished?

Those are not necessarily new topics. They are often the operational reality hiding inside the original topic.

That distinction matters because a writer can answer the brief perfectly and still miss the part of the problem that makes the answer useful. This is one reason I increasingly think of a brief as a decision object, not merely a production document: it contains assumptions about what matters, and those assumptions should be allowed to change.

Evidence should be able to change the question

There is a difference between adding evidence to content and allowing evidence to change the content.

The first is familiar.

You have an argument, then you find a statistic that supports it. You have a section, then you find a customer quote that gives it texture. You have a claim, then an expert provides a line that makes it more credible.

The evidence strengthens something that already exists.

The second is more interesting.

You hear the same operational problem several times and realise the brief is asking the wrong question. A customer conversation exposes an assumption you did not know you were making. A practitioner explains that the difficulty sits somewhere different from where the content plan placed it. An expert gives an answer that makes one proposed section less important and another one essential.

Now the evidence is not decorating the content. It is doing editorial work. It can change the sequence, the emphasis, the promise, the level of reassurance, the claims that need qualification and the questions a writer needs to investigate. Sometimes it changes the output altogether.

The correct response to new insight may be to strengthen an existing page, use a video already sitting in the organisation, add one FAQ, change one sentence in a brief, commission a specific example or decide that no new content is needed.

That is a much more interesting use of insight than collecting quotes after the argument has already hardened.

The writer should not have to rescue the brief

I have spent most of my career writing, so there is an obvious objection to this idea.

Isn’t discovering the real problem part of the writer’s job?

Yes. It should remain part of the writer’s job.

A brief that removes every decision from the writer is not a better brief. It is a script. Over-briefing can be as damaging as under-briefing because the writer stops investigating and starts assembling.

I am not interested in that.

The point is not to resolve every ambiguity before the writer starts. It is to avoid knowingly passing weak assumptions downstream when the organisation already has evidence that could improve them.

A writer should still challenge the angle, find the contradiction, test the evidence and discover things the brief could not predict. That is part of authorship. I wrote recently that the AI draft is not the article, partly because the act of writing over a scaffold still contains judgement the scaffold cannot own.

But there is a difference between discovery and avoidable rework.

If customer conversations have already shown that people repeatedly misunderstand one stage of a process, the writer should not have to rediscover that from scratch. If an event has already exposed a practical problem that the original brief missed, there is little value in hiding it until the draft review.

A stronger brief does not tell the writer what to think.

It gives them a better problem to solve.

This is where real-world insight becomes infrastructure

I used to think of event notes, interview transcripts and customer conversations mainly as source material. I now think that undersells them. They can be inputs into the commissioning system.

An industry event does not have to produce an event article. A customer conversation does not have to produce a customer story. A practitioner interview does not have to end as a video asset.

The more useful question is what the organisation learned and where that learning should go next.

Sometimes it belongs in a published piece. Sometimes it belongs in a future interview question. Sometimes it belongs in a product conversation. Sometimes it should alter a brief that somebody else will write from weeks later.

That last route is easy to miss because the output is almost invisible. Nobody sees the insight moving into the brief; they only see the eventual page. But the writer received a better starting point because somebody connected a real-world signal to a live production decision. That is a form of editorial infrastructure.

It is also one of the reasons I keep coming back to the Evidence Engine. The value of an evidence system is not merely that it helps you find a quote faster. It is that evidence remains available early enough to change what the organisation decides to make.

Evidence needs a route, not just a repository

There is another step I have become more conscious of while doing this work. Once useful evidence exists, somebody still has to decide where it belongs. A transcript, clip or customer answer does not become valuable merely because it has been stored and tagged correctly.

I recently compared a practitioner interview with several live briefs. Three answers were potentially useful, but not in the same way. One clearly supported a reporting question already in the plan. Another could strengthen guidance about the quality and timeliness of underlying records. A third was useful evidence about workload and capacity, but for a different audience. The interview also touched on a year-end process without actually explaining it, so that apparently convenient route was rejected.

That changed how I think about reuse. The useful question is not “where else can we put this?” It is “what question is this evidence actually strong enough to answer?” Sometimes the answer is a live brief. Sometimes it is a future article, a social clip or a question worth asking again. Sometimes the answer is nowhere yet.

The practical pattern is:

brief requirement → source evidence → selected evidence → route / retain / reject

The rejection step matters because evidence systems can become asset-distribution systems surprisingly quickly. Once a useful clip exists, there is organisational pressure to use it. Editorial judgement has to be able to say that a good answer is still the wrong answer for this particular page.

I have explored the video side of this in Are you getting the GEO value from all that video?. The broader point is the same: evidence only becomes infrastructure when it can move into the right decision at the right time.

GEO makes the timing more important

This becomes more interesting in GEO work.

The simple version of GEO is easy to understand: identify the questions people are asking, find the pages that should answer them, improve the structure, make the answer easier for machines and people to retrieve, then measure whether visibility changes.

There is useful work in that.

But AI search also creates a new stream of editorial signals.

It can show where questions cluster, where an answer appears weak, where a brand is missing from a conversation or where the language people use is moving beyond the categories inside an existing content plan.

The tempting response is to turn each signal straight into production: prompt → page, question → article, gap → asset. I think that is too fast.

A search signal tells you there may be a question worth investigating. It does not automatically tell you whether the problem is weak content, missing evidence, product friction, customer confusion, an outdated assumption or simply something that does not deserve another page.

So the workflow I am testing looks more like this:

signal → existing answer → evidence check → real-world insight → brief decision → production

The important addition is the evidence check.

Before asking a writer to generate another answer, look at what the organisation already knows. Search the customer material. Read the transcripts. Look at the research. Talk to the people closest to the workflow. Check whether the original framing still survives.

I have argued before that the work happened before the prompt. This is the same principle applied one stage earlier in production.

The prompt is not the first input.

The brief is not either.

The useful intervention is usually smaller than you think

There is a danger here. Once you start talking about evidence systems, editorial intelligence and upstream decision-making, a simple content job can acquire an alarming amount of machinery. I do not want another 20-page artefact attached to every brief, writers waiting for an evidence committee before they can start, or every customer conversation classified against a giant taxonomy so that the organisation can claim it has a system.

The point is to reduce avoidable weakness, not create administrative intelligence. The practical test I am using is deliberately small:

What are people actually struggling with? What evidence do we already have? What does the current brief still fail to answer? What is the smallest change worth making?

Sometimes the answer is one new question, changing a line that sounds more confident than the evidence allows, or adding a piece of practitioner proof. Sometimes it is leaving the brief alone, and that final option matters.

If real-world insight does not materially change the problem, the content or the evidence requirement, it does not need to be forced into the document simply because somebody collected it.

Editorial judgement includes knowing when not to add.

This is useful for writers because it preserves their time for the hard part

The best argument for doing this upstream is not process efficiency.

It is what it allows the writer to spend time on.

A weak brief pushes basic problem discovery into the draft. The writer starts trying to answer the question and discovers halfway through that the framing is too neat, the evidence is thin or the operational reality sits somewhere else. They go back, broaden the research and rebuild the piece.

Sometimes that is exactly how good writing happens. But sometimes the organisation already knew. The knowledge was sitting in an event transcript, a customer conversation, a subject-matter expert’s notes or a previous piece of work that nobody connected to the brief.

That is not creative discovery. It is organisational forgetting.

When the relevant insight enters earlier, the writer can spend more time on the things that actually require authorship: testing the argument, finding the right evidence, deciding what matters, making the complicated thing understandable, challenging what the organisation thinks it knows and writing something another person would choose to keep reading.

That is where I want writers spending their judgement.

Not repeatedly rediscovering context the organisation already paid to acquire.

AI makes the draft cheaper. That makes the brief more consequential

This may be the biggest reason the timing matters now.

A few years ago, drafting itself was expensive. A weak brief created waste, but the pace of production limited how quickly that weakness could scale.

AI changes that.

A mediocre brief can now become a polished-looking draft in minutes. The output can be fluent, structured and complete enough to make the original assumptions harder to notice.

That is why I keep returning to the argument in The words were never the whole value: as production becomes cheaper, the value moves towards the decisions that determine what gets produced.

The draft is no longer the earliest place to intervene.

The useful editorial work may happen before there is any prose to edit.

Which question are we answering? Why this one? What evidence do we already have? What did the real world complicate? Which assumption in the brief no longer holds? What should the writer be free to discover, and what should we already have learned?

Those are commissioning questions.

They are also increasingly AI questions, because systems that can produce answers very quickly put more pressure on the quality of the question and the evidence surrounding it.

The brief is where insight can still change the system cheaply

I am not arguing that every brief needs a reporting phase. Most do not. I am arguing that when an organisation already has real-world insight, it should reach the work before the answer becomes expensive to change. That is the part I am testing now.

Take a live plan. Find the few briefs where field evidence genuinely matters. Compare the clean version of the problem with the messy one people actually describe. Make the smallest useful change. Then hand the writer a better starting point.

It is not glamorous work, and often the final intervention is barely visible. But I think this is one of the places editorial work becomes more valuable as production gets easier.

The writer still writes. The editor still edits. AI still helps. The difference is that the organisation gets better at learning before it starts producing.

Sometimes the most valuable editorial work is not improving the answer. It is changing the question before anybody starts answering it.