Corrections, Refiles, Kills, Repeats and Embargoes

Contents

General

Reuters is totally honest about errors. We rectify them promptly and clearly. We do not disguise or bury mistakes in subsequent updates or stories. We repeat stories only when running them without any change from the original.

Many corrections can be prevented by checking simple things - the day of the week, proper names and figures, for example. For a list of checks see Avoiding Errors.

Reuters recognises three classes of errors and has set up three separate procedures to deal with them.

  • STORY WITHDRAWN -- The so-called "kill" is reserved for stories that are totally wrong or so fundamentally flawed that a conventional correction is impossible. A desk head or specialist editor must decide whether to kill a story or correct it.
  • CORRECTED - Corrections are necessary whenever a substantive, factual error appears in a story or table. Such errors include mistakes that alter the meaning or significance of the story or passage, or undermine its credibility. Stories merit corrections, for example, when they contain a wrong RICs (Reuters Instrument Code) because the mistake links the news to the wrong company. Errors involving numbers almost always merit corrections. See the appendix for more examples.
  • REFILE - Refiles allow Reuters to recognise and correct minor factual errors in stories without burying them in repeats or unnecessarily alarming readers. Such minor errors in general would have no bearing on any investment decision or understanding of the news, nor would they detract from a story’s credibility. Stories usually merit refiles, for example, when the wrong day of the week is included in the first sentence, when typos appear in common words or when a name is misspelled. A refile may only be published by the most senior member of staff on the appropriate desk. See the appendix for more examples.
  • REPEAT - Repeats are reserved for stories that have previously appeared on a Reuters news service and do not contain errors. A story is repeated exactly as it first appeared. If the headline or text has been changed for any reason, then it is not a repeat, and the proper story format needs to be used, such as correction, refile or an update. Repeats (or updates) should never be used to overwrite mistakes or inaccuracies.

Minor factual errors and typos are addressed as refiles, not repeats. See the appendix for more examples.

Follow the corrections procedure religiously. It is the responsibility of the reporter or bureau to prepare the correction but it must always be issued by the desk, even if the original was directly injected by the bureau. The final decision on whether to issue a withdrawal, correction, refile or repeat rests with the editing desk or specialist editor. Such decisions are expected to be based on approaches outlined here, rather than on personal preferences and informal polls of staff.

When correcting errors that first occurred in an earlier update of a series, you must note that the error first occurred in a particular update. If you have a further update after a CORRECTED story, it should carry a new USN and should NOT replace the corrected story. This means the correction will remain visible on the screens. For example, if an UPDATE 4 was corrected, UPDATE 5 would carry a new USN to ensure that clients continued to see CORRECTED-UPDATE 4.

In RAM, all corrections should be sent with the CXN address code.

Trashlines or advisory lines at the top of the text are mandatory for all withdrawals, corrections, refiles and repeats and must be filed within parentheses. The trashline should say exactly why a story is being killed, corrected, refiled or repeated. All trashlines on refiles and corrections must include the word “corrects" or "correcting". Trashlines serve the interests of transparency and are required to route our stories properly to some customers. They are technical as well as editorial tools.


Corrections and Procedures

Alerts and Newsbreaks

  • An incorrect Alert must be followed by a corrected Alert with a NEW USN and the word CORRECTED- manually inserted at the beginning of the text. The corrected Alert should state clearly in parentheses what is being corrected. If this would make it much too long, an explanation should be given at the top of the Newsbreak. Example: CORRECTED-TRANSMENIAN INDUSTRIES YEAR NET PROFIT 5.4 MLN EUROS (NOT 4.5 MLN)
  • The incorrect Alert should then be manually deleted from the screens.
  • If the incorrect Alert is part of a series of Alerts chained together with the same USN, the correct Alerts can be repeated to chain with the corrected Alert, but they must be preceded by RPT-. Alerts should be repeated in this manner only if the series is very recent and particularly significant.
  • If the Newsbreak has not yet been filed, file it with the same USN as the corrected Alert. The Newsbreak should include a trashline explaining the error and using the term “alert”. This procedure applies even when the Newsbreak is correct or when the erroneous alert is not covered in the body of the Newsbreak.
  • If the Newsbreak has been filed and is correct, resend it as a REPEAT to chain with the corrected Alert as it would have been deleted. Again, include a trashline explaining the error in the alert. Do not put an R in the message type of a Newsbreak that is being repeated to cover a corrected Alert because it will overwrite the Alerts.
  • If the Newsbreak has been filed and is incorrect, resend it as a CORRECTED to chain to the corrected Alert, manually inserting CORRECTED- in the headline. Write (CORRECTED) in the slug line.
  • Correct the headline if that is also wrong.


