Brief field provenance and why every answer needs an author and a date

In February somebody queries the success measure in the signed brief. It reads 1,400 pre registered buyers from the retrofit segment, and the campaign is tracking at less than half of it with six weeks to go. The obvious question in the room is where 1,400 came from. Nobody can answer it, because brief field provenance is exactly what this document lacks: no author on the value, no date, and no record of how it got there.

Four people are present. None of them wrote it. The show director thinks it came out of the October planning session. The marketing lead thinks it was derived from last year's number plus a growth assumption. The coordinator who typed it into the field left the business in November. Twenty two minutes of searching the email archive produces a thread that mentions 1,400 without attributing it, and the meeting moves on to what to do, having failed to establish the one thing that would have told them whether the target was ever realistic.

Brief field provenance is the answer to that failure, and it is a smaller piece of engineering than it sounds.

Ten fields, and who wrote them

Run the test before building anything. Take a brief that has been signed, pick ten fields, and try to name the author of each with enough confidence to say it out loud in a meeting.

On the brief in the example above the result was three nameable, two guessed, five unknown. The two guesses were checked afterwards against the edit history and both were wrong, which is the finding worth sitting with: people are confident about authorship and they are confident incorrectly, because they remember who talked about a topic rather than who typed the value.

Five unknown out of ten, on a document that carries four approval signatures. Every one of those approvals attests to the document as a whole and none of them attests to a single field inside it. That gap is the thing provenance closes.

What provenance means precisely

Worth taking the definition from people who wrote one down. The W3C published its provenance data model as a Recommendation on 30 April 2013, defining provenance as information about entities, activities and people involved in producing a piece of data or a thing, which can be used to form assessments about its quality, reliability or trustworthiness.

Three core types carry the model. An entity is the thing itself, here a field value. An activity is what happened over time to produce it, here a typing session, a roll over or a generation call. An agent is whoever bears responsibility, here a person or a system acting on somebody's behalf.

Map that onto a brief and the record per field is four columns wide: the value, the agent, the activity, and the timestamp. Add a fifth for the source where the activity was a copy, naming the edition and field it came from.

That is the whole schema. It is smaller than most teams expect, and the reason it does not exist in most brief tooling is that documents have no natural place to put it, so the information is discarded at the moment it is cheapest to capture.

The three origins a value can have

Collapse the activity column to three values and it becomes usable by people rather than by auditors.

Typed. A human wrote this into the field during this cycle. Carries the author's name and the date. This is the only origin that represents a decision made for this edition.

Inherited. Copied from a previous edition. Carries the source edition and the date of the copy, plus the original author where the chain survives. Most values in most briefs are this, and almost none of them are labelled, which is the roll over problem in its most concrete form.

Generated. Produced by a model from a prompt and some context. Carries the model, the date, and whoever ran it. This category did not exist five years ago and it now accounts for a growing share of first drafts, and it is the origin where labelling matters most, because generated prose is fluent and fluency is read as confidence by every reviewer who has not been told otherwise.

Rendering the origin beside the value costs about a centimetre of screen width and changes reviewing behaviour immediately. A reviewer who can see that the audience description is inherited from 2024 and has never been typed reads it differently from one looking at the same sentence in isolation. That is the entire mechanism, and it works because it gives attention somewhere to go, unlike the general instruction to read carefully.

Why does an author matter more than an approver?

Because you can go back to an author and ask why.

An approver tells you somebody thought the document was acceptable. That is a weak signal, since approving is a single act covering forty one fields, and the reasoning behind it is not recoverable from the record. An author tells you who held the pen on this specific claim, which means there is a person who once had a reason, and reasons can be interrogated.

The February meeting above needed one thing: somebody who could say the 1,400 came from taking last year's 1,180 and applying the 18 per cent growth the board asked for, or alternatively that it came from a bottom up estimate of the retrofit market. Those two origins imply completely different responses, and neither the document nor the approval chain could distinguish them.

There is also an accountability effect that shows up quickly and is worth naming honestly. Values written by somebody who knows their name will be attached get written more carefully. That cuts both ways, since it also makes people reluctant to put a number in a field at all, and a team that responds to provenance by writing vaguer targets has traded one problem for a worse one. The counter is to make the activity visible without making it punitive, which is a management choice rather than a schema choice.

What code review settled that document review has not

Software teams solved this a long time ago and their solution is worth borrowing, because the scale is convincing.

Sadowski and colleagues at Google published a study of modern code review at the software engineering in practice track of ICSE in 2018, built from 12 interviews, a survey of 44 respondents and review logs covering 9 million reviewed changes. The detail that matters here is structural rather than any single finding. In that system every change carries an author, a timestamp and a reviewer as a matter of course, so the question "who wrote this line and when" is always answerable at no cost to anybody, and the entire review culture is built on top of that being free.

Document review in event teams has the opposite default. Authorship is discarded, timestamps apply to the file rather than to the content, and reconstructing who wrote a sentence takes twenty minutes of archaeology, so nobody does it, so the question stops being asked, so the culture never develops.

The clinical world reached the same conclusion from the safety side. The ECRI Institute Partnership for Health IT Patient Safety, in its 2016 safe practice recommendations for copy and paste, requires that the provenance of copied material be readily available, meaning the source, the author, the time and the date. Two very different fields, both concluding that attribution has to be free at the point of reading or it will not happen.

How much provenance is too much?

There is a real answer and it is lower than an engineer's instinct.

Store the full history. Show almost none of it. A reviewer needs three facts at a glance: origin, author and age. Everything else, including the previous values, the intermediate edits and the chain back through four editions, belongs behind a click.

The failure mode of over displaying is a brief that looks like a version control interface, and event teams will not use it. I would rather have three fields of provenance shown for every value than a complete audit trail nobody opens, and if you can only build one of the two, build the display before the archive.

There is a second question about granularity. Per field is right. Per sentence is over engineering that produces a mess of markers inside a paragraph. Per section is too coarse, because a section is where the mixing happens: a positioning section can hold one inherited sentence and one typed one, and a section level marker will describe it as whichever the system saw last.

A brief and review workspace of the kind described on the publishing engine page is where this has to live, since capturing the activity requires being present at the moment the value is written. Nothing reconstructs provenance afterwards from a finished document.

Where this stops

Provenance records who wrote a value. It says nothing at all about whether the value is any good.

A field can carry a perfect record, typed by the show director on 4 October at 14:22, and hold a number she invented in the moment because the meeting needed one. The provenance will be accurate and complete and the target will still be arbitrary. What you gain is the ability to ask her, which is more than most teams have, and considerably less than knowing.

The second limit is inherited chains that break. When a value is copied from an edition whose own provenance was never captured, the record says inherited from 2024 and stops there. Building the chain backwards is impossible, so an organisation starting this today gets one useful generation of history and inherits a permanent blank behind it. That is an argument for starting now rather than an argument against starting, and it also means the first year of provenance data will look disappointing.

The last one is that provenance and authority are different things. Knowing who typed the positioning statement does not tell you whether they had the standing to decide it, and a brief where the coordinator typed a decision the show director made verbally will attribute it to the coordinator, accurately and misleadingly. Closing that gap needs the rule that decisions have one home, and it also needs the field to distinguish typing from deciding, which is a further column and a harder conversation.

Pick ten fields in your most recently signed brief this week and write down who you think wrote each one. Then check. The count you get wrong, plus the count you cannot guess at all, is the size of the gap, and in most teams it is more than half. What that half has in common with fields nobody edited is worth looking at too.