SOM 1.0 · veröffentlicht auf der IBC 2026
Ein Bus für den Story-Kontext.
Jedes Tool daran.
Das Story Object Model ist ein offener Standard für den Story-Kontext in der Content-Produktion – eine Schicht unter den Tools, die Sie bereits betreiben. Sie trägt, was gerade über eine Story wahr ist und wie sich das verändert hat. Die Tools reden nicht mehr miteinander, sondern lesen stattdessen eine gemeinsame, laufend aktuelle Beschreibung der Story.
Unter den vierzehn Champion-Organisationen
Entwickelt im IBC Accelerator Media Innovation Programme 2026 als Projekt SMART STORIES, mit vierzehn Champions und siebzehn Teilnehmern.
Die Lücke
Jedes System hält ein Fragment. Keines hält die Story.
Jedes Tool in einer Redaktion ist in seinem eigenen Ausschnitt genau. Die Entscheidungen, die die Story prägen – ein Hold auf eine Zahl, welches Skript aktuell ist, was freigegeben wurde –, wandern per Chat, Telefon und Zuruf über den Tisch, und die nächste Schicht überleben sie selten.
Spät in einer Breaking Story hält der Chef vom Dienst eine unbestätigte Opferzahl zurück. Der Rundown erfährt davon; die Grafik bekommt ein Rebriefing und versteht es falsch; der Online-Desk hat den Gruppenchat gesehen, der Social-Desk nicht; dem Ticker hat niemand Bescheid gesagt.
Die Zahl ist auf einem Ausspielweg zurückgehalten und auf einem anderen live, und morgen ist die einzige Spur das Gedächtnis der Beteiligten. Der Kontext hat nie gefehlt – er saß dort fest, wo kein System ihn lesen konnte.
Der Chef vom Dienst trifft dieselbe Entscheidung in dem Tool, das er ohnehin benutzt, und sie wird in die Story geschrieben. Jedes abonnierte Tool sieht sie sofort und wendet die Regeln an, die seine Redaktion ihm mitgegeben hat: Der Clip darf nicht laufen, die Grafik wird nicht ausgespielt, der Ticker lässt die Zahl weg.
Die Entscheidung, wer sie getroffen hat, wann und warum, ist dokumentiert – ebenso, was jedes Tool daraufhin getan hat. Der Mensch wurde nicht ersetzt; er trägt keinen Zustand mehr herum und trifft wieder die Entscheidung.
Die Idee
Tools sprechen mit der Story, nicht miteinander
SOM ist eine kleine Menge von JSON-Nachrichtenfamilien auf einem gewöhnlichen Publish/Subscribe-Bus. Über den Tools sitzt nichts: kein Orchestrator, keine zentrale Anwendung. Jeder Teilnehmer liest die Story, entscheidet selbst und veröffentlicht in seiner eigenen Familie, was er getan hat.
Story
Das, was in der Welt geschieht: worum es geht, seine Quellen und wie weit man ihnen traut, Lifecycle und Priorität, die Prämisse, die die Redaktion erwartet, und die aufgestellten Behauptungen samt ihrem Prüfstatus.
Asset
Was die Redaktion sammelt und produziert, um sie zu erzählen – Video, Audio, Skripte, Grafiken, Transkripte. Nur als Referenz: Medien laufen nie über den Bus. Jedes Asset trägt seine Provenienz und seine Beweisposition.
Telling
Der Moment, in dem ein Asset über ein Ziel ein Publikum erreicht. Eine Story, ein Pool von Assets, beliebig viele Tellings – und der Compliance-Status gehört zum Telling, nicht zum Medium.
Abgeschrieben, nicht erfunden. Die drei Substantive stammen aus Story-Archaeology-Sitzungen – bei denen nach der Ausstrahlung nachverfolgt wurde, wie der Kontext einer echten Story zwischen Menschen und Systemen wanderte. Das Modell ist klein, weil das Vokabular, das Redaktionen ohnehin benutzen, klein ist. Die drei Substantive im Detail →
Hier anfangen
Drei Wege auf den Bus
Ein konformes System implementiert das Envelope und nur die Familien, zu denen es etwas zu sagen hat. Was das bedeutet, hängt von Ihrer Rolle ab.
Sie besitzen Storys
Ein Planungssystem oder NCS. Sie legen die Story an und veröffentlichen story.context-Snapshots: eine unveränderliche story_id, eine steigende sequence_number und jedes Mal jedes Feld – Weglassen bedeutet nicht vorhanden.
Ihr Tool handelt nach Regeln
Ein Rundown-, MAM-, CMS-, Playout- oder Grafiksystem. Ihr Executor ruft Skills aus der gemeinsamen Bibliothek ab, veröffentlicht skill.warning.raised und entscheidet, was Ihr Tool zurückhält.
Sie bewegen Medien oder Ausspielungen
Ein TAMS-Speicher oder MAM kündigt delivery.media_available an; ein bindendes System veröffentlicht som.link.*; Playout und Social veröffentlichen som.telling.*.
Das Regelwerk
SOM trägt den Kontext. Skills tragen das Wissen.
Redaktionelle Regeln werden einmal geschrieben, von der Redaktion, im offenen agentskills.io-Format, wo jedes Tool sie lesen kann. Ein Skill ist passiv: Er deklariert, was wahr ist, und das Tool, dem der Executor gehört, handelt danach.
Senden Sie keine Opferzahl, bevor zwei namentlich genannte, unabhängige Quellen sie bestätigen oder es eine offizielle Stellungnahme gibt. Bis dahin halten Sie die Zahl auf jedem Ausspielweg zurück und leiten sie an den Standards-Desk weiter.
# illustrative — the same rule, once, for every tool skill: casualty-figure-hold declares: GATE scope: story.context.editorial_gates when: confirming_sources < 2 and no official_statement then: hold · route: standards_desk authored_by: standards desk silence: valid
Eine Kopie, ein Autor. Niemand übersetzt die Regel in sechs Herstellerprodukte, und kein Hersteller braucht eine Kopie Ihrer Richtlinien, um für Sie zu arbeiten. Lässt sich eine Regel nicht auswerten, bleibt die Ausgabe, die sie schützt, zurückgehalten, und ein Mensch entscheidet. Wie Skills abgerufen werden →
In Aktion sehen
Zwei Breaking-News-Szenarien, ein Story-Bus
Auf der IBC 2026 spielte das Konsortium zwei Szenarien mit unterschiedlichen Storys und unterschiedlichen Herstellern durch – alle lasen und schrieben dieselbe Story mit echten Produktionstools. In keinem der beiden schickt irgendetwas einen Befehl an irgendetwas anderes.
Der Hurrikan ↗
Agenturmeldungen und ein Wetterdaten-Feed auf dem Bus, dazu Transkription und Media Intelligence, die die Story lesen. Zwei Clips treffen ein – einer mit Echtheitsnachweis, einer ohne –, und das Gate behandelt sie unterschiedlich, nachvollziehbar dokumentiert. Der Sturm wird an der Quelle neu eingestuft, eine Journalistin bestätigt es, und jedes Tool, das von der alten Kategorie abhing, sieht die Änderung gleichzeitig. Eine unbestätigte Behauptung aus nur einer Quelle bleibt zurückgehalten, während der Rest der Seite live geht.
AP · The Weather Company · Trint · Moments Lab · Cuez · Vizrt · HyperContent AI · Shure · Amazon Web Services
Szenario 02Die Ankündigung des Premierministers ↗
Eine Ankündigung, deren Ausgang erst feststeht, wenn sie gemacht wird. Die Story geht mit einer erwarteten Prämisse und zwei vorbereiteten Skript-Sätzen auf den Bus. Tools, die sie lesen, halten Social-Media-Entwürfe zurück, schlagen eine Live-Einheit vor, transkribieren den Feed und schlagen die Aussage vor, sobald sie gesprochen ist – und nichts ändert sich, bis eine Journalistin freigibt. Diese eine Freigabe schneidet den Clip, übernimmt die passenden Skripte, unterdrückt die anderen mit dokumentierter Begründung und gibt die zurückgehaltenen Posts frei.
Reuters · Octopus · LiveU · Fonn Group (Mimir) · Trint · HyperContent AI · Amazon Web Services
Es ersetzt nichts
Ein neuer Standard, dazu intelligente Schnittstellen
Hardware hatte GPI; Software hatte MOS, von Sendern und Herstellern für ihre Branche gebaut und im Besitz von niemandem. SOM ist das Gegenstück für die Ära intelligenter Tools, und es trifft die Standards, die bereits funktionieren, dort, wo sie stehen.
| Schicht | Wofür sie zuständig ist | Verhältnis zu SOM |
|---|---|---|
| NCS / Planung | Anlegen und Verfassen der Story | Der Story-Eigentümer. Veröffentlicht story.context und besitzt dessen Sequenz. Der Rundown ist eine Ansicht einer Story; SOM trägt die Story, von der er eine Ansicht ist. |
| MOS | Gerätesteuerung, Rundown-Elemente | MOS-Verbindungen bleiben, mit einer Bridge, die sie mit dem Story-Kontext vertraut macht. |
| TAMS BBC R&D Time Addressable Media Store | Die Frames | SOM hält fest, was die Frames für die Story bedeuten. Ein Hold heftet sich über tams://-Source und Zeitbereich an genau die Frames, die er blockiert; ein Zitat kennt seine In- und Out-Punkte; welche Frames welches Publikum erreicht haben, wird zu einer Abfrage. |
| MAM / andere Speicher | Essenz, Renditions, Abruf | Dasselbe Muster über einen locator (store + ref). Medien in SOM sind beliebige Medien, nicht nur TAMS. |
| Agents & MCP | Was auch immer Sie gebaut haben | Bleibt. Generative Ausgaben, die veröffentlicht werden, sind ein assets[]-Eintrag mit Urheberschafts-provenance; Behauptungen über Inhalte sind assertions[] mit einem Review-Status. |
Was SOM nicht ist: die Medien, der Rundown, ein MAM, ein Produkt, Software, ein Ersatz für irgendetwas, das Sie betreiben, oder Eigentum eines Herstellers. Wie das Projekt es formuliert: Ein Standard, der einem Hersteller gehört, ist ein Produkt; einer, der einer Branche gehört, ist Infrastruktur.
Das Envelope
Jede Nachricht teilt sich eine Hülle
Ein geschlossenes Objekt – unbekannte Felder auf oberster Ebene scheitern an der Validierung. Klicken Sie auf einen Schlüssel, um zu lesen, was er bedeutet.
som_version
Die Version des Schema-Pakets, der das Payload entspricht — "1.0.0" für SOM 1.0.
Rein informativ: Consumer DÜRFEN NICHT danach verzweigen. "0.3.2" ist nicht SOM 1.0 — drei Felder wurden vor der Ratifizierung zurückgezogen —, ein Consumer darf es also nicht als konform behandeln.
Die Regeln, die wehtun. Senden Sie som_version: "1.0.0" und verzweigen Sie nie danach. message_type ist das einzige Unterscheidungsmerkmal. correlation_id ist Pflicht. topic beginnt mit som. Schalten Sie die Format-Assertion (format) ein – die meisten Validatoren akzeptieren stillschweigend eine message_id, die keine UUID ist. Vollständige Envelope-Referenz →
In Zahlen
Die Gestalt des Standards
Mitwirkende
Von der Branche gebaut, für die Branche veröffentlicht
SOM wurde öffentlich in Form gestritten – zwei Hackathons, eine wöchentliche Arbeitsgruppe und sechs Monate vom Kick-off bis zum funktionierenden Bus – und als Version 1.0 am 12. September 2026 auf der IBC in Amsterdam veröffentlicht.
Die Autoren sind Jon Roberts, Morag McIntosh, Alex Bassett und John Boucklos. Jon Roberts, Morag McIntosh und Alex Bassett haben das Modell konzipiert und das Projekt geleitet, gemeinsam mit Brian Hopman von AP; John Boucklos hat die Spezifikation mitverfasst, das Schema bis 1.0 geführt und die Validatoren sowie das Repository gebaut.
BBC R&D arbeitete an der TAMS-Schnittstelle. Google Cloud war Titelsponsor des Accelerator-Projekts; Amazon Web Services stellte den Referenz-Bus, das Dashboard und den TAMS-Speicher bereit; The Associated Press und The Weather Company lieferten Daten.
Keine Gebühr und nichts zu unterschreiben. Schemas, Beispiele, Tools und Skills stehen unter Apache 2.0; der Spezifikationstext unter CC BY 4.0. Diese Lizenzen sind die gesamten Bedingungen.
Der Accelerator ist vorbei; die Arbeitsgruppe nicht. Sie steht allen offen, die das Modell implementieren oder davon betroffen sind, und jede Änderung kommt als Pull Request, den jeder eröffnen kann.
Champions · 14
- ITN
- NBCUniversal
- Associated Press
- Channel 4
- Al Jazeera
- The Washington Post
- ITV
- BBC
- Sky
- EBU
- SMPTE
- Reuters
- Scripps
- GC-SC (Global Creative & Security Community)
Teilnehmer · 17
- Shure
- EVS
- Cuez
- Moments Lab
- Perspective Media Group
- Google Cloud
- Trint
- Cognizant
- Amazon Web Services
- Electric Sheep
- Nuvelics
- Octopus
- Fonn Group
- The Weather Company
- HyperContent AI
- LiveU
- Vizrt
Liste wie verzeichnet in der CONTRIBUTORS.md ↗ der Spezifikation.
Häufige Fragen
Bevor Sie fragen
Handelt irgendetwas von selbst?
Nein. Ein Skill deklariert, was über eine Story wahr ist; das Tool, dem der Executor gehört, entscheidet, was daraus folgt; ein Mensch gibt alles frei, was ein Publikum erreicht. Eine Freigabe gilt für eine bestimmte Fassung des Textes – eine Überarbeitung öffnet das Gate also wieder, statt die Freigabe zu erben. Lässt sich eine Regel nicht auswerten, bleibt die Ausgabe, die sie schützt, zurückgehalten, und ein Mensch entscheidet.
Geht es darum, Journalisten zu ersetzen?
Es geht darum, ihr Urteil festzuhalten. Die Entscheidungen, die eine Story prägen, gibt es längst – in einem Chat-Verlauf, einem Rebriefing, im Kopf von jemandem – und mit der nächsten Schicht sind sie verschwunden. Werden sie in die Story geschrieben, ist jede Entscheidung dokumentiert und der Person zugeordnet, die sie getroffen hat. Der Mensch trägt keinen Zustand mehr zwischen Systemen hin und her, sondern trifft die Entscheidung.
Was hindert zwei Systeme daran, widersprüchliche Fassungen derselben Story zu schreiben?
Ein einziger Schreiber. Das Story-Management-System des Publishers legt die Story an und besitzt ihre sequence_number – niemals die Agentur, nicht einmal bei einem Flash. Alle anderen tragen über ihre eigene Nachrichtenfamilie bei. Wo Skills sich widersprechen, verbinden sich Gates per Konjunktion (ein einziger Hold heißt: zurückgehalten), Compliance ist fail-closed, und eine Transformation hebt niemals einen Hold auf.
Wer betreibt den Bus, und was passiert, wenn er ausfällt?
Jede Redaktion betreibt ihren eigenen, wie jede andere Messaging-Infrastruktur im Haus. Fällt er aus, arbeiten die Tools eigenständig weiter wie heute und gleichen sich nach dem Wiederverbinden ab – nichts hängt am Bus, um auf Sendung zu bleiben. Weil die Story immer vollständig neu veröffentlicht wird, liest ein zurückkehrendes Tool ein einziges Objekt und ist auf dem aktuellen Stand.
Ist SOM an Kafka oder an einen bestimmten Broker gebunden?
Nein. SOM definiert ein Envelope und sieben Payload-Familien, die über einen gewöhnlichen Publish/Subscribe-Bus laufen. Die einzige Topic-Regel: Ein Topic beginnt mit som. – und ein Consumer leitet den Payload-Typ ohnehin nie aus dem Topic ab; message_type ist das einzige Unterscheidungsmerkmal.
Warum nicht einfach ein Modell auf die vorhandenen Systeme ansetzen?
Eine Retrieval-Abfrage beantwortet eine einzelne Frage für ein einzelnes Tool, und niemand sonst sieht die Antwort. Eine Produktion braucht das Gegenteil: einen Zustand, den jedes Tool identisch liest, Gates, die auch dann noch halten, wenn die Arbeit von einem Hersteller zum nächsten wechselt, und eine zugeordnete Aufzeichnung jeder Entscheidung. Die Position des Standards: Modelle sind Consumer von SOM, kein Ersatz dafür.
Laufen Medien über den Bus?
Niemals. Assets sind Referenzen. An der TAMS-Schnittstelle verweist eine Story auf eine Source-URI und einen Zeitbereich; ein MAM oder jeder andere Speicher wird auf dieselbe Weise über einen locator adressiert. Medien werden beim redaktionellen Akt an eine Story gebunden, niemals beim Ingest.
Was wird aus den Systemen, die wir schon betreiben?
Sie bleiben. SOM ist kein MAM, kein Rundown und kein Produkt und ersetzt nichts. MOS funktioniert weiter, mit einer Bridge, die es klüger macht, und was Sie mit Agents gebaut haben, bleibt Ihres. Ein einziges System genügt für den Anfang.
Wie füge ich ein Feld hinzu, das die Spezifikation nicht vorsieht?
Legen Sie es unter extensions["com.{vendor}.{field}"] ab. Consumer MÜSSEN Extension-Schlüssel ignorieren, die sie nicht kennen, und DÜRFEN die Nachricht deswegen NICHT zurückweisen. Herstellereigene Enum-Werte verwenden stattdessen das Präfix x- – x-graphics_pack.
Warum vollständige Snapshots statt Deltas?
Weil Consumer spät dazukommen, neu starten und Nachrichten verpassen. Eine story.context-Nachricht ist der vollständige Zustand der Story, Weglassen bedeutet also nicht vorhanden, nicht unverändert. Ein Schreiber, der nur seine eigenen Felder sendet, löscht stillschweigend die Arbeit aller anderen – die Konformitätserklärung nennt das den folgenschwersten Fehler, den eine Implementierung machen kann.
Wie ändert sich der Standard, und wer entscheidet?
Öffentlich. Jede Änderung kommt als Pull Request an storyobjectmodel/som, und jeder darf einen eröffnen. Innerhalb von 1.x werden nur additive Änderungen veröffentlicht; Entfernen oder Umbenennen wartet auf 2.0, und ein als veraltet markiertes Feld funktioniert bis dahin weiter. Was noch nicht geklärt ist, steht im Open Register.
Wem gehört er?
Niemandem. Der Standard ist offen und herrenlos. Schemas, Beispiele, Tools und Skills stehen unter Apache 2.0; der Spezifikationstext unter CC BY 4.0. Es gibt keine Gebühr und nichts zu unterschreiben.
Was ist Story Archaeology?
Die Methode, aus der das Modell hervorging. Man nimmt eine echte Story nach der Ausstrahlung und verfolgt, wie ihr Kontext tatsächlich wanderte, Station für Station, zwischen Menschen und Systemen – wo Wissen entstand, wo es verloren ging und wer es von Hand weitertrug. Story, Asset und Telling wurden aus diesen Sitzungen abgeschrieben, nicht erfunden.
Weiterlesen
Direkt aus der Quelle
Diese Website ist ein inoffizieller, sekundärer Leitfaden. Dies sind die Primärquellen – die ersten drei sind der Standard selbst.
storyobjectmodel.com ↗
Die Sicht des Standards auf sich selbst, die beiden IBC-Demonstrationen, Prinzipien, FAQ, wie man mitmacht, der Live-Emulator und die Schemas unter ihren dauerhaften URLs.
GitHub – das Spezifikations-Repository · SOM 1.0 · 12. September 2026storyobjectmodel/som ↗
Die sieben normativen Schemas, 18 ausgearbeitete Beispiele und 20 Fälle, die abgelehnt werden müssen, die Validatoren, die Skill-Bibliothek sowie die Dokumente zu Konformität, Kompatibilität und Migration.
Jon Roberts, für die Autoren · September 2026Introduction and principles ↗
Warum die Story nie ein Modell hatte, Medien und Steuerung aber schon, die drei Substantive und die sechs Prinzipien, die jede künftige Änderung bestehen muss.
TVBEurope – Milan Varga, Octopus Newsroom · September 2026Transforming newsrooms with agentic workflows ↗
Der Bericht eines Beteiligten über das Projekt und das Provenienz-Argument, warum sich ein Sender dafür interessieren sollte.
AP Workflow Solutions – Brian Hopman · 2026The next newsroom coordination problem ↗
Warum MOS nicht das ist, was ersetzt wird, und wo sich die Grenze zwischen SOM und Skills schwer ziehen lässt.
TVBEurope – Ash Ellis, Moments Lab · September 2026Solving the story context gap ↗
Was es für einen Hersteller bedeutet, auf den Bus zu veröffentlichen, statt Inhalte zwischen Schnittstellen weiterzureichen.
Octopus Newsroom – Interview mit Milan Varga · 2026Writing an open standard for story context ↗
Die Entstehungsgeschichte: Die Bedeutung einer Story wurde nie in einer Form aufgeschrieben, die sich weitergeben ließ.
Trint – Tessa Kaday · August 2026The Smart Stories Project at IBC Accelerator ↗
Die Kurzfassung, geschrieben vor den IBC-Demonstrationen.
IBC Accelerator · 2026Incubator 2026: SMART STORIES — the agentic production ecosystem ↗
Die Projektseite des Accelerators, so wie das Programm sie festhält.
Lesen Sie es. Bauen Sie dagegen. Sagen Sie, was bricht.
Die Spezifikation ist veröffentlicht und frei implementierbar. Wenn Sie dagegen entwickeln, Skills schreiben, eine Story-Archaeology-Sitzung durchführen oder der Arbeitsgruppe beitreten möchten, wenden Sie sich direkt an das Projekt.