Rolling over event briefs is how last year becomes this year silently

On 4 September somebody creates the 2027 brief by clicking roll over from 2026. It takes about a second and produces a complete thirteen section document with no empty fields, no warnings and no visual difference from a brief a team spent three weeks writing.

That last property is the problem, and it is worth stating carefully because rolling over event briefs is a genuinely good idea being implemented in a way that destroys the information a reviewer needs.

What a roll over actually does

Three things happen at once and only one of them is intended.

It copies the text, which is the point, and which saves a team perhaps two hours of retyping venue details, hall numbers, legal mandatories and prior performance figures.

It transfers the apparent status of that text. A section that was reviewed, argued over and signed in 2026 arrives in 2027 wearing the same completed appearance it earned last year, having earned nothing this year.

And it erases the distinction between the two categories of section. In the source document, the venue address and the positioning statement were different kinds of thing: one a fact anybody could verify, the other a choice somebody made under conditions that have since changed. After the copy they are identical rows in a database, both populated, both looking equally settled. The reasoning behind treating them differently sits with the decision and description split, and a roll over that ignores it flattens the whole distinction in one action.

The empty section that renders as a decision

The worst case is subtler than stale text, and it is the one worth checking for first.

Suppose the 2026 brief had an empty non goals section, because the team ran out of time. The roll over copies an empty section into 2027. The template, being helpful, renders an empty non goals section as "None specified".

A reader in 2027 sees a section with content in it. "None specified" reads as a decision: the team considered non goals and concluded there were none. What actually happened is that nobody filled a box eighteen months ago. The rendering layer converted an absence into an assertion, and the assertion then survives review because there is nothing in it to disagree with.

I have seen the same failure in reporting systems, where a missing figure displays as zero and a zero is a number people act on. The rule is the same in both places: a system should be able to say it does not know. A template that has no way of expressing "this was never answered" will express it as something else, and whatever it picks will be read as a claim.

The check takes ten minutes and is worth running before anything else here. Open the brief you rolled over most recently and look for every section whose content is a placeholder: "None specified", "To be confirmed", "As previous", a single hyphen, or a heading with nothing under it. Count them. In a thirteen section template, three or four is normal. Then ask, for each, whether a reader outside the team would understand that as an absence or as an answer.

How long does a stale field take to surface?

Longer than you would guess, and the cost of a stale field scales with the delay, so this is the number worth measuring.

Follow one rolled brief through a cycle. The roll over happens on 4 September. Three inherited items turn out to be wrong, and each surfaces at a different point.

The first is a sponsor tier that was retired in the spring. It surfaces on 15 October, 41 days later, when a salesperson tries to sell it. Cost: an awkward call and an hour of somebody's time.

The second is an audience descriptor naming a segment the portfolio stopped targeting. It surfaces on 11 November, 68 days later, at the media planning stage, after two weeks of planning work built on it. Cost: rebuilding a plan.

The third is a claim about the number of countries represented, inherited unchanged for three editions. It surfaces on 9 December, 96 days later, when an exhibitor queries it in writing. Cost: a correction notice and a conversation about whether anything else in the marketing is wrong.

Mean detection latency across the three is 68 days. The pattern generalises: inherited errors surface at the moment somebody has to act on them, which is exactly when the work built on top of them is most expensive to unwind. A re affirmation step at the start would have caught all three on 4 September at a cost of about twenty minutes.

What the clinical safety work found about copied text

Health records ran into this problem a decade before event teams did, at higher stakes and with more scrutiny, and the conclusions are directly usable.

The ECRI Institute Partnership for Health IT Patient Safety published safe practice recommendations for copy and paste in February 2016. Four recommendations, and the first two are the ones that matter here: provide a mechanism to make copy and paste material easily identifiable, and ensure that the provenance of copied material is readily available, meaning the source, the author, and the date it was copied from.

Tsou and colleagues published the supporting systematic review in Applied Clinical Informatics in 2017, drawing on 51 publications. Their finding is more honest than the recommendations alone suggest: copying is common, and the evidence that it causes harm is thinner than the strength of opinion about it. What copying reliably does is make the record harder to read and harder to attribute, and the harm follows from that rather than from the copy itself.

Read across to a brief and the conclusion is the same. Rolling over is not the defect. Rolling over invisibly is. A team that copies thirteen sections and labels all thirteen as copied, with the date and the source edition, has lost nothing and gained a reviewer who can see what needs attention.

Shipping a roll over as unconfirmed

The mechanism is small. Every field carries a confirmation state alongside its value, and a roll over sets that state to unconfirmed for every field it copies.

Unconfirmed fields render differently. Greyed text, a marker in the margin, the source edition and date shown beside the value. They are readable, so the team gets the continuity benefit, and they are visibly provisional, so nobody mistakes them for this year's work.

Confirming a field is one action by a named person, and it stores that person and a timestamp. Approval of the brief requires every decision field to be confirmed this cycle. Description fields can be confirmed in bulk, since checking that the venue address is still the venue address is a glance rather than a judgement.

Time cost: thirteen sections, of which eight are descriptions confirmed in one action and five are decisions needing thought. Call it ninety seconds each for the five and two minutes for the bulk confirm, so under ten minutes for the whole brief. Against a mean detection latency of 68 days on the errors it catches, that is the cheapest control in the production process.

Holding a confirmation state per field is beyond what a document can do, which is the practical reason briefs migrate into a brief and review workspace at portfolio scale. A word processor has one status for the whole file.

Does re affirmation just become another rubber stamp?

Partly, and pretending otherwise would be dishonest. A team under deadline will bulk confirm things it should have read.

Two design choices change how much of that happens. The first is keeping bulk confirmation available for descriptions and unavailable for decisions, so the only fields requiring individual attention are the five that deserve it. A control that demands attention everywhere gets ignored everywhere.

The second is showing the age of the inherited value. "Positioning, unchanged since the 2024 edition, confirmed by three people since" is a considerably more uncomfortable thing to click past than an undated grey box, and the discomfort is doing useful work. Fields that have survived several editions untouched are the ones most likely to be wrong and least likely to be read, since each previous confirmation makes the next one feel safer.

Even with both, some confirmations will be reflexive. That is the general property of any field that arrives with an answer in it, worked through in the default effect on prefilled fields, and a confirmation step reduces it rather than removing it. The gain is that a reflexive confirmation is at least attributable, so when the sponsor tier turns out to be retired there is a name and a date attached to the moment somebody said it was current, which is what field level provenance is for.

Where this stops

Confirmation states record that somebody looked. They cannot record that somebody thought.

A reviewer who confirms the positioning field in four seconds has produced the same database row as one who spent ten minutes on it, and no amount of interface design distinguishes them. What you get is a name and a time, which is enough to have a conversation later and not enough to prevent the error now.

There is also a limit around who can confirm. Bulk confirming eight description fields is safe only if the person doing it has access to the underlying facts, and a coordinator confirming that the hall allocation is unchanged is confirming something they have no way to check. Either the facts get pulled from the system that owns them, or the confirmation is theatre performed by whoever is available.

Take the brief you most recently rolled over and pick the three fields you would be most embarrassed to find were wrong. Search the edition history for the last time each was actually edited. Anything that has survived two roll overs untouched is where to start.