Example of a corrected Newsbreak: Slug BALDONIA-TRADE (CORRECTED) Headline CORRECTED- Baldonia Jan-June trade surplus falls Advisory Line (Corrects fourth paragraph to state that the surplus in June fell 16.6 percent to 985 billion euros and not fell 17.7 percent to 999 billion)

There is no need to include the headline in such advisory notes except when the headline is being corrected. Keep advisory notes (trashlines) as simple as possible to avoid confusing the reader. Paraphrase and summarise information in a trashline whenever possible but repeat the exact wording of the corrected sentence or segment if necessary. Do not include a line saying a corrected repetition follows, as that is obvious.


Here are some examples of advisory lines (trashlines):

(Corrects paragraph 2, which erroneously described ABC Co as the largest widget maker in Manchukistan. ABC Co is the second largest behind QRS Corp)

(In paragraph 6, the word "not" was dropped from the quote. Please read the sentence correctly as "The economy is not growing," John Doe said.)


Correcting stories with no Alert

The corrected story should have the same USN as the original story. It should have an A in the "Ref" or "Msg Type" field in the header on System 77 and Decade. This will delete the original story and insert the corrected one. It will also generate the word CORRECTED at the front of the headline, so there is no need to shorten the headline.


Correcting stories more than 24 hours old

Stories over 24 hours old will no longer have a valid USN and so will not respond to "A" in the Ref/Msg Type field, so follow this procedure to correct a Newsbreak that is more than 24 hours old. Use a new USN and insert CORRECTED at the beginning of the headline. Delete the story from the Newsyear database using the following procedure.


  1. Make a copy of the correction. Make sure it has the old USN.
  2. Add a Y to the Message Type/Ref Field
  3. In the Q Codes field type date and time of the original story, recalculating the RT time for GMT as follows: 18-MAY-1999:19:33:20 (for a story filed EDT at 15:33:20). This should fill the entire field. (The date and time are below stories on Kobra)
  4. Remove the headline, RICS and all the copy
  5. Make two spaces in the text field with the space bar
  6. Make a hard (wineglass) return
  7. File
  8. Call up the story again on Kobra to ensure that the database has been cleaned out

(Note: The Q field may not appear on the header you use; check with your techs)


Official Corrections

Special provisions are made for official corrections - those from a source, over which Reuters has no control. This is to make clear to subscribers where the responsibility for the mistake lies.

We only describe a correction as official if a source has acknowledged that the original information was wrong. If in doubt, refer to specialist editors. The only change from the standard correction format is to manually add the word (OFFICIAL) followed by a hyphen to the Alert and the headline of the Newsbreak. The slug takes (CORRECTED, OFFICIAL).

How to issue an official correction to a snap

  1. Use a DIFFERENT USN from the original Alert
  2. Type CORRECTED-(OFFICIAL) - and then the text of the Alert, all in upper case
  3. Delete the original Alert
  4. Chain the Newsbreak to the Alert, again using CORRECTED-(OFFICIAL)- before the headline if the Newsbreak is also being corrected
  5. In both cases, CORRECTED-(OFFICIAL)- must be manually inserted. Do not put an A in the Ref/Msg type box of the header field.


