Corrections, Refiles, Kills, Repeats and Embargoes

Contents

GENERAL PRINCIPLES

Reuters is totally honest about errors. We rectify them promptly and clearly. We do not disguise or bury mistakes in subsequent updates or stories.

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.

  • CORRECTED - Corrections are necessary whenever a substantive, factual error appears in a story or table. Such errors alter the meaning or significance of the story 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 and proper names merit corrections. See the appendix for more examples.
  • REFILE - Refiles allow Reuters to recognise and correct minor errors in stories without 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 to fix spelling, typos, dropped words or duplicated words. If in doubt, use the CORRECTED procedure. See the appendix for more examples.
  • WITHDRAWAL- The so-called "kill" is reserved for stories that are totally wrong or so fundamentally flawed that a conventional correction is impossible. Desk heads in consultation with specialist editors or bureau chiefs decide whether to kill a story or correct it.
  • REPEAT - A Repeat is NOT a correction. 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. A story should usually only be repeated if it needs to be distributed more widely to extra product codes.

Corrections, Refiles, or Withdrawals can be written by the relevant reporter, bureau chief or specialist editor but must be published through a regional editing desk and not "direct injected" or self published even if the original was directly injected by the bureau.

When correcting errors that first occurred in an earlier update of a series, you must note that the error first occurred in a particular numbered 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 the story with the headline tag CORRECTED-UPDATE 4.

Trashlines or advisory lines at the top of the text are mandatory for all withdrawals, corrections, refiles and repeats. The trashline should say exactly why a story is being withdrawn, 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.

CORRECTING ALERTS

ALERT(S):

Find the Alert using Lynx Search and select the alert in a Lynx basket by clicking on it, then click on the button "Correct Chain" in the menu bar or right click on the headline and select "Correct Chain" in the menu bar.

Selecting "Chain Correction” calls up a popup box with a series of options, allowing you to correct all the alerts on a new USN or select only one or more of the alerts for correction while repeating the other correct alerts to the same new USN, and automatically removing the original series on the old USN.

Check either the "All" button or the "Custom" button in the Correct Chain box.

If you check the "All" button, then click "Continue" in the bottom right of the box it will open the file, add CORRECTED- and allow you to write your corrected alerts. You can then "Transfer” or “Transfer and Newsbreak” it to your default editing desk if you are a reporter or Publish or “Publish and Newsbreak” it as an editor.

In a series of alerts, clicking the “Custom” button allows you to choose which alert(s) you want to correct, refile or repeat. If you check the "Custom" button, then click on the down arrow next to each alert and select either "Delete", "Correct", "Refile" or "Repeat" for each alert in the chain, then click the "Continue" button in the bottom right of the box which will open the file of alerts and allow you to make your changes.

Note the “Continue” button will not publish anything. It merely allows you to go ahead and write your corrections until you are ready to “Transfer” or “Publish”.

Also note that Lynx is programmed to put a NEW USN on the alerts chain along with message type S (rather than message type A for corrected stories) BUT will remove the old alerts chain with the incorrect alert(s). The old chain may take a couple of minutes to disappear from Eikon and you may need to refresh your news screen.

Reporters should "Transfer" the alerts file to a regional editing desk for editors to “Publish”.

CORRECTING STORIES IN LYNX EDITOR

FOR STORIES PUBLISHED LESS THAN 24 HOURS AGO:

To correct a published story in Lynx Editor:

Find the story headline using Lynx Search and then click on the headline and select the "Correct" button in the menu bar above or right click on the headline and select "Correct" in the drop down menu.

In the case of a regular story, clicking the "Correct" button will: Open the story and automatically keep the same USN to replace the old story Add the Message Type A; Add (CORRECTED) in the slugline; Add the CORRECTED- headline tag before the headline.

Reporters should write a corrected version of the story and transfer it to a regional editing desk for editing and publishing. Corrections should be checked and published by a regional editing desk. The correction functionality will publish the correction by replacing the original item on the same USN.

NOTE: When updating a story after a correction, use the same procedure as for a regular update. Find the corrected story using Lynx Search, click on the headline and hit the Update button (or right click on the headline and select update in the popup window) and proceed as usual for updates.

