One bus for story context.
Every tool on it.
The Story Object Model is an open standard for sharing editorial story context between newsroom systems. No point-to-point integrations, no vendor lock-in — one set of typed messages every tool can read and write.
Proposed by these newsroom organisations
Championed by fourteen newsrooms and standards bodies, with sixteen technology participants, as the SMART STORIES IBC Accelerator project.
The core loop
A story lands. Skills react. A human decides.
Every SOM deployment runs the same shape. A story is published as a full snapshot, skills evaluate it, their outputs wait in staging, and nothing reaches the production bus without an editorial decision.
A story is republished in full on every change. sequence_number increments; there are no deltas. Consumers keep the latest version per story_id.
The executor matches each story against every skill’s advert — a machine-readable claim of what it reads, fires on, and produces. Deterministic, not guessed.
Skill outputs never go straight to production. They land on som.skills.staging and wait.
An editor approves or rejects. Either way the decision is republished in a fresh attributed envelope and recorded on som.system.audit.
Start here
Three ways onto the bus
Anything that speaks JSON over a message bus can join. What you implement depends on the role you play.
You publish stories
An NRCS, a wire service, a rundown system. You produce story.context snapshots: stable story_id, incrementing sequence_number, fresh message_id per publish, one correlation_id per story lifecycle.
You build a skill
A compliance check, a style check, an enrichment. A skill is data, not code — one JSON file of rules, interpreted by the executor. Outputs ride the approval gate like everything else.
Skill anatomy & rule types →You move media
A MAM, a TAMS store, a transcription service. You announce availability with delivery.media_available and resolve stories stream-first through asset_id.
Why SOM matters
What changes when story context is shared
The problem is not that systems can’t exchange data. It’s that they can’t exchange the story’s current meaning.
A wildfire is moving toward a residential area. The graphics system is building a map from the evacuation zone it was given. Officials widen the boundary; the producer updates the story.
One system now holds the new version. Another is still working from the old one — not because the link between them is broken, but because nothing in the stack had a way to say the story changed. A person used to close that gap by telling everyone. A graphics assistant can’t overhear the gallery.
The story context updates once, and every subscribed system gets the change. No one chases downstream tools by hand.
This is why SOM is described as complementary to MOS, not a replacement for it. MOS has moved data reliably between newsroom systems for twenty years, and it still does — but it was built for a world where humans supplied the meaning layer on top. That assumption holds right up until the tools start interpreting the story themselves.
n×n becomes n
Every newsroom integration project starts by wiring one system to another, then another. SOM replaces that mesh with a bus: you implement the standard once and every other participant is reachable.
Automation without loss of control
Skills are passive and data-driven — they observe and advise, they never act unilaterally. The staging topic plus a human gate is the core safety pattern, and it is part of the standard, not an afterthought.
Everything is on the record
Runs, decisions, non-actions. A safe-state stop — when the correct action is unclear, do nothing and record the non-action as WITHHELD — is a first-class outcome, not a silent failure.
Vendor-neutral by construction
Typed messages, a closed envelope, schema-validated payloads. Anything the spec doesn’t cover yet rides under extensions["com.{vendor}.{field}"] — a sanctioned namespace with a clean promotion path.
Media stays where media lives
SOM carries metadata and references — never bytes. An asset points at a TAMS Source URI; the store announces arrival; retrieval happens below the SOM boundary. SOM never proxies media and never queries the MAM.
Provenance travels with the story
Today the origin of a claim, the name of whoever checked it, and the clearance that let it go to air are recorded in whichever system happened to be open, and reassembled by a person if anyone asks later. A shared story object moves that record along with the story.
Stream-first, no query API
There is no “fetch me story X” endpoint. Stories republish in full on every change, so a late-joining consumer replays from the earliest retained offset and keeps the latest version per story. Resolution is by design a stream concern.
Who’s behind it
An industry specification, written by editors
SOM is being specified by SMART STORIES, an IBC Accelerator project. It was proposed by the Associated Press, NBCUniversal, ITN and the BBC, and is now championed by fourteen newsrooms, agencies and standards bodies, with sixteen technology companies participating.
The distinguishing choice is who holds the pen: the specification is written by working editors, not only by architects. The deliverables are the spec itself, a reference architecture, a reference implementation, an integration guide and live multi-vendor demonstrations.
What comes out of the development phase is five things: The specification, The Skills reference architecture, A reference implementation, A three-tier integration guide and a live multi-vendor demonstration at ibc2026. The public draft specification is due at IBC in September 2026.
Story state, verification status, compliance sign-offs and the links between stories already exist in a newsroom — but they live in people’s heads and in conversations. They never got written down in a form a system could carry, so they never moved between systems.
Which matters more the more automation is in the building: a tool with no access to editorial context doesn’t decline to answer. It fills the gap with an assumption, and the assumption looks exactly like a fact.
Further reading: AP on the coordination problem ↗ · interview with Milan Varga ↗
Champions
- Associated Press
- Al Jazeera
- Washington Post
- BBC
- Channel 4
- ITV
- Sky
- EBU
- NBC Universal
- SMPTE
- Reuters
- ITN
- Scripps
- The Global Creative & Security Community
Participants
- Shure
- EVS
- CUEZ
- Moments Lab
- Perspective Media Group
- Google Cloud
- TRINT
- Cognizant
- Nuvelics
- AWS
- Octopus
- The Weather Company
- HyperContent AI
- LiveU
- Electric Sheep
- Fonn Group
Roster as published on the IBC Accelerator project page ↗. Sources differ slightly on where one or two organisations sit.
The four ideas
What the standard rests on
Stated by the project itself, and worth reading closely — each one rules something out as much as it rules something in.
A shared story structure
It carries editorial context and interprets none of it. The structure travels; the judgement does not.
A story agent
One per story, following it across every tool it touches, from tip-off through distribution, tracking what changed and recording it.
Decentralised intelligence
Processing stays inside each vendor’s own software. There is no central engine that has to understand everything.
A Skills reference architecture
A newsroom writes its editorial rules once, as portable configurations that agents in different systems can read.
SOM contains no intelligence. It is the shared structure; the intelligence stays inside each vendor’s tools. Its job is only to make sure those tools are looking at the same picture of the story — which is also why the interesting argument is not about what SOM can do, but about where its edge belongs.
Where SOM fits in
SOM isn’t here to replace your systems
It sits between them. Your NRCS stays your NRCS; your MAM stays your MAM. SOM is the shared vocabulary they use to talk about the same story.
| Layer | What it owns | SOM’s relationship |
|---|---|---|
| NRCS / rundown ENPS, iNEWS, Octopus… | Authoring, rundowns, editorial truth | Publishes story.context snapshots onto the bus. SOM does not author. |
| MAM / TAMS store | Essence, renditions, retrieval | Announces delivery.media_available. SOM references Sources, never Flows, and never moves bytes. |
| MOS | Device control, playlist item state | Complementary, and explicitly so. MOS gives systems a shared pipe for data and has done it well for two decades; humans supplied the meaning on top. SOM is a coordination layer that can sit across a MOS environment and carry that meaning in a form a tool can read. |
| Graphics & playout incl. OGraf | Rendering and on-air execution | Consumes story context and on-air Telling events. SOM describes what is happening; the renderer does it. |
| AI / ML tooling | Transcription, summarisation, checks | Joins as a skill or an external executor. Generative output that publishes is an assets[] entry with provenance; claims about content are assertions[]. |
The envelope
Every message shares one wrapper
A closed object — unknown top-level fields fail validation. Click any key to read what it means.
som_version
The schema pack version the payload conforms to — "0.3.2" on the current pack.
Informative only. Never branch on it — message_type is what identifies the payload family. Traffic recorded before 12 Aug 2026 reads 0.2.0, the retired SOM-048 wire freeze.
Five rules that bite integrators. som_version is informative — never gate on it. correlation_id is required and must be threaded end-to-end. timestamp lives on the envelope, never in the payload. originating_system replaced source at v0.3 and the old field is hard-rejected. Message-type names are suffixed on the wire. Full envelope reference →
By the numbers
The shape of the standard
skill.warning.raised payloadLearn by building
Four things worth doing first
Run the loop end to end
Bring up the bus and the reference dashboard, publish a seed story, watch two style warnings appear, approve one and reject the other.
Quick start →30 minutes · beginnerWrite your first skill
One JSON file: an advert, a couple of rules, a detail_template. Register it, dry-run it against the seed stories, then go live.
Wire up the TAMS junction
Emit a rolling media arrival, then a capture-complete one, and watch an asset flip CAPTURING → CAPTURED and the skills re-run against the new snapshot.
Trigger a safe-state stop
Announce media that matches no story. Nothing is created, nothing is guessed — a WITHHELD record lands on the audit topic. That is the system working.
Common questions
Before you ask
Is SOM tied to Kafka?
No. SOM is transport-agnostic — it defines envelopes, payloads and topic names, not a broker. The reference starter uses Kafka, so “topic” means a Kafka topic there, but nothing in the message contracts depends on it.
Do I have to run the reference implementation?
No. Anything that speaks the bus and JSON can join. The reference starter is a .NET process that bundles an executor, a dashboard and a simulator — useful for learning the loop and testing against, but the contract is the schema, not the code.
Are skills AI?
They don’t have to be — in the reference executor most are pure rule evaluation over a JSON snapshot, with no model involved. What makes something a skill is the shape: a declared advert, deterministic recall, and outputs that go through the approval gate. AI-backed skills plug in identically, and an LLM review pass is offered as one of the three skill-validation layers.
What stops a bad automation reaching air?
The staging topic. An executor cannot publish to the production bus — it writes to som.skills.staging and a human approves or rejects. Approval republishes the payload in a fresh attributed envelope with the reviewer stamped into extensions, and both outcomes are recorded on som.system.audit.
How do I add a field the spec doesn’t have?
Put it under payload.extensions["com.{yourvendor}.{field}"]. Consumers that don’t recognise it must ignore it silently. This is the designed escape hatch — the reference implementation uses it itself for com.ibc-poc.capture_complete. Anything that later graduates into the spec drops its vendor prefix on promotion.
Why full snapshots instead of deltas?
Because consumers join late, restart, and miss messages. A full republish on every change means a consumer needs no history to be correct — keep the latest version per story_id and you are in sync. It also makes change detection cheap: skills compare the new snapshot with the previous one they saw.
How does a media arrival find its story?
It doesn’t carry one. delivery.media_available deliberately has no story_id — you resolve asset_id → Asset → Story from story.context. A cold consumer replays the story topic, or holds the arrival briefly, or after a bounded wait treats it as unmatched and records the non-action.
What is a “Telling”?
An on-air exposure event. On-air state is derived from Tellings and never stored on the asset itself — the same asset can be on air in one place and not another. Together with Links (asset-to-destination commitments with a per-destination compliance gate), it forms the distribution layer.
Is this production-ready?
Parts of it. The core skill loop and the delivery + audit halves of the distribution layer run live in the reference implementation. som.link.* and som.telling.* have ratified schemas but are a later build. The contract is stable regardless of implementation status — integrate against the schema.
Further reading
Straight from the source
This site is a secondary source. These are the primary ones.
Transforming newsrooms with agentic workflows ↗
The fullest public account of the project: the four ideas SOM rests on, the five deliverables, and the provenance argument for why a broadcaster should care.
AP Workflow Solutions — Brian Hopman · 2026The next newsroom coordination problem ↗
Why MOS is not the thing being replaced, what a Story Agent is for, and the honest version of the hard part: where the line between SOM and Skills belongs.
TVBEurope — Ash Ellis, Moments Lab · September 2026Solving the story context gap ↗
A participant’s view of building against the standard, and what it means to publish content onto the SOM bus rather than hand it between interfaces.
Octopus Newsroom — interview with Milan Varga · 2026Writing an open standard for story context ↗
The origin story, and the sentence the whole project turns on: the meaning of the story was never written down in a form that could move.
Trint — Tessa Kaday · August 2026The Smart Stories Project at IBC Accelerator ↗
The short version, and the cleanest one-line framing of the ambition: do for the agentic era what MOS did for newsrooms in the 1990s.
IBC Accelerator · 2026Incubator 2026: SMART STORIES — the agentic production ecosystem ↗
The project page itself: the full champion and participant roster, and the deliverables as the programme records them.
Put something on the bus
Bring up the reference stack, publish a seed story, and watch the loop run.