Example: Corrected Alert CORRECTED-(OFFICIAL)-GERMAN FINMIN-NO NEED REVISE 2001 43.7 (NOT 46.1) BLN DM DEFICIT GOAL Corrected headline and story CORRECTED-(OFFICIAL)-Germany sees no reason to raise 2001 borrowing Advisory line (Please read in first paragraph, 43.7 billion marks instead of 46.1 billion marks to comply with an official correction from finance ministry)


Refiles – Procedures

Note that slugs for both refiles and corrections use (CORRECTED) as part of the slug.


The slug line would read: HEALTH-INSURANCE (CORRECTED). Headline The word REFILE appears in upper case before the headline, with a dash and no spaces separating them. For example, "REFILE-XYZ Co posts first-quarter earnings."

There must be an advisory line (trashline) above the story text telling readers what is being corrected. Follow the same procedures for writing trashlines for refiles as you would for corrections.

Back to top

REPEATS - PROCEDURES Repeats should always be issued with (REPEAT) at the end of the slug line and RPT- at the front of the headline.

The slug line would read: HEALTH-INSURANCE (REPEAT) The headline would read: RPT-XYZ Co reports first-quarter earnings.

There must be an advisory line above the story text explaining why the story is being repeated.

The advisory line would read, for example: (Repeats to widen distribution)


Kills(Withdrawls) - Procedures

Suspect Story

If a story is suspected of being wrong, but we cannot immediately confirm this, we need to send an Advisory to clients. Send it to the same codes used for the story in question but with a different USN.


For example, send a headline along these lines: ADVISORY-Ruritania President-report being checked

Slug: BC-RURITANIA-PRESIDENT (ADVISORY URGENT) In the text field, say something along these lines: With reference to the story headlined "Ruritanian president reported badly hurt in car crash", we are checking a report that the president was not in the car.


Suspect story requires correction

If the story turns out to need only a correction, send a CORRECTED with the same USN as the original story and A in the header field.

If the story is fundamentally flawed, send an ADVISORY saying the story is wrong and is withdrawn. It should have the same address codes as the original, the same USN, a message type of R and the topic code WDW. This ensures the erroneous item will be deleted from real-time products and that there is a link (same USN) between the advisory and the story to be killed which will allow the withdrawn story to be removed from the longer-term database used for machine-readable news. Please also include the GMT time and date (in DD/MM/YYYY format) when the original item ran and also include its USN explicitly in the text. The GMT time can be worked out from the Xtra timestamp.

Headline: ADVISORY-Ruritania president story withdrawn Slug: BC-RURITANIA-PRESIDENT (URGENT) (STORY WITHDRAWN) Advisory line (trashline):

Please be advised that the Ruritania story reporting that the president was hurt in a car crash is wrong. The president's spokesman says the president was delayed and did not make the car journey as planned. The following story has been withdrawn.


STORY_NUMBER: L0987654

STORY_DATE: 19/02/2006

STORY_TIME: 1610 GMT

A substitute story follows.

In rare cases the Advisory would say: "There will be no substitute story." This would be the case, for example, when the story was totally wrong, e.g. if the car never left.

In the special case where an alert needs to be withdrawn and the advisory on this also needs to be alerted, a slightly different procedure must be followed. In this case, the alert(s) should be sent on a new USN and the withdrawn snap(s) deleted. The newsbreak that covers the advisory snap should then be repeated to the old USN as well, to ensure a link between the advisory and the withdrawn item. This different procedure is required because R does not work reliably on priority 1 items. The advisory should contain the USN, date and time information as in the example above.

In addition to these steps, an email must be sent to RCOM Editorial telling them what has been done.

This will alert our online colleagues to pull each version of the story from websites and to contact online customers to ask them to remove it.

Killing or withdrawing a story is a serious situation. No story should be killed or withdrawn without consulting a desk editor and specialist editor. The bureau chief may also be required to write an Incident Report to the regional specialist editor.

Embargoes

General

Institutions and organisations with information to convey will often give it to news services ahead of the official release time so as to give journalists time to prepare their stories – as in the case of a lengthy report – or to level the competitive and regulatory playing field – as with financial numbers.