Lynx Editor is programmed to then:

Generate a new USN for the next update after a correction to preserve the correction;

Replace the CORRECTED slug and headline tag with UPDATE x etc;

Generate the S message type.

DO NOT USE the COPY button to produce an update, or correct an update, or update a corrected update as this breaks the reference chain in Lynx Editor history.

CORRECTING STORIES MORE THAN 24 HOURS OLD

Repeat the same procedures as for same day corrections (see above).

After the corrected story is published the next step should be completed by desk editors only, not reporters.

Find the ORIGINAL story headline again, NOT the corrected story you have just published, in the "Publish" basket or using "New Lynx Search" etc

Click on the headline and select "Historical Delete" in the menu bar or right click on the headline and select "Historical Delete". A pop-up window will open into which you need to write the published date and time (converting from AM and PM on Eikon into the 24 hour clock) in the following exact format DD-MM-YYYY:HH:MM:SS.00 (Note the hyphens, colons, point and two zeros at the end).

To find the published date and time, find the story on Eikon, look for the information at the bottom of the story or left of the headline and enter it in the pop up window in the format noted above. The trick is to use the GMT date but the LOCAL TIME. For example:

27-06-2012:20:46:10.00 -- two zeroes at the end.

Select OK

Note nothing is generated into the Lynx Publish basket after you use Historical Delete function, there is no confirmation on the Lynx screen which reverts to the Search page, and the original incorrect story will remain in the Lynx database as it should, but you should see the story disappear from Eikon.

If the offending story is still there then email Editorial Help Desk to have it removed (you can generate an email with a screengrab of the story directly from Eikon so Iteam can see the USN, published time etc).

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 credibility, 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.

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 your regional editing desk. 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 euros instead of 46.1 billion euros to comply with an official correction from finance ministry)

BLOGS

If a post needs a correction, strike out the incorrect material, then immediately afterwards write the corrected word or phrase in brackets. Add CORRECTED after the headline of the post.

Image:blogshot01.gif

If the correction is relatively minor, you can simply write the correct word or phrase after the section that has been struck through.

Image:blogshot02.gif

It is acceptable to fix minor misspellings without leaving a record. However, if you misspell the name of, for example, a company or person, correct it throughout the story and the headline if need be.

At the bottom of the story, write a correction such as the following:

(CORRECTION: The first name of Irish Foreign Minister Micheal Martin was misspelled Michael in the original version of this story.)

If you update a post, add UPDATED after the headline. In the body of the post, add the update in brackets where it belongs:

Most of the cash was used to repurchase stock from executives and employees (UPDATE: Moneyblog reports that all of the proceeds were used for that purpose)

Alternatively, you can link to an updated story:

Jim Johnson has joined Cloudnine Capital, a London-based buyout firm, Reuters has learned. Johnson was previously a managing director at Clunker Associates for 11 years. (UPDATE: I spoke to Johnson and posted more info here.)

If you need to correct a headline, add a line at the bottom of the post describing how it was changed.

(CORRECTION: The headline that appeared on the original version of this story incorrectly suggested that Silvio Berlusconi was shortlisted for the Nobel Peace Prize)


REFILES

Find the story using Lynx Search and select it by placing your cursor on the headline and hit the Refile button, or right click and select REFILE.

The REFILE function will:

Keep the SAME USN to replace the original story on desktop products as it does for the CORRECT button.

Add message type R to replace the original story (not message type A used for corrections)

Add CORRECTED to the slug field, BUT add REFILE as a headline tag, not CORRECTED.

Then write an advisory (trashline) in the advisory field telling readers what is being corrected. Follow the same procedures for writing trashlines for refiles as you would for corrections.

NOTE: When updating a story after a REFILE, use the same procedure as a normal update. Find the refiled story using Lynx Search, click on the headline and hit the Update button (or right click on the headline and select update in the popup window) and proceed as usual for updates. Lynx Editor is programmed to then:

Generate a new USN for the next update after the refile to preserve the correction;

Replace the REFILE headline tag with UPDATE x etc;

Generate the S message type.

