Automated news production

1. Templates, data and the shape of an automated item

An automated news item is the product of three parts: a structured data feed, a set of rules that decide what is newsworthy in that feed, and a template with conditional language. A results service, for example, receives a fixture record, applies a rule that a margin above a threshold is described as “comfortable”, and fills a sentence pattern. Nothing is generated from nothing; every clause was written by a person in advance. This is why classic automation is comparatively safe and comparatively dull. The editorial work moves upstream into the rules, where a badly chosen threshold quietly produces thousands of misleading descriptions before anyone reads one.

2. Beats where automation earns its place

Automation fits beats with three properties: the underlying data is published on a predictable schedule, the vocabulary is stable, and the reader wants coverage of the individual case rather than a synthesis. Sports fixtures, transport disruption, air quality, tide and weather notices, planning-application lists, company filing notices and constituency-level results all qualify. In Ireland, regular statistical releases from the Central Statistics Office and open datasets published through data.gov.ie are the sort of predictable, well-documented sources on which such a pipeline can be built. Beats where the story is in the contested interpretation — courts, policy disputes, anything with a live legal risk — are poor candidates, because the template cannot carry the necessary caution.

3. Pipeline dependencies and how they break

The most common automated-news failure is not a language failure but a plumbing failure. A source changes a column heading; a schema adds an optional field; a provider moves an endpoint; a code list is renumbered; a file arrives with a different date format and every item shifts by a day. Because the template keeps producing fluent sentences, the output looks healthy while being wrong. Robust pipelines therefore validate before they publish: they check that the record count is within an expected band, that mandatory fields are present, that values fall inside plausible ranges, and that the publication timestamp of the source is newer than the last run. Anything that fails validation is held for a person.

4. Error propagation at scale

A reporter who misreads one figure produces one wrong article. A pipeline that misreads one field produces every article in that run. The severity of an automated error is therefore the product of its rate and its reach, and both can be large before anyone notices. Two design choices reduce the damage. The first is throttling: publish an initial small batch, hold the remainder for a short window and check the sample. The second is a kill switch that can withdraw or de-index an entire run by batch identifier, rather than requiring someone to edit items individually while the clock runs.

5. Corrections for items nobody wrote

A correction policy written for hand-typed copy does not transfer cleanly. If the fault lies in the source feed, the honest note says so and states when the corrected data was received. If the fault lies in the rule or template, the note should say that too, because the same fault probably affected other items. Good practice is to stamp every automated item with a batch identifier and a pipeline version, so a single correction can be applied consistently and readers can see which run an item belongs to. Keeping the original wording visible in the correction note matters more here than usual, since the reader cannot ask the author what was meant.

6. What it does to the desk

Automation does not remove work; it relocates it. Instead of writing the routine item, staff specify the rules, monitor validation alerts, handle the exceptions the pipeline refuses, and write the interpretive piece that the automated coverage makes possible. That is a genuinely different job, closer to editorial systems design than to reporting, and it needs people who can read a data dictionary as well as a press release. Desks that introduce automation without creating this role tend to end up with a pipeline nobody owns — which is the condition in which silent breakage survives longest.

7. Labelling automated output

Readers respond reasonably to automated items when they are told what they are looking at. A short standing line — naming the data source, stating that the item was produced automatically from that source, and giving the route for reporting an error — is enough. The label should sit with the item rather than in a policy page nobody opens, and it should survive syndication, because an automated item stripped of its label and republished elsewhere looks like ordinary reporting. Where an item is later amended by a person, the label should say that as well, so the reader is not told a hybrid piece was machine-made.

8. Measuring whether it works

Volume is a poor success measure for automation, because volume is the one thing a pipeline is guaranteed to deliver. More useful indicators are the exception rate (items held by validation as a share of items attempted), the correction rate per thousand published items, the median time between a source revision and the corresponding update, and the share of reader complaints traced to pipeline faults rather than source data. Reviewed monthly, these four numbers tell a desk whether the automation is stable, drifting or quietly degrading, and they are far more informative than a chart of items produced.

Which beats suit automation

Fit is a judgement about the beat, not a ranking of publishers. A strong fit still requires validation, labelling and a correction route before the first item goes out.

Before an automated feed goes live

• The source is documented: publisher, update schedule, licence and revision policy.
• Field-level validation rejects missing, out-of-range or stale records.
• Record counts outside the expected band hold the run for a person.
• Every item carries a batch identifier and a pipeline version.
• A kill switch can withdraw a whole batch in one action.
• Threshold language has been reviewed by an editor against real edge cases.
• A standing label names the source and the automated origin, and survives syndication.
• A named editor owns the pipeline and receives its alerts.
• The correction note template distinguishes source faults from template faults.

Run the checklist again after any change to the source schema. Most automated errors begin as an unannounced change at the other end of the pipe.

Questions readers ask