Embargoes can be confusing. It is bad news when they are broken and can cost us access in the future to information critical to our clients, such as key economic indicators.

There are two kinds of embargo – the transmission embargo and the publication embargo. Make sure you know the difference.

  • With a transmission embargo the source of the information provides it to us on the understanding that no story will be transmitted to any of our clients until a specified time.
  • A publication embargo permits us to transmit a story immediately to wholesale media clients but with an advisory line telling them it may not be published or broadcast before a specified time. This means we cannot send such items to screen clients or internet news sites but only issue them on our media wires. These must carry the topic code EMB so they can be excluded from certain systems.

If we obtain, independently, news that is the subject of material already transmitted under embargo, we should issue our own un-embargoed story based on that source. Once an embargo has expired we should, if appropriate, follow this up with an Update adding in any material received under embargo. Our knowledge of an embargo must not inhibit attempts we have previously set in train to pursue a story.


Minimising the risk of an embargo break

Bureaux sending embargoed material to a desk must clearly mark it as embargoed in three places, in UPPER CASE.

  • In the slugline (System77 users) or Cy-Slug line (Decade).
  • At the top of the text, above the dateline.
  • In the comment line of the header field.

The desk should fill in the auto-release time and date in the editorial system header as soon as the story lands, and before it is edited. Our editing systems allow stories to be released more than 72 hours ahead, but it is a good idea not to issue stories too far in advance. Before transferring the story to an editor, make sure it is labelled EMBARGOED. If the auto-release time is midnight of the day you are handling the story, ensure that the time is entered as 00:00:01 of the FOLLOWING day. Do not enter the time as 2400 on the current day. Otherwise the system will read it as the previous midnight and the story will appear on screens immediately.

In the Americas, the release time for stories meant for Americas only is expressed in EDT or EST depending on the time of year (e.g. “embargoed for release at 19:10 EST”). Stories filed from the Americas to international services should also add the GMT release time, in italics and highlighted e.g. …19.10 EST (2301 GMT).

Do not work on a copy of the original item that carried the auto-release time – the auto-release will not be copied into your header. Also, any information in the header field may be stripped off if the story is sent to another editing desk.

Whoever transmits an embargoed item should check the transmission queue to ensure it has been transmitted. If the auto-release time is outside the desk’s control period, the exact headline and the embargo time must be mentioned in the handover. It may also be a good idea to pass on a copy of the embargoed item to the desk that is taking over, just in case the embargo is broken after the handling desk close.

If you need to change, release early, or kill an embargoed item this can be done, although in some centres this may involve intervention by systems administrators. Stories issued to the media under an embargo should carry the word EMBARGOED in brackets after the slug and give the release time and date in brackets on a separate line between headline and dateline.

In the U.S., material under publication embargo should be sent to the code WIB to allow for handling by the online desk.

Examples of a media publication embargoed items:

BC-BALDONIA-SOLDIERS (EMBARGOED)

Baldonian president honours five dead soldiers

(Embargoed for release at 2301 GMT April 28)

BALDONIA CITY, April 28 (Reuters) – Baldonian President Sanoloo Shiprash called five soldiers killed in a guerrilla ambush heroes of the nation on Thursday.

Do not use the word midnight to describe the release time for stories on publication embargo. It can cause confusion about whether you mean the start or end of the day. If it is a midnight GMT embargo, use 0001 GMT, with the date.

Embargoed stories should, when practicable, be issued to media subscribers shortly before the start of the news day in which they will be required, but generally not more than 12 hours ahead of scheduled publication unless the story is unusually long or complicated, when more time should be allowed. They must carry the topic code EMB when filed so they can be easily identified by downstream systems. Correspondents should file embargoed stories as soon as they are available.

What to do when an embargo is broken

If another news service breaks an embargo, contact the source to see if they object to our running the story early. In urgent cases (e.g. when a market is moving) we can override objections and issue the story ahead of time after approval by an editor-in-charge. In non-urgent cases we would normally respect the wishes of the source of the material.