DO NOT USE the COPY button to produce an update, or correct an update, or update a corrected update as this breaks the reference chain in Lynx Editor history.

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.


KILLS OR WITHDRAWALS

If a story contains multiple errors, it may need to be WITHDRAWN, and not just CORRECTED.

Killing or withdrawing a story is a serious situation. No text story should be withdrawn by a reporter without first consulting the bureau chief or specialist editor, and the head of the regional desk.

Withdrawn stories should be replaced if the issues that caused them to be killed can be resolved. The withdrawal should state whether or not a replacement will be published (and when).

If the story is sensitive, or in cases where it is difficult to decide if a withdrawal or correction is more appropriate, approval must be sought from the regional editor or managing editor for news. Those editors, in turn, may escalate the issue to the global ethics and standards editor.

If the withdrawal relates to visual or digital issues, the global head of visuals or the executive editor of digital will give final approval, consulting the global ethics and standards editor as needed.

PROCEDURE

First, find the story in a Publish basket or via a Lynx Editor Search.

Right click on the headline and select the WITHDRAW option.

A popup window will open with a preformatted withdrawal ADVISORY containing the slug, the ADVISORY headline tag, the same USN and message type R in the header field.

The text of the advisory will also contain the USN OF THE STORY TO BE WITHDRAWN, the date and the time published in GMT

All you need to do is write the headline and advisory line explaining why the story is withdrawn.

In the text field give reasons for the withdrawal and say whether or not a replacement story will be be published.

Then PUBLISH the ADVISORY and the story will be withdrawn/deleted from desktop products like Eikon simultaneously.

In addition to these steps, an email must be sent to rcomsupport@thomsonreuterslcom and BLR-Online_Newsroom@thomsonreuters.com telling them what has been done.

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

NOTE: WITHDRAWALS MORE THAN 24 HOURS OLD

Note that if a story being withdrawn was originally published more than 24 hours previously, you will need to supplement the above withdrawal procedure with the HISTORICAL DELETE procedure used with CORRECTIONS more than 24 hours old.

After publishing the advisory using the WITHDRAWAL function in Lynx Editor, Find the ORIGINAL story headline again, NOT the WITHDRAWAL advisory, in the "Publish" basket or using "New Lynx Search" etc

Click on the headline and select "Historical Delete" in the menu bar or right click on the headline and select "Historical Delete". A pop-up window will open into which you need to write the published date and time (converting from AM and PM on Eikon into the 24 hour clock) in the following exact format DD-MM-YYYY:HH:MM:SS.00 (Note the hyphens, colons, point and two zeros at the end).

To find the published date and time, find the story on Eikon, look for the information at the bottom of the story or left of the headline and enter it in the pop up window in the format noted above. The trick is to use the GMT date but the LOCAL TIME. For example:

27-06-2012:20:46:10.00 -- two zeroes at the end.

Select OK

Note nothing is generated into the Lynx Publish basket after you use Historical Delete function, there is no confirmation on the Lynx screen which reverts to the Search page, and the original incorrect story will remain in the Lynx database as it should, but you should see the story disappear from Eikon.

If the offending story is still there then email Editorial Help Desk to have it removed (you can generate an email with a screengrab of the story directly from Eikon so Iteam can see the USN, published time etc).

WITHDRAWING ALERTS

A withdrawal should only be done by editing desks.

However, in the case of market moving economic or market data or company announcements the bureau or reporting team that was the source of the error can publish an interim ADVISORY alert, saying which data or headline was wrong and noting the correct information.

For example:

ADVISORY-AUTOMATED ALERT STATING COUNTRY XX CENTRAL BANK RAISED BENCHMARK INTEREST RATE WAS ISSUED IN ERROR; THERE WAS NO CENTRAL BANK ANNOUNCEMENT

ADVISORY – ALERT ON COUNTRY XX DECEMBER CPI WAS ISSUED IN ERROR; THERE WAS NO MINISTRY OF FINANCE ANNOUNCEMENT

The advisory alert can be created and published either through Lynx Editor (right-click on the original alert in a Publish or Alerting-Tools basket, and use the Add Chained function to prepare and publish the advisory alert), or through Lynx Alerting, if the advisory is for an alert you have just published (use “ctl + shift + p” to recreate the alert, then change the text as needed, and publish).

