Field note · 14 September 2026

Who runs the bus?

The Story Object Model gives a newsroom one shared description of a story, and it does that well. What it deliberately does not give you is a broker, a delivery guarantee, an authentication model, or an answer at three in the morning. That half is an operations problem — and operations is what we do.

A standard arrived on Saturday

On 12 September 2026, at IBC in Amsterdam, the Smart Stories project published version 1.0 of the Story Object Model — SOM. The specification is days old. So treat everything below as a first reading by people who run production systems, rather than as experience we do not have.

The model is deliberately small. Three concepts carry it: the Story — what is happening, how far the sourcing is trusted, where it has got to, what is being claimed; the Asset — scripts, video, audio, graphics, transcripts, held as references, because media never travels the bus; and the Telling — the moment an asset meets an audience through a destination, with a record of when that exposure started and ended. Seven message families are published as JSON Schema. Editorial rules can be written once, as machine-readable Skills, instead of being reimplemented inside every tool.

Story, Asset and Telling sit on the bus; the media store sits outside it, reached by reference and time range, because media never travels the bus. — Fig. 1Story, Asset and Telling travel on the bus. The media itself never does — an asset is a reference and a time range into a store that sits outside.

It was produced by fourteen champion organisations and a long list of technology vendors. Schemas, examples, tools and skills are Apache 2.0; the specification prose is CC BY 4.0. There is, in the project’s own words, no fee and nothing to sign.

The problem it goes after is real and old. MOS arrived in 1998 and connected newsroom systems operationally: it can tell a device to roll a clip. It never carried the editorial context around that clip — the legal hold, the sourcing confidence, the decision a programme editor made at 16:40. That knowledge has always lived in people, in chat, and across the desk. Every system holds a fragment of the story, and every fragment is correct. No system holds the story.

Left: six newsroom systems wired to each other with fifteen point-to-point links. Right: the same six systems each connected once to a single story bus. — Fig. 2Six systems and fifteen conversations to keep working — or six subscriptions to one shared description. MOS connected the systems in 1998. It never connected the story.

What the specification deliberately does not say

Read the conformance document and the scope is precise. A conforming publisher emits a valid envelope, its payload validates against the schema for the message_type it declares, and it ignores what it does not recognise. A conforming consumer must not fail on a message type it does not handle. That is the contract, and it is a good one.

What the contract does not cover: which broker you run, what delivery guarantee it offers, whether messages arrive in order, who is allowed to publish, how they authenticate, how long anything is kept, and what happens when a consumer accepts a message and then falls over. There is no transport document, no security document and no reference architecture in the repository today.

Publishers write to the bus and subscribers read from it. The specification covers only the messages on the bus; the broker, ordering, retention, replay, authentication, dead letters, backpressure and on-call sit outside it and are the operator's to run. — Fig. 3The specification ends at the message. Everything a message passes through on its way to a subscriber is an operational choice, and somebody has to own it.

This is the right call. A standard that mandated Kafka would have been a product rather than infrastructure, and it would have excluded half the industry on day one. But it does mean the box labelled the bus in every architecture diagram is a box somebody has to own, run, and answer for at the worst possible moment. The specification hands you a clean contract and, correctly, leaves the operational half on your side of the line.

Eight things we would expect to be doing on day one

All of these come from the published 1.0 material, not from imagination.

The SOM envelope: required fields, optional fields, a forbidden signature field, and the payload nested inside it. — Fig. 4The envelope every SOM message travels in. Three of the eight decisions below are already visible in it.

Broker, topics and blast radius. The envelope requires topic to begin with som. — everything after that is yours. Topic granularity is not cosmetic — it decides who wakes up when one story misbehaves, and it is very hard to change once a dozen vendors have subscribed.
Snapshots, not deltas. A story.context producer must not omit fields it did not modify; omission means absent, not unchanged, and the specification calls getting this wrong the single most damaging error an implementation can make. Every message carries the whole current state. That is a gift to anyone writing a consumer and a standing bill for whoever pays for retention. Compaction, cold storage and cost modelling are a first-week decision.
Ordering is yours to provide. correlation_id ties together every message about one story lifecycle, causation_id optionally records what prompted what, sequence_number must increase and updated_at must move forward. Note what is not guaranteed: message_id need only be a UUID — UUIDv7 is recommended, not required — so you cannot assume the wire sorts itself by time. Ordering, idempotency and replay are properties of the bus you build, and the spec is honest enough not to pretend otherwise.
Validate at the edge — but validate the right things. SOM requires implementations to switch format assertion on for uuid and date-time. Most JSON Schema validators, in most languages, have it off by default, so a malformed timestamp passes as “valid” until something downstream misorders a story. Two traps sit either side of this. The repository ships twenty negative cases that a correct implementation must reject — but only nineteen are caught by the schemas; the twentieth is a message declaring the old 0.3.2 version, which is rejected by a conformance rule rather than by a schema. A gateway that validates with schemas alone scores nineteen out of twenty and quietly admits pre-1.0 traffic. And in the other direction: the compatibility policy lets producers add new optional fields at any 1.x release, and requires consumers to tolerate them. A gateway tuned to reject anything it does not recognise will be strictly non-conformant the day 1.1 lands. Strict on the envelope, generous on the payload.
Version pinning and change control. Producers must emit the pack version they conform to, and consumers must not branch on it — with one exception, that 0.3.2 is not conformant and must not be treated as such. 1.0 is a clean break from the pre-release wire format, which is worth knowing if anyone on the project already has integration code written against IBC-era drafts. Compatibility here lives in governance rather than in code, and governance is a role with a name against it, not a document.
Who is allowed to say what. 1.0 specifies no authentication or authorisation mechanism. A message declaring system_type: compliance_engine is making a claim, not presenting a credential. Worth knowing before you design around it: the envelope schema does not merely omit a signature field, it forbids one — signing has to ride in the vendor-namespaced extensions block or at the transport layer. Mutual TLS, per-publisher topic authorisation and a decision about signing are entirely yours. On a bus that carries legal holds, that is not a detail.
Failure behaviour. Consumers must not reject unknown message types. Good. What happens to a message a consumer accepts and then fails to process is unspecified: dead-letter queues, retry and backoff, poison messages, backpressure when a wire service surges. Unspecified by the standard means specified by you — or specified by accident.
The three-in-the-morning question. Which system last published on this story? Why did the rundown not see the legal hold? Which Skill raised that warning, against which version of which rule? Answering that under pressure needs message-level tracing, searchable retention and a view a duty editor can read. Ordinary observability work. It is the difference between a bus and a rumour.

