Put a follow-up date on every announcement

The responsibility after publication

Every announcement we cover should carry a follow-up date. The date can refer to an expected decision, the next scheduled report or a point at which an editor should check the record again. A reader deserves a way to return to a claim after the attention surrounding its launch has passed. My position is simple: the job of publishing an announcement includes identifying a sensible moment to ask what happened next. A neat account on the day of release leaves that responsibility unfinished.

A calendar will not rescue a weakly sourced article. The factual account still needs a source, a period and a clear description of the claim. Follow-up adds another piece: an expectation that the claim can be revisited. Without it, a launch, a public programme and a numerical report can all disappear into the archive through the same process. Each receives an opening account and a permanent URL, while its subsequent record is left for a determined reader to reconstruct.

Keep the clocks separate

I would start with three clocks. The event clock records when an activity happened. The source clock records when an organisation published its account. The editorial clock records when this website prepared or revised its article. A follow-up date belongs to a fourth clock: the next opportunity to check a relevant development. Combining those dates creates avoidable confusion. Changing our article today does not move an older event into the present, and a newly published announcement does not establish that its intended result has already occurred.

The first choice should be the institution's own stated milestone. If a release gives a reporting date, a decision deadline or an availability date, that is a useful candidate. The follow-up should describe the record we expect to inspect at that point. A calendar entry saying only 'check again' is too vague. An entry saying 'look for the published decision and the delivery timetable' gives an editor a defined task and gives a future reader a way to understand what was checked.

When no milestone is supplied, I favour a disclosed editorial review date. Thirty days can serve as an initial check for a short commercial announcement; a public programme may need an initial review after ninety days. Those are starting intervals for an editor to justify, not universal deadlines imposed on every subject. The interval should reflect the type of claim and the records likely to become available. An article can explain the chosen interval briefly, without pretending that the date itself makes an uncertain outcome predictable.

Match the review to the evidence

A reported numerical series needs a different appointment. The next scheduled release is often the sensible point to return, with the period and definition kept consistent. The editor should examine revisions as well as the new headline value. A change in a series can come from a changed definition, altered coverage or updated records. Following only the latest total can turn an accounting difference into an exaggerated narrative. The review should retain the earlier figure and show enough of the comparison for a reader to follow the calculation.

An experiment calls for attention to operating conditions. The later question may concern another setting, a larger trial, a changed instrument or a result reproduced by someone else. A projection calls for attention to assumptions and later observations that bear on them. Those tasks deserve their own descriptions. Repeating a generic promise to 'monitor developments' would tell the reader little about the evidence sought. A follow-up record should name the claim under review and the kind of publication or observation that could strengthen or challenge it.

Record the search and the forecast

There also needs to be a clear outcome for an unproductive search. An editor who checks the specified records and finds no relevant update should record the scope and date of that search in the working file. Publication should remain proportionate. Sometimes the old article needs a short dated note; sometimes a substantial new account is justified; sometimes the article needs no visible change. A search without a result must never be converted into a claim that nothing happened, that a project failed or that the institution concealed information.

I would keep predictions in a separate, reviewable record. A prediction should name an outcome, a timeframe and the evidence used to make it. At review, the original wording should remain available beside the later assessment. Moving the deadline or quietly softening the wording would defeat the exercise. Publishing the record also creates a cost for casual certainty. It encourages a writer to specify what would count as being wrong, while leaving readers able to judge the eventual explanation.

Begin with a small ledger

A practical implementation starts with a small working ledger: the article identifier, source, claim, review trigger and responsible writer. A person can maintain that ledger. A scheduled reminder can help with the date, while an editor reads the evidence and decides what it establishes. Each entry should lead to a traceable follow-up that a reader can inspect, with the record preserved for the next review.

Our own twelve-story coding notebook supplies a manageable place to begin. Its rows already identify different forms of evidence and preserve their source links. A writer could add a review trigger to each row, explain the choice and retain subsequent notes without rewriting the original claim. A later account should show the additions, corrections and unresolved questions. That would give a reader something useful beyond a reassuring promise about quality: a visible trail from an announcement to the next check.