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 note 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 is 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

	MOS	SOM
The question it answers	How does the newsroom system drive the devices that put a rundown on air?	What is the state of this story, for every system that works on it?
First published	1998 (concepts released by AP); 2.8.5 in 2017, 4.0 in 2019	SOM 1.0, September 2026
Maintained by	The MOS Group: more than 150 companies, as of 2021	The SOM working group, in the open
What travels	Running orders, stories, items, and media objects (`mosObj`)	Story snapshots (`story.context`) and events about the story
Shape	Point to point: the newsroom system and each device	Publish once to a bus; every subscriber receives it
Who is in charge	The NRCS owns the running order	The system that owns a story publishes its state
Encoding	XML	JSON, validated against JSON Schema
Transport	Defined: TCP sockets, HTTP web services, secure WebSockets	Not defined: the bus operator supplies transport, ordering, and identity
Conformance	Profiles 0 to 7; compatibility is claimed per profile	Schemas and conformance rules; families are optional; no tiers
Typical systems	NRCS, graphics, video servers, prompters, automation, still stores	Planning and NCS, media stores, graphics, web CMS, AI skills, compliance tools
Licence	Published openly; concepts released to the public domain in 1998	Apache 2.0 (schemas, tools), CC BY 4.0 (specification text)

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 does not 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 is 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. HyperContent can help newsrooms plan and operate one.

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.