live_news_coverage v1.0.0

---

name: live_news_coverage description: Cover a developing story live with a single timestamped live file, verification gates before each update, and clear labels for confirmed, reported, and developing material. Use when running a live blog, live page, rolling updates, or live video text coverage from first alert to wrap, or when fixing a live file that mixed rumour with fact.

---

Live News Coverage

Purpose

• Run one live file as the single record of a developing story, from first alert to a closed wrap.

• Keep speed and accuracy separate. Publish fast only what has passed the gate for its label, and show the reader what is confirmed, what is only reported, and what is still unknown.

• Leave a file a second editor can audit later. Every update carries its time, label, source, and verification note.

Workflow

1. Open the file before the second update

• Create the live file with bin/live_new.py. One story gets one file. Do not scatter updates across chat, social posts, and notes.

• Fill the header on open: working headline, status OPEN, timezone, opened time, and editor name or initials.

• Write the first summary block with three lists: What we know, What we do not know, What we are checking. Update all three after every material change, not only at the end.

• Put a key points list under the summary. Keep it to the facts a new reader needs in 30 seconds. Rewrite it when facts change. Do not append to it forever.

2. Run every new fact through the verification gates

• Gate 1, provenance. Name the origin. Primary document, direct witness, official statement, agency copy, or a named secondary outlet. If the origin is a social post, find the original post and the original uploader, not a repost.

• Gate 2, corroboration. Count independent routes, not repeats. Two outlets copying one wire report or one post count as one route. See references/verification-gates.md for the route test and the photo and video checks.

• Gate 3, harm. Hold names of dead or injured people until officials confirm and family notification is reported. Hold a suspect name or photo until a named authority releases it. Hold public safety instructions until an authority issues them. If a fact could cause harm when wrong, raise its gate by one level.

• Gate 4, response. For an allegation of wrongdoing, seek a response from the person or organisation named before publishing, and record the attempt with a time. If no response arrives by publish time, say so in the update.

• Gate 5, wording. Match the sentence to the label. A reported claim gets attribution in the first sentence. A confirmed fact gets a direct statement with its source named nearby. Never let a headline or push alert state a claim more strongly than the update body does.

• If a fact fails a gate, you have three honest options: hold it, publish it at a lower label with attribution, or publish a checking note that says what you are verifying without repeating the claim in detail. Spreading a rumour in order to deny it still spreads it.

3. Post updates in the fixed format

• Write each update with the format in references/update-formats.md: timestamp with timezone, short headline, label, body, Source line, Verification line.

• Use one label per update, from this set only:

• CONFIRMED: passed provenance and corroboration, with at least two independent routes, or one primary source with direct knowledge such as an official record, a named authority on the record, or your own reporter at the scene.
• REPORTED: one credible route, clearly attributed, not yet corroborated. The update must say who reported it and that you have not confirmed it independently.
• DEVELOPING: events are moving and the update records actions, timings, closures, or official process without claiming an outcome.
• CONTEXT: verified background that helps the reader judge the live facts. No new claim about today.
• CORRECTION: fixes a specific earlier update. Name the earlier time, state what was wrong, then state the corrected fact and its source.

• Keep each update to one development. If two things happened, post two updates. A reader scanning timestamps should be able to find each fact again.

• Order updates newest first in the published file. Keep timestamps in local time for the story location plus the timezone abbreviation, and keep one timezone through the whole file.

• Attribute in the body, not only in the Source line. Readers quote the body out of context, so the body must stand on its own.

• Say what you do not know in plain words when it matters. Short lines work: Police have not said whether anyone was injured. The cause has not been announced.

• For photos and video from the public, run the checks in references/verification-gates.md before use: original source, contact with the uploader where possible, date check, location check, and a search for earlier uses of the same material. Credit the uploader as agreed and record the permission in the update notes.

4. Maintain the file while it is live

• Refresh the summary and key points after any CONFIRMED update that changes the picture, after any CORRECTION, and at least once per hour on a long file.

• Keep a running corrections log inside the file from the first correction onward. Never edit an earlier update silently. Fix it by posting a CORRECTION update and adding a short note to the original update that points to the correction time.

• Pin or link the live file from every alert you send. An alert that cannot be traced back to a labelled update does not go out.

• Log dropped claims in the editor notes section. A claim you checked and rejected is part of the record, with one line on why it failed.

• Validate the file before handover and before closing with bin/live_check.py. Fix every error it reports. Warnings need an editor decision, not a shrug.

5. Close the file with a clean wrap

• Change status to CLOSED only when updates have stopped and the wrap sections exist. See the worked file in references/worked-live-file.md for a complete close.

• Write the wrap summary as a normal inverted pyramid story lead block: most important confirmed facts first, then outcome, then response, then what happens next. Use only CONFIRMED and corrected facts in the wrap. Reported claims that were never confirmed stay out, or appear with their label and the note that they were not confirmed.

• Add three closing sections: Timeline with the key timestamps, Corrections with every correction made, and Still open with each unanswered question and who is expected to answer it.

• Add a sources list for the whole file: primary documents, official statements, named interviews, and agency material, each with a date.

• Run bin/live_check.py --closed as the last step. A closed file that fails the check stays open.

Output Contract

• One live file in Markdown with: header, summary block (What we know, What we do not know, What we are checking), key points, timestamped labelled updates newest first, editor notes, and on close a wrap summary, timeline, corrections, still open list, and sources list.

• Every update has: timestamp with timezone, headline, one label from the five label set, body with attribution in the body, a Source line, and a Verification line.

• A validation report from bin/live_check.py with zero errors for the state claimed, open or closed.

• No separate side record. Claims checked and rejected, response attempts, and photo or video permissions are logged in the editor notes of the same file.

Operating Rules

• Accuracy outranks speed. Neither speed nor format excuses an error. That rule comes from the SPJ Code of Ethics and the BBC accuracy guidance summarised in references/verification-gates.md.

• Never upgrade a label to fill a quiet period. A quiet hour gets a DEVELOPING update that says what is being waited for, or no update at all.

• Never name a victim, a minor, or a suspect from a single social source, a scanner feed, or a live caller. Wait for a named authority.

• Never repeat an unconfirmed claim in a headline, alert, image caption, or summary in stronger words than the update that carried it.

• Anonymous material needs a reason stated in the file: why anonymity was granted, why the source is in a position to know, and what second route was sought. If you cannot write those three lines, do not use the material.

• Correct in the open. State what was wrong, what is right, and when the error ran. Do not delete the error from the record.

• Keep opinion, analysis, and eyewitness colour in their own labelled updates or clearly marked paragraphs. Do not mix them into CONFIRMED updates.

• When two credible sources conflict, publish the conflict as REPORTED with both attributions. Do not pick the version that fits the earlier updates.

References

• Read references/verification-gates.md before covering high harm stories: casualties, allegations, evacuations, public safety, health, and market moving claims.

• Use references/update-formats.md for the exact update templates, alert wording, and wrap templates.

• Study references/worked-live-file.md for a full fictional file from first alert to wrap, including a rejected claim and a correction.