Where the sharp edges are

Three honest cautions, none of which are criticisms of a 1.0.

The Skills library is not the specification. It versions separately, currently at 0.2.2, every skill in it is marked draft, and the project says plainly that a newsroom can implement SOM 1.0 completely without using the library at all. Treat published skills as a vocabulary to learn from, not a policy engine to deploy.

Some fields ship ahead of their registries. framing_treatment is in 1.0; the governed registry of values it keys into is not. Until that lands, newsrooms agree by local convention, which means real configuration work and a migration later.

And the worked corpus is uneven by the project’s own admission — the hurricane example exercises Story and Asset but never reaches a Telling. If your interest is in the distribution end, there is less to copy from than the model’s three-part framing suggests.

Breaking news is the load test

The two scenarios shown at IBC — a hurricane, a prime ministerial announcement — are the right scenarios, and a demonstration is still a demonstration. Real breaking news is burst traffic, two publishers behaving badly, a skill warning that must not be swallowed, and a programme editor who does not care whose broker it is.

One thing deserves saying plainly. An editorial gate that silently fails to propagate is worse than no gate at all, because people come to trust it. If a newsroom is going to move holds and sourcing confidence onto a bus, that bus has to be run to the same standard as the rundown: SLOs, alerting, runbooks, and somebody awake.

How we would start

Small, and in the project’s own order. Its website sets out three levels of adoption — subscribe and publish, which it puts at days; then bidirectional structured context; then letting a tool decide autonomously against the story. Worth knowing that these levels are framing on the site rather than conformance levels in the specification, so they are a sensible sequence rather than a badge. We would not begin anywhere but the first, and we would say so to anyone who asked us to begin at the third.

A twelve-week sequence: weeks one to four build a bus that can be broken safely, weeks five to eight prove one editorial rule end to end, weeks nine to twelve put it under real operations. — Fig. 5Twelve weeks, in the project's own order. Nothing in the first four touches air.

Weeks 1–4 — a bus you are allowed to break. A broker in your own cloud, the project’s emulator alongside it, a validating gateway at the edge, two producers and one consumer. Retention and replay configured on day one rather than retrofitted. Nothing touches air.

Weeks 5–8 — one real editorial rule, end to end. A single gate, taken from a rule your newsroom already enforces by hand, expressed against the draft Skills vocabulary with the expectation that it will change. Measured: did it propagate, how fast, and what happened when we deliberately broke it.

Weeks 9–12 — operate it. SLOs, alert routing, runbooks, on-call, and a monthly report that says what actually happened. This is the point at which it stops being a pilot.

Only then is a conversation about the next level worth having.

What we are not claiming

We would rather be believed later than impressive now.

We have no SOM production track record. Nobody does. The specification is days old, 1.0 ships without a reference implementation in the main repository, and the project publishes an open register of what it has deliberately left unsettled.
We did not write the standard, and we hold no position in its working group.
We will not tell you SOM is certain to be adopted. Open standards in this industry have gone both ways. Its maintainers are a small group, the cadence of the working group is not yet published, and whether it eventually sits under an established standards body is an open question.
We will not sell you an agentic newsroom. First level, proven, then a decision.

What we do claim is narrower, and we think more useful. We have spent more than a decade running production platforms for tier-1 news organisations — the ordinary, unglamorous work of brokers, queues, pipelines, retention, access control, observability and 24/7 P0/P1 incident response, in newsrooms where being down at 18:00 is not an option. We work with HyperContent AI, one of the vendors that took part in both IBC demonstrations. And we can read a specification closely enough to tell you which parts of it are going to cost you money.

If SOM becomes the standard the industry settles on, somebody will have to run the bus. If it does not, the same eight problems will arrive wearing a different name.

Talk to us before you pick a broker. It is the cheapest conversation in the whole programme.

Book a chat ← All insights