The story-centric newsroom workflow, from the wire to every platform, in SOM

Every newsroom runs the same loop, whatever its size: material comes in, editors decide what matters, people gather and make the story, someone checks it, and it goes out on every platform the audience uses. A story-centric newsroom runs that loop around one shared story instead of around each show or page. The Story Object Model (SOM) is an open standard built to carry that shared story between systems. This article walks the newsroom workflow stage by stage, names the people at each stage, and shows where each step lives in SOM 1.0.

Why SOM looks like a newsroom

SOM wasn't designed from a whiteboard. The introduction to the SOM specification says where its core nouns came from:

Those three nouns were not invented. They were transcribed, in sessions we called Story Archaeology, from the way working newsrooms already describe what they do.

The three nouns are the story (the happening itself), the asset (a piece of media or editorial work, whether or not it is ever published) and the telling (the moment an asset meets an audience on a platform). Around them sit the things a story needs to travel: lifecycle, priority, editorial gates, compliance, where each piece of material came from and how far it is trusted, and how stories relate to each other.

Newsroom sociology described a similar structure in 1973, when Gaye Tuchman showed how newsrooms make the unexpected manageable by sorting events into types (hard, soft, spot, developing and continuing news), so that every type has a routine. SOM doesn't carry her labels, but it carries the distinctions: a story that is developing, a story that is breaking, a story that continues from an earlier one.

Stage 1: intake, where stories come from

A newsroom is fed by far more material than it can ever use.

• Wires. News agencies send a constant stream of text, photos and video. Agency items follow IPTC standards such as NewsML-G2, where each item has a version, a publication status (usable, withheld or canceled) and signals for updates and corrections. Most wire items never become a story.
• The diary. Forward planning keeps a calendar of known events: court dates, elections, results, press conferences, anniversaries. NewsML-G2 has Event items for the diary and Planning Items for the coverage a newsroom expects to deliver.
• Everything else. Press releases, emergency scanners, social media, tips from the audience, pool feeds, the archive, and the newsroom's own reporters.

A story starts in one of three ways, and SOM 1.0 names all three in story_type:

• Planned. A diary event becomes a story before anything has happened: story_type PLANNED, with a premise that records the expected_outcome and a confidence (LOW, MEDIUM, HIGH). When the event happens differently, premise_changed, previous_outcome and actual_outcome say so.
• Reactive. An agency flash or a scanner call opens a story that is already ACTIVE, with the wire recorded in editorial_source (source_type WIRE, the provider, a credibility level and when it was received_at).
• Orphan. Media arrives before anyone has made a story for it: a viewer's clip, a feed nobody booked. SOM holds it in a minimal ORPHAN shell until someone confirms which story it belongs to.

In the orphan example published with SOM 1.0, a clip from an audience tip line arrives as USER_GENERATED and UNVERIFIED. A matching model asserts, with 0.91 confidence, that it belongs to the hurricane story; the assertion waits for a person's review, and a VERIFICATION gate holds the clip until it is checked.

Stage 2: the story meeting, where editors decide

The editor-in-chief or head of news chairs the story meeting. Planning items, wire stories and reporters' pitches compete for a place; the result is the day's story list, which American newspapers call the budget. Output editors then commit stories to shows and platforms.

What the meeting decides maps onto a handful of SOM fields:

• How much it matters: priority.level, from ROUTINE through STANDARD, HIGH and URGENT to FLASH, with a reason and who escalated it.
• Who owns it: story_owner, the system or entity with authoritative control over the story, and newsroom_id, the newsroom it belongs to.
• What doesn't go ahead: SPIKED for a story that is dropped, KILLED for one that must not run.

Stage 3: gathering, where the facts arrive

Reporters and correspondents gather the facts; crews and photographers capture the pictures; researchers and verification teams check claims and audience material. In SOM:

• Media arrives by reference. A media store publishes delivery.media_available when material lands. The media itself never travels the bus; the story points at it by a source reference and a time range.
• Every source is recorded in editorial_source with its type (WIRE, OFFICIAL, FIELD_CREW, POOL_FEED, GOVERNMENT, INTERNAL, PRESS_RELEASE, SCANNER, USER_GENERATED, SOCIAL, ARCHIVE, or a newsroom's own x- type) and how far it is trusted (TRUSTED, VERIFIED, ENDORSED, UNVERIFIED).
• Checks are assertions. A fact check, a detection or a match is an assertion with a review_state (PENDING, CONFIRMED, REJECTED), and says whether a person or a model made it.

Stage 4: making, where assets are produced

Video editors cut packages, graphics designers build maps and lower thirds, writers draft scripts and articles. Each piece of work is an asset in SOM, whether or not it is ever published:

• Type: VIDEO, AUDIO, STILL, GRAPHIC, MAP, LOWER_THIRD, SCRIPT, ARTICLE, TRANSCRIPT, SOCIAL_POST and others.
• Status: IN_PRODUCTION, PREPARED, READY, or INVALIDATED when it must no longer be used.
• Evidential position: PRIMARY, SECONDARY or TERTIARY, where the asset sits in the evidential chain, from original material to work built on accounts of it. This is how a compliance tool knows what kind of material it is looking at.

Stage 5: checking, where standards decide what may go out

Standards editors and lawyers look at anything sensitive: defamation, court reporting restrictions, privacy, graphic content, unconfirmed figures. Their decisions only work if they reach every system that could publish the material.

SOM makes those decisions part of the story:

• Editorial gates hold named things, a particular asset or a lifecycle phase, until they are APPROVED or REJECTED.
• Compliance flags record open issues with a severity (LOW to CRITICAL) and a status (ACTIVE, RESOLVED, WAIVED).
• The audit trail. A system.audit message records a clearance or a suppression (CLEARED, SUPPRESSED, WITHHELD, OVERRIDDEN).
• Skills speak up. An AI skill that spots a problem publishes skill.warning.raised with a severity of hold, flag or inform. The skill declares; the newsroom's own tools decide what to do.

Stage 6: telling, where the story goes out

A show-centric newsroom organises around programmes and pages: each rundown and each web page holds its own version of the story. A story-centric newsroom keeps one story and tells it many times.

In SOM, an asset is committed to a destination with link.committed (and can be pulled with link.withdrawn). The moment it meets an audience is a telling: telling.started, telling.ended and telling.exposed. Whether something has aired is never stored on the asset; it is read from its tellings. The rundown doesn't disappear. SOM is explicit that the rundown is one view of the story, and devices in the gallery keep taking their cues over MOS, as our comparison of MOS and SOM explains.

One story, seven snapshots

The hurricane example published with SOM 1.0 shows the whole loop in one afternoon. Each row below is a field in the story; each column is a complete story.context snapshot, with a sequence_number that only goes up.

A wire item opens the story at HIGH priority while it is still DEVELOPING. Landfall makes it BREAKING and URGENT; the upgrade to Category 4, confirmed by an official source, makes it FLASH. Video, a transcript and an outage lower third arrive as assets. A standards gate holds the lower third while the outage figure is unconfirmed, and approves it once the figure is confirmed. Because every snapshot is the whole story, a system that joins at snapshot five needs nothing from the first four.

The people, and where their work shows up

SOM follows a principle it calls messages, not organisations: it has no opinion about your desks, your roles or your tools. People don't appear in SOM as job titles. Their work appears as the state of the story.

Two things stay outside SOM 1.0 on purpose. Assignments and crew bookings live in planning and resource tools; there is no SOM message for them. And a newsroom's judgement (what to hold, what to flag, what to run) is house policy, carried by its skills and tools rather than by the standard.

What a story-centric bus makes possible

Once every system reads the same story, decisions that used to travel by phone and by shouting across the room travel with the story instead:

• A correction made once reaches every output. The bulletin, the website, social and the app all read the same snapshot.
• A held asset stays held everywhere. A gate on an asset is part of the story, so every system that could publish it can see it.
• An agency kill can follow its item. When an agency cancels an item, every story that recorded it as a source can be found through its editorial_source entries, and a skill can raise a warning on each one.
• Orphan media finds its story. A matching skill proposes the story, a person confirms it, and the clip moves across with its identity and timestamps intact.

Questions

What is a story-centric newsroom?

A newsroom that organises its work around the story rather than around each programme or page. One story is planned, gathered and checked once, then told on every platform: TV, radio, web, social and apps.

What is the difference between show-centric and story-centric?

A show-centric newsroom keeps a separate version of a story in each rundown and on each page, so every change has to be made several times. A story-centric newsroom keeps one story and many tellings of it, so a change made once reaches every output.

How does a news story start?

In one of three ways: planned from the diary of expected events, reactive to something that happens (often an agency flash), or from media that arrives before anyone has made a story for it. SOM 1.0 calls these PLANNED, ACTIVE and ORPHAN stories.

Does SOM replace the newsroom computer system or the planning tool?

No. SOM is a message standard. The newsroom system, planning tools and rundowns keep doing their jobs; SOM lets them share the state of each story with every other system that works on it.

Does SOM model newsroom roles and assignments?

No. SOM describes what travels on the bus, not how a newsroom organises itself. Roles show up as the state of the story (its owner, its sources, its gates), and assignments stay in planning and resource tools.

Where do wire services fit in SOM?

A wire service can be the system that publishes a message, and a wire item can be a recorded source of a story, with its provider, credibility and time of receipt. Most wire items never become stories; the ones a newsroom picks up are recorded as sources of the stories they feed.

Sources

• The Story Object Model specification: introduction and principles (quotation CC BY 4.0), the 1.0 JSON Schemas, and the hurricane and orphan examples
• storyobjectmodel.com
• NewsML-G2 Guidelines, IPTC: item versions, publication status, signals, Event items and Planning Items
• Gaye Tuchman, "Making News by Doing Work: Routinizing the Unexpected", American Journal of Sociology 79(1), 1973, pages 110 to 131 (abstract)

To see these messages move between systems, read the newsroom workflows. Every field named here is in the story.context schema reference, and every term in the SOM glossary. To put your own system on the bus, start with the vendor quick start.