If we decide also to ignore an embargo we must issue an advisory on the following lines to explain the circumstances: BC-BALDONIA-SOLDIERS (ADVISORY) The BALDONIA CITY story headlined “Baldonian president honours five dead soldiers”, which was embargoed for 2301 GMT April 28, is released for immediate publication. Another news organisation has broken the embargo.


Accidental release to Reuters screens

If embargoed material (including Alerts) is released accidentally to screen services, this material must not be deleted. Where appropriate, we should quickly issue an advisory with the same USN. For example, for the release of a trade figure …

ADVISORY – RELEASE OF RURITANIAN TRADE DATA Reuters inadvertently issued an alert and story detailing Ruritanian trade data for June. Other scheduled data, including money supply and foreign reserves remain under embargo until 0900 GMT.

Again, do not delete the errant material. This may give unfair advantage to those who spotted it and disadvantage those who happened to be looking away from their screen at the time. Do not apologise in the advisory – keep it as simple as possible.


Mending fences on embargo breaks

In all cases of embargo breaks the bureau or unit must inform: the relevant desk, the organisation supplying the news, and if merited, regulatory authorities such as stock exchanges.

Tell them we have made an honest mistake for which we are sorry; that we are taking steps to make sure such things do not occur again and that we trust future relations with the source will not be jeopardised.

Bureau chiefs should then write a letter to the organisation affected repeating that our policy is to observe embargoes and that we apologise for our error. In most cases, an embargo break requires an incident report to be written.


Appendix

Use the following guide to determine whether to correct, refile or repeat a story.


When to Correct

RICs -- When the RIC used is not that of the company in the news. If a RIC belongs to no other company and links to a blank data page, the story should be refiled to remove the dead RIC and replace it with an active RIC. DATA - Nearly every error that involves a number requires a correction.

MILLION VS BILLION -- Corrections are necessary with this common error. Also, correct when the word "billion" or "million" has been dropped.

DATES AND TIME PERIODS -- Wrong dates, months or years in the text. Excludes dates in datelines and days of the week in the first paragraph, which often can be addressed with a refile unless the meaning changes. For example, we would correct: XYZ Co acquired EFG Co. in 1997, not 1897, as stated in paragraph 5.

QUOTES -- Any error in a quote that changes the meaning of the sentence. It is unacceptable to drop the quote from an update instead of issuing a correction. If a quote contains an extra word or two or is missing a word, issue a refile unless the meaning changes.

PRICES -- It is unacceptable to issue an update rather than a correction when the wrong price for a stock, bond or other asset is published (unless the price changed incrementally while the story was being filed.) Also correct mistakes in the direction of any price changes, such as when the story mistakenly says a stock rose instead of fell.

BACKGROUND -- Even though background information may not change the meaning of the story or its trading impact, it often adds to the crredibility, and thus merits a correction when it is wrong.

PROPER NAMES -- Names of people, places, companies and organisations should be corrected when a misspelling creates confusion or when an erroneous name has been substituted. For example: The name President Jeb Bush was inadvertently used in the first sentence instead of his brother George W. Use a refile to correct obvious typos in proper names. For example, President Georeg Bush. The trashline would read: Refiles to correct spelling of George in first paragraph.

GENERAL CONTENT -- Descriptions, analyses or explanations that are erroneous should be corrected even if republished from a previous story or if they are not of primary importance. For example, an advisory line might read: The second paragraph erroneously described XYZ Co as the largest widget maker in the world. XYZ Co is the second largest behind QRS Corp.

DROPPED WORD -- When the missing word changes the meaning of a sentence, a correction is necessary. For example, "He was found guilty," instead of "He was found not guilty." Otherwise, use refile to add dropped words or delete extraneous ones.

TIME REFERENCES -- Corrections of time references should carry advisory lines that read: Corrects month measured by housing data to June instead of July.


