Julian Wetherane

The journal · Publishing versions and correction delivery

A correction is a journey beyond the source page

Changing the publisher's own record does not show what every recipient can now see. I distinguish editorial authority, delivery state and the evidence at the destination.

The earlier version has already travelled

A correction begins with an editorial decision, but its practical life can extend across several systems and organisations. The source page changes, an app carries a cached version and a partner has already received the earlier item. A programme report may show that the publishing service is available and the update was sent successfully. Neither fact necessarily explains what a reader encounters at a particular destination. I want the technology account to follow the correction far enough to make that remaining question visible.

This is not an argument for a CIO to determine what a publication should correct. Editors own the content decision and its significance, supported by the relevant professional advice where needed. My responsibility concerns the machinery through which that decision travels. The version relationship, the intended destinations and the evidence of delivery need to be understandable. When those responsibilities are separated clearly, technology can support editorial judgement without pretending that an operational status is a verdict on the truth of the underlying account.

Our rehearsal followed 120 corrections through a website, an app and a partner route. Ninety-six reached the agreed version on all three. Twenty-four remained stale on the partner route even though the source had changed. The discrepancy was not visible in a simple account of source updates. A team could reasonably say that its publishing action had succeeded while an editor still lacked an answer about a copy beyond that immediate service. The two descriptions concerned different points in the journey.

The temptation is to treat the external destination as someone else's problem. A publisher cannot directly control every recipient, and partner cooperation may be slow. A technology team also needs a boundary for its work. Those are real constraints, but they do not make the unresolved state disappear. The useful response is to describe what is known, identify who can take the next action and keep the distinction between an internal completion and a wider confirmation. A boundary should clarify responsibility, not make an inconvenient question invisible.

Acknowledgement is a separate piece of evidence

I supported six weeks of investigation and retries costing AUD480,000. The work preserved the relationship between the earlier item and the correction while making route status easier to examine. Editorial colleagues remained responsible for the intended change. Technology and the partner-facing owners examined why a transmitted update had not produced the agreed destination evidence. This was more demanding than counting messages sent, because the question concerned what had happened after the message left the source service.

Twenty of the twenty-four disputed journeys were confirmed through that work. Four still awaited acknowledgement. We therefore reported 116 confirmed and four pending in the rehearsal. The word pending mattered. It did not prove that the partner continued to display an old version, nor did it establish that the correction had been applied. It described the evidence we lacked. Treating absence of acknowledgement as either automatic failure or automatic success would have made a stronger claim than our record supported.

I find it useful to separate several states in the discussion. A correction can be approved by editorial, represented in the source, transmitted to a destination and acknowledged there. Depending on the service, further evidence may be needed to establish what is actually presented. The enterprise should decide which states matter for its account and who can confirm them. The point is not to create an elaborate vocabulary for its own sake. It is to prevent one convenient word, completed, from carrying several different conclusions without explanation.

The route also affects what a reasonable next step looks like. A problem inside a service we operate may call for a direct repair. A partner dependency may require an agreed contact and evidence exchange. A historical copy outside an active distribution relationship may raise a different question altogether. I would not hide those differences inside one aggregate success percentage. A useful executive summary can remain concise while distinguishing the actions management can take immediately from the questions that depend on another organisation or a different professional judgement.

Completion needs an explicit boundary

The rehearsal supplied evidence about 120 examined journeys. It did not establish that every correction in the archive had reached every possible copy. A controlled exercise can reveal a failure mode and test a response, but its scope should remain attached to the result. I would be equally cautious about claiming that the six-week programme had improved reader trust or eliminated editorial risk. Those propositions require other evidence. The technology outcome was a clearer and more reliable account of the particular delivery paths we examined.

There is still value in that bounded result. Editors gain a way to ask where an approved change has travelled. Service owners gain a more precise problem to investigate. Executives can see why expenditure on delivery evidence matters even when the source page already appears correct. The programme also creates a better basis for discussing future partner arrangements. If a destination cannot provide useful confirmation, that limitation can be considered when defining the service rather than rediscovered during an urgent correction that everyone wants to regard as finished.

The cost should remain in the account as well. Partner coordination, retries and examination use people and time that could otherwise support new publishing features. I would not present this work as effortless housekeeping. It is a choice about the quality of the enterprise's explanation when a published version changes. The board or sponsor should understand both the continuing obligation and the resources required to manage it. That makes the investment discussion more honest than a claim that a small technical adjustment has removed every uncertainty from the process.

I also want the process to remain usable under pressure. An editor should not need to interpret a dense application log to understand the state of a correction. The operational detail must support a clear statement of the item, version, destination and outstanding action. Different readers of that account will need different depth, but they should not receive contradictory meanings. Technology's work includes translating system evidence into an explanation that the person responsible for the publication can actually use when deciding what to do next.

A source page is an important point of control, not the whole life of a published item. Once the earlier version has travelled, the correction has a journey of its own. I want our systems to make that journey visible enough to support the people who remain answerable for the publication. The result may contain a pending destination, a limited examination or a dependency we cannot immediately resolve. Keeping those conditions in the story is more useful than ending the account at the first successful update and leaving everyone else to discover where the older version still matters.