This advisory should carry the same USN as the original using the S message type (NOT the R message type) and therefore should NOT delete the original. A regional desk must then be informed that the desk can follow up with a proper withdrawal procedure, as described below.

LYNX EDITOR PROCEDURE FOR WITHDRAWING ALERTS:

To withdraw an alert or a chain of alerts, click on one of the alerts in the Publish basket, select CORRECT CHAIN then select ALL and select WITHDRAW and CONTINUE. A new story with a new USN will be created which allows you to explain why the alerts are being withdrawn. Hit PUBLISH and Lynx will automatically delete the original alerts and publish the withdrawal on the new USN.

To withdraw one or more but not all alerts in a chain, you need to use the CORRECT CHAIN function, select CUSTOM, select DELETE for the alerts you wish to withdraw and select REPEAT for the alerts you wish to preserve or REPEAT, then select CONTINUE and PUBLISH. The alerts preserved will be repeated on a NEW USN without the deleted alert(s).

Then go back and do a withdrawal on the chain, as above, giving the USN of the repeated alerts as part of the explanation.

FOR LYNX ALERTING SOFTWARE (NOT LYNX EDITOR) PROCEDURES:

Please consult your regional speed editor.

REPEATS

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)

WHEN TO REPEAT

Stories can be repeated for technical reasons, for example to fix metadata or coding. Initiative stories, such as INSIGHTS, ANALYSIS and SPECIAL REPORTS, can also be repeated to broaden their distribution, such as repeating them at peak Eikon readership periods.

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

CHANGING SLUGS: The trashline should read: Repeats to change story keyword used by media 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.

EMBARGOES

Types of Embargoes

Traditionally there were are two types of embargoes:

A TRANSMISSION EMBARGO which restricts publication to all subscribers until a time specified.

A PUBLICATION EMBARGO which transmits the story immediately to MEDIA CLIENTS ONLY with an advisory that the story is not to be published until the time specified. However, in the age of real time news websites and social media, Reuters no longer uses PUBLICATION embargoes.

ALL embargoes are now TRANSMISSION embargoes.

Minimizing the risk of an embargo break

Bureaus transferring embargoed material to an editing desk reporters must clearly mark it as embargoed in UPPER CASE, either in the COMMENT LINE in Lynx Editor or in the TEXT field of the alert, or story, as well as in the SLUG field of the story.

For example the Comment line should read:

"EMBARGOED FOR RELEASE AT 2301 GMT APRIL 28"

And the slugline should read:

BC-BALDONIA-SOLDIERS (EMBARGOED)

Adding Embargoes to Stories

To embargo a story in Lynx Editor:

Open the story in Lynx Editor and click the Set button in the embargo field. Specifiy the date and time for the embargo. The time defaults to GMT. If you wish to set the embargo in the local time on your computer, uncheck Use GMT box. Click the Set button again to save the embargo.

To revise the embargo time, click the Edit button.

To remove the embargo, click the Remove button.

When you have set the embargo, the Publish button will change to an Embargo button. Click the Embargo button to transfer the story to an Embargo basket where the story will be held until the embargo time expires and Lynx Editor will automatically publish the story.

If you are not comfortable with setting the embargo field yourself in Lynx Editor, then clearly mark the alert or story EMBARGOED, using the procedure described above, and transfer it to a regional editing desk basket for the desk to complete the procedure.

Embargo Breaks

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 a senior editor. 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.

If Reuters breaks an embargo, the material must NOT be deleted. Deleting the content published mistakenly is dishonest and may give unfair advantage to clients who read it and disadvantage those who missed it.

Where appropriate, we should quickly issue an advisory with the same USN but using the J (join or append) message type to add the advisory to the bottom of the story. For example:

ADVISORY – RELEASE OF RURITANIAN TRADE DATA Reuters inadvertently issued an alert and story detailing Ruritanian trade data for June.

Mending fences on embargo breaks

In all cases of embargo breaks the bureau or reporting team must inform: the relevant editing, 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.

Powered by MediaWiki
GNU Free Documentation License 1.2