MOS vs SOM: what each newsroom standard is for, and why you need both

A question that comes up often: is the Story Object Model the new MOS? No. MOS and SOM solve different problems at different layers of the newsroom, and a newsroom that adopts SOM keeps its MOS integrations. This article sets the two side by side: what each one is for, how each one works, and where they meet.

The short answer

• MOS (the Media Object Server protocol) connects the newsroom system to the devices that put a programme on air: graphics, video servers, prompters, automation. It carries running orders and media objects, point to point, and the newsroom system is in charge.
• SOM (the Story Object Model) describes the story itself: its state, sources, assets, gates and where it has been told. Any system publishes it once to a bus, and every system that cares reads it: planning, media stores, graphics, the web CMS, AI tools, compliance.

MOS answers "how does the newsroom system drive the gallery?" SOM answers "what is the state of this story, for everyone who works on it?"

MOS: the protocol that wired up the gallery

MOS began in 1998, when AP released the concepts behind it to the public domain at its ENPS developers' conference. It has been developed since by the MOS Group, in cooperation among equipment vendors, software vendors and users; more than 150 companies took part as of 2021. The SOM project puts it plainly: MOS was designed by engineers from broadcasters and vendors on behalf of their industry, and nobody owns it.

How it works:

• Point to point. The newsroom computer system (NRCS) holds a connection to each MOS device: video and audio servers, still stores, character generators, prompters and automation.
• The NRCS is the authority. It owns the story data in a running order. Devices report status and offer media objects (mosObj); since Profile 7 they can ask the NRCS to change a running order, but the NRCS decides.
• Running orders, stories, items. A running order holds stories; stories hold items; items point at media objects on a device.
• Profiles 0 to 7 say what an implementation supports: basic communication, object workflows, running orders, item control, redirection and running order changes. A product claims MOS compatibility per profile.
• XML over a connection. Version 2.8.5 uses TCP sockets (ports 10540 to 10542) with UCS-2 text; 3.8.4 uses web services over HTTP; 4.0 (2019) uses secure WebSockets. Every version is XML. MOS 4.0 is not JSON.

MOS changed what a gallery could be. The SOM specification says as much in its first pages:

MOS let newsroom systems drive devices and changed what a gallery could be.

SOM: a shared story for every system

SOM 1.0 was published in September 2026, developed through the IBC Accelerator project Smart Stories. It's an open standard: schemas and tools under Apache 2.0, the specification text under CC BY 4.0, with changes proposed in the open.

How it works:

• The message, and nothing else. SOM defines JSON messages, checked against published JSON Schemas. It deliberately leaves the transport, ordering, identity and delivery to whoever runs the bus.
• One story, published once. A system publishes a message to the bus; every system that subscribes receives it and decides for itself what to do. No pair of systems needs its own integration.
• Complete snapshots. A story.context message carries the whole story, not just what changed, with a sequence_number that only goes up. A consumer that joins late, or misses a message, is right again after the next snapshot.
• Six payload families, plus the envelope (the specification counts seven schemas). Story context, tellings (a story going out on a platform), links (an asset committed to a destination), media availability, skill warnings from AI tools, and a governance audit trail.
• Publisher-asserted. A story is minted by the system that owns it, and nothing is inferred across sources.

The specification is just as clear about the line between the two:

SOM is not a rundown. The rundown is one view of a story; SOM carries the story the rundown is a view of.

Side by side

Where they meet

In a newsroom that runs both, the newsroom system sits in the middle. Below it, MOS runs the gallery as it does today. Above it, the same story goes out on the SOM bus to the systems MOS was never meant to reach: the web CMS, AI tools that transcribe, check or enrich, the standards desk, the media store.

A few things follow:

• Nothing in the gallery changes. SOM doesn't carry running orders or cue devices, so there is nothing to migrate away from.
• The newsroom system usually publishes first. It already knows the story, so it's the natural owner of the story.context snapshots.
• A device can speak both. A graphics system can take its playlist over MOS and publish a SOM link event when a graphic is committed to a story, so the web and compliance teams see it too. Where a device only speaks MOS, a bridge can turn what it reports into SOM events.
• Editorial decisions travel. A legal hold, a correction or a kill decided once reaches every system that reads the story, not only the ones on the rundown.

Which one do you need?

• You build a graphics, playout, prompter or automation system: keep MOS for the gallery. Add SOM to hear about stories before they reach a rundown, and to say what you did with them.
• You build a newsroom or planning system: keep MOS towards the gallery, and publish your stories as SOM snapshots so every other system can follow them.
• You build a web CMS, an AI tool, a media store or a compliance tool: you probably never spoke MOS. SOM is the way in: subscribe to the stories you care about, and publish what you add.
• You run a newsroom: you need both. MOS for what goes to air, SOM for everything else that happens to the story.

Questions

Does SOM replace MOS?

No. MOS connects the newsroom system to the devices that play out a rundown; SOM shares the state of a story with every system that works on it. They work at different layers, and a newsroom can run both.

Is SOM a newer version of MOS?

No. They are separate standards from separate groups. MOS is maintained by the MOS Group; SOM 1.0 was published in September 2026 through the IBC Accelerator project Smart Stories and is maintained in the open by the SOM working group.

Does SOM carry rundowns or cue devices?

No. SOM carries the story: its state, sources, assets, gates and tellings. Running orders and device control stay with MOS.

Is MOS 4.0 JSON?

No. MOS 4.0 moved the connection to secure WebSockets, but its messages are still XML. SOM messages are JSON.

What transport does SOM use?

SOM defines the message only: no broker, no ordering, no delivery guarantees, no identity. Whoever runs the bus supplies those. SOM Managed Bus is one such bus.

Can one product speak both MOS and SOM?

Yes. A graphics or playout system can keep its MOS connection to the newsroom system and publish SOM events about the stories it works on, so systems beyond the gallery can see them.

Sources

• MOS Protocol: frequently asked questions and current versions, MOS Group
• MOS Protocol 2.8.5 and MOS Protocol 4.0
• The Story Object Model specification, SOM working group (quotations from its introduction, CC BY 4.0)
• storyobjectmodel.com
• Smart Stories: agentic production ecosystem, IBC Accelerator
• Solving the story context gap, TVBEurope

To see SOM messages checked on a live bus, try the vendor quick start or read what the bus is, and isn't.