Step 1 · Map your newsroom to SOM

Available now No code in this step, and it's the most valuable one. Most SOM

problems in a newsroom are ownership problems: two systems both think they own the story, or nobody tells the graphics engine that a story was killed.

Check your story model

Before you draw anything, paste one of your own stories, as your newsroom system exports it, into the SOM fit check in your workspace. It suggests how your fields map onto SOM's story.context, lists what SOM requires that you don't have, and what the bus would refuse. Use a made-up or anonymised story: nothing you paste is stored, but it is a sandbox.

What it finds is often your first agenda item with the vendor of your newsroom system.

Inventory your systems

List every system that creates, changes or reacts to a story. For each one:

System	Vendor or in-house	SOM system_type	Publishes	Receives	SOM support today
Planning or newsroom system	Vendor A	ncs	story.context, system.audit	skill.warning.raised, telling.*	Native, adapter or none
Graphics	Vendor B	graphics	link.*	story.context
Media store	Vendor C	archive or custom	delivery.media_available	story.context
Web CMS	In-house	custom	telling.*, link.*	story.context, delivery.media_available
Playout or automation	Vendor D	automation	telling.*	story.context, link.*
Standards desk tooling	In-house	compliance_engine	system.audit	story.context, skill.warning.raised
AI skills (style, legal, fact-check)	Vendor E	skill_worker	skill.warning.raised	story.context
Prompter	Vendor F	prompter	–	story.context

system_type must be one of SOM 1.0's values: see the envelope. The last column matters most. "None" means the product needs an adapter, and someone has to build and own it: you, the vendor or a third party. Which parts apply to you shows the same systems from the vendor's side.

Decide who owns each story

SOM expects one writer of a story's story.context snapshots at a time. Every other system reacts with its own messages: links, tellings, deliveries, warnings, audits. Write down:

• The story owner. Usually the newsroom or planning system. Is it the same for every kind of story? What about breaking news started on the web desk, or found media (ORPHAN stories)?
• Hand-offs. When a story passes from one system to another (the newsroom system to the web CMS, say), and whether it comes back.
• How other systems change the story. A graphics engine doesn't publish a new snapshot: it publishes link.committed, and the owner folds that into its next snapshot.
• Who kills a story, and how everyone finds out: a KILLED snapshot from the owner.
• Who turns a skill's flag into an editorial gate. The owner does, in its next snapshot: see Skills for publishers.
• Who records governance decisions: clearances and suppressions, as system.audit.

The bus enforces what you decide here: Story ownership lists your hand-offs and warns about, or refuses, a snapshot from any other system. You set it up in step 2.

Draw the message flow

For your three most common story types, draw who sends what to whom, in order. A breaking story:

Newsroom system ──story.context seq 1 (ACTIVE)──────────▶ graphics, CMS, playout, skills, prompter
Media store     ──delivery.media_available──────────────▶ newsroom system, CMS
Newsroom system ──story.context seq 2 (asset added)─────▶ …
Skills          ──skill.warning.raised (cause: seq 2)───▶ newsroom system, standards
Standards       ──system.audit (CLEARED)────────────────▶ newsroom system, archive
Newsroom system ──story.context seq 3 (gate approved)───▶ …
Graphics        ──link.committed────────────────────────▶ newsroom system, playout
Playout         ──telling.started, telling.ended────────▶ newsroom system, CMS, archive
Newsroom system ──story.context seq 4 (KILLED)──────────▶ everyone

Every arrow becomes a check in step 4. Every system on the right is a consumer with a filter; once they're connected, your routing map draws the same picture from their grants and filters, so you can compare it with this one. The newsroom workflows are worked examples of these flows.

Agree naming

Id	Convention (example)	Why
system_id	<organisation>-<system>-<instance>: dailyplanet-ncs-01	One installation, one system_id. It's what grants, ownership and audits refer to, and it's claimed across the bus
story_id	The owner's own story id	Stable for the story's whole life. Use a fresh one for every test run
topic	som.<message_type>, optionally followed by your own suffix	Consumers can filter on a topic prefix, if every producer follows it
newsroom_id	One per newsroom or desk	Groups with several newsrooms can filter by it
Extensions	com.<yourcompany>.<field>	Your house's own fields, which other consumers ignore

Deliverable

A short document with your fit check findings, the inventory, the ownership decisions, the flows for your top story types and the naming. It's each vendor's brief in step 3.

Next: Step 2 · Set up your house.