Concepts
SOM in five minutes
The whole model is four ideas: stories are snapshots, skills are data, decisions are human, and non-actions are recorded.
The objects
What SOM actually models
Seven nouns carry almost everything. Learn these and the message contracts read themselves.
Story
The editorial unit, keyed by a stable story_id. Published as full story.context snapshots carrying headline, lifecycle phase, compliance flags, editorial sources, assets and gates.
Asset
A piece of content on a story — video, script, graphic — with an editorial status and, for media, media_refs[] plus an acquisition_state.
Source (TAMS)
The stable editorial idea of a piece of media, addressed as tams://store/id. A Flow is one technical rendition of it — SOM references Sources, never Flows.
Skill
A passive, data-driven newsroom automation. It declares what it operates on, the executor decides when it runs, and its outputs are proposals — never actions.
Story Agent
One per story, persistent from tip-off through distribution. It follows the story across every tool it touches, tracks what changed, asks the rest of the stack what is happening, and records every interaction to an auditable trail.
Link
An Asset-to-Destination commitment, with a compliance gate evaluated per destination. The same asset can be cleared for digital and blocked for broadcast at the same moment.
Telling
An on-air exposure event. On-air state is derived from Tellings and never stored on the asset — because the same asset can be on air in more than one place at once.
Snapshots, not deltas
A story is republished in full, every time it changes
sequence_numberincrements andupdated_atmoves on every republish.- Consumers keep the latest version per
story_id. There are no deltas to apply and no ordering puzzle to solve. - Each republish gets a fresh
message_idandtimestamp, but keeps the samecorrelation_id. - Skills re-run on every new version — which is what makes change detection possible.
- A consumer that joins late replays the story topic from the earliest retained offset. There is no story query API; resolution is stream-first by design.
Change rules stay quiet on first sighting
A rule of type field_changed compares the new snapshot against the previous version the executor saw. On the first sighting of a story — including right after a restart — there is nothing to compare against, so it does not fire.
This trips people up constantly. If a change rule “never fires”, republish the story once so there is a baseline, then trigger the transition.
Story lifecycle
Four phases, one direction
Only stories with story_type: ACTIVE carry a lifecycle block — that is a schema rule, not a convention. Select a phase to see what it means on the bus.
DEVELOPING
The story exists and is being worked. Fields arrive incrementally: a premise with a confidence score, early editorial sources, the first assets.
Every field that arrives is another full republish, and every republish re-runs the skills. This is the phase where enrichment and advisory inform warnings do most of their work.
Threading it together. correlation_id ties every message about one story lifecycle — inbound snapshots, skill runs, staged warnings, decisions, audit records. Follow one id through the bus and you have the complete history of that story, in order, across every participant.
Skills & recall
The executor decides what runs — deterministically
A skill declares itself
Every skill ships a machine-readable advert: what it operates_on, what it fires_on, and what it produces. It is a claim, and the executor holds you to it.
"advert": {
"role": "compliance check",
"operates_on": ["story.context"],
"produces": ["skill.warning.raised"],
"fires_on": ["headline", "assets[].acquisition_state"]
}If operates_on doesn’t include story.context, the executor skips the skill entirely — and says so in the log, once. That is the single most common reason a new skill “never runs”.
Matching, not guessing
Recall is the executor’s step of deciding which skills apply to an incoming message. It is deterministic advert matching — no model, no heuristics, no ranking.
That matters for a newsroom: the set of checks that ran against a story is reproducible, explainable and auditable after the fact. Each execution produces a skill.run.completed record with latency, what it read, and what it emitted.
A skill is passive. It observes a snapshot and proposes. It cannot mutate the story, and it cannot reach the production bus.
The seven rule types, skill anatomy and the validation layers →
The boundary
What belongs in SOM, and what doesn’t
This is the live argument in the standard, and the one worth understanding before you model anything.
The structure that can travel across organisations, vendors and story types. What a story is, what changed, what state it is in, how things relate.
It carries editorial context and interprets none of it. SOM holds no intelligence — the intelligence stays inside each vendor’s own tools.
Editorial standards, compliance rules, show formats, institutional practice. The things that legitimately differ between one newsroom and the next.
A broadcaster’s election coverage and an entertainment show can use the same model and apply it very differently. Written once, as portable configuration that agents in different systems can read.
Why the line is hard. Draw it too broadly and the standard becomes rigid — every newsroom’s particular habits baked into something meant to be shared. Draw it too narrowly and it becomes too thin to be worth adopting. The project’s own working view is that the shared layer may end up smaller than people expect, and that this is fine: a useful common model doesn’t have to capture everything, only the right things.
Status, honestly. The line being drawn today may move once vendors start building against it. The public draft specification is due at IBC in September 2026; what this site documents is the schema pack and reference implementation as they stand, not a ratified standard. Treat the vendored schemas as the source of truth and expect the model to keep moving.
The approval gate
Nothing reaches production without a decision
This is the core safety pattern of the standard, and it is structural — an executor has no path to the production topic at all.
hold
The executor must withhold all output on the affected fields until the warning is resolved; subscribers must not use held content.
In the reference dashboard, hold lands red and cannot be cleared with a single click.
flag
Output is marked as requiring review. Subscribers may display a visual warning.
Lands yellow with a standard approve / reject.
inform
Advisory only — no blocking action, no mandatory response from any subscriber.
Lands blue and auto-clears once acknowledged.
The payload is republished to som.skills.events in a fresh, gate-attributed envelope — new message_id and timestamp, causation_id pointing at the staged message. The reviewer and time ride in payload.extensions, and a CLEARED record lands on som.system.audit.
Same shape, to som.skills.rejected, with the rejecting reviewer in extensions and a WITHHELD audit record. A reject is not a deletion — it is a terminal non-action, recorded as one.
Safe-state stop
Doing nothing is a result, and it gets written down
When the correct action is unclear, a SOM participant does nothing — and records the non-action as WITHHELD on som.system.audit. This is the rule that keeps an automated newsroom honest: silence and refusal look identical from the outside unless refusal is logged.
The canonical example. A media store announces that a clip has arrived, and the clip’s asset_id matches no story on the bus. The reference coordinator re-checks for about a second, then stops: it does not invent a story, and it does not drop the event silently. It writes a WITHHELD audit record and moves on. Creating a story from unmatched media is a separate, explicitly opt-in preview lane.
The same vocabulary covers human decisions: an editor’s reject is a WITHHELD too. One audit topic, one grammar, whether the non-action came from a machine or a person.
Glossary
The vocabulary
| Term | Meaning |
|---|---|
| Story | The editorial unit; published as full story.context snapshots, keyed by story_id. |
| Asset | A piece of content on a story (video, script, graphic) with editorial status and, for media, media_refs[] + acquisition_state. |
| Source (TAMS) | The stable editorial idea of a piece of media (tams://store/id); a Flow is one technical rendition of it. SOM references Sources, never Flows. |
| Delivery | The availability handshake: media became reachable in a store (delivery.media_available). |
| Link | An Asset-to-Destination commitment, with a per-destination compliance gate. |
| Telling | An on-air exposure event; on-air state is derived from Tellings, never stored on the asset. |
| Skill | A passive, data-driven newsroom automation; the executor runs it. |
| Story Agent | One agent per story, persistent from tip-off through distribution: it follows the story across tools, tracks change, and records interactions to an auditable trail. |
| Executor | The process that watches the bus, decides which skills apply, and runs their rules against each snapshot. |
| Advert | A skill’s machine-readable declaration of what it operates on, fires on, and produces. |
| Recall | The executor’s deterministic advert-matching step — deciding which skills run. |
| Staging | The pre-approval topic; nothing reaches the production bus without a human decision. |
| Safe-state stop | When the correct action is unclear, do nothing and record the non-action (WITHHELD on som.system.audit). |
| Envelope | The outer wrapper every SOM message shares; the payload inside is what schemas validate. |
| Extension | payload.extensions["com.{vendor}.{field}"] — the sanctioned place for not-yet-ratified fields. |
| Instance | One surface a story airs on — linear newscast, web live-blog, social card — identified by instance_id. |
Next: the wire format
Every message shares one envelope. Here is every field in it, and the five rules that bite integrators.