Special note on Alerts: Mistakes in Alerts raise the special issue of timings. The kind of errors that would merit refiles are usually better left unaddressed in Alerts. When a refile is deemed necessary, let the Alert with the mistake stand and issue a refile that would stand side by side with the original. Any mistake involving a number would still be corrected in Alerts. Again, it is best practice to insist that all mistakes in Alerts be sent to the appropriate editing desk, which would then make a decision on how to handle it. The bureau, reporter or editor in the field should never make such a decision independently. Any remedial action must be handled by the editing desk.


When to Refile

Use refile to handle the following types of mistakes that would have no bearing on a trading decision or would not distort the meaning of a story or any passage within it. Sample advisory lines are also provided.

RICS - Refile stories that contain wrong RICS only when the symbol used belongs to no other company and links to a blank data page. The trashline would read: Refiles to correct inactive stock symbol in paragraph 4. If a RIC belonging to another company is mistakenly used, a correction is required. The trashline would read: Corrects stock symbol in paragraph 3 to ABC.N from ABC.O.

DATELINE -- Errors in datelines, including the location and date, unless either would have an important bearing on the meaning of the story e.g. Corrects dateline from FRANKFURT to Brussels or Corrects dateline to Aug 5 from Aug 4

DAY OF THE WEEK -- When the wrong day of the week appears in the lead sentence, unless the mistake would distort the significance of the news or applies to a day in the future e.g. Corrects day in first paragraph to Tuesday from Monday.

TIME CONVERSIONS -- Simple time conversions when the time being converted is correct, e.g. Corrects time in paragraph 3 to 1350 GMT from 1550 GMT.

SPELLING -- For typographical errors of common words, or most spelling mistakes in proper names, e.g. Fixes typo in 10th paragraph or Corrects spelling of Greenspan in final paragraph.

NAMES -- A story that says "President Bush" on first reference or President Goerge Bush, for example, should be refiled with President George W. Bush. The trashline would be: Refiles to correct name in paragraph 2 to President George W. Bush.

AGES -- Use REFILE for correcting the age of an individual, unless the mistake distorts the meaning of the story. The trashline would read: Refiles to correct age in paragraph 6 to 53 years old.

TITLES -- Use REFILE to correct minor mistakes in titles, such as senior vice president instead of vice president. The trashline would read: Refiles to correct title in paragraph 2 to chief financial officer. But use CORRECTED for errors that could have bigger ramifications, such as chief financial officer instead of chief executive. If there is any question, the desk head will make the decision on REFILE vs CORRECTED.

ADDS WORD -- To insert dropped words, unless the dropped word distorts the meaning of the sentence (such as the word "not") e.g. Corrects to add dropped word executive in paragraph 10. Other examples that would require corrections are words like million or percent when dropping them raises the possibility that a reader may misinterpret a number.

DELETES WORD -- To remove unnecessary words unless the presence of the word distorted the meaning of the sentence. E.g. Corrects to delete extraneous word the in paragraph two.


When to repeat

Use repeats in the following situations. Examples of advisory lines are provided.

ADDING CODES AND RICS: The advisory line should read: Repeats to widen distribution

ADDING BYLINES OR TAGLINES: The advisory line should read Repeats to adds byline

CHANGING SLUGS: The trashline should read: Repeats to change story label used by some customers. If we change a slug on a story that has been sent to media, an advisory must be sent to the media codes noting the slug has been changed to/from.

REPEATING TO NEW USN: The trash line should read: Repeats to new story number. Remove media codes from the repeat.

REMOVING STORY ATTACHED TO PREVIOUS UPDATE: The trash line should read: Repeats to remove story attached to bottom of text.

REPEATING TO ATTACH TO ALERTS: The trash line should read: Repeats to attach text to news alerts. Remove any media codes from the repeat.

REPEATING AHEAD OF DATA OR EVENT: The trashline should read: Repeats story published on Monday ahead of data due at (time)

REPEATING FROM A PREVIOUS DAY: The trashline should read: Repeats story first published on Sunday.

Powered by MediaWiki
GNU Free Documentation License 1.2