Changelog

Added

• A privacy notice, sandbox terms and a legal notice are published, and every page links them from its footer. The privacy notice says what personal data the sandbox processes, why, for how long and who helps us process it, and how to use your rights, with a contact that works without signing in. The request-access form now links the terms and the privacy notice, and connecting an app links the terms it records your acceptance of.
• Your account and data, self-serve. A new Your account and data page, under People, lets you download what the portal holds about you as one JSON file: your profile, your workspaces and roles, invitations sent to your email, your notification settings, the audit log entries about you, and any access request made with your email. From the same page you can delete your own account after typing your email address. While you're a workspace's only owner, the page asks you to hand the workspace over or delete it first. A workspace's owners can delete it after typing its name. Its members lose access at once, its connections and their credentials stop working, and its queues, topic and archive are removed. A house removes its vendors first, and a vendor organisation's last vendor workspace leaves its houses. Every step is recorded in the audit log, which keeps its entries for 365 days. See Your account and data.

Changed

• Insights moved to rnd-solutions.net/insights, alongside RND's other field notes, and is no longer part of this site's menu or footer. Each article keeps its path, so an old link to /insights/… here redirects to the same article there. The RSS feed is retired; its link now opens the Insights page.
• Integrate as a vendor and the quick start now say to create your consumer connection before you publish the messages you want to read back: a connection receives only what is published after it exists, and the pull API answers 503 until its queue is ready (usually a minute, at most about 10). The Playground line now says it checks your app's grants when you choose it under Send as, and inviting your team is no longer listed as coming: owners and admins do it on the Team page.
• Access requests are now deleted 12 months after they're made, and the IP address recorded with a request is removed as soon as it's approved or rejected. Requests made before this change follow the same rule. You can also ask RND to delete your request sooner. See How long your request is kept.

Fixed

• Replay on a consumer connection now works: starting one failed at once with "AWS refused it". It replays the archived messages of the period you choose into the connection's queue.
• Apps and credentials shows a consumer or skill app as connected while it has an active consumer connection, with how many and a link to manage them under Consumer connections. It showed every such app as not connected.
• Consumer connections: a connection's actions (Replay, Redrive DLQ, Edit filters, Revoke, Remove) are now in a full-width row under it, so none is cut off at the right edge of the table.

Added

• RND support access, by your consent. A workspace owner can now let RND read the workspace for 1 hour, 1 day, 3 days or 7 days (7 days at most), from Ask RND, and revoke it at any time. While it lasts, RND engineers see the workspace's pages as a viewer does, including payloads in its story timeline, and can't change anything. In a house, RND sees vendors' connections as counts, as the house does, and nothing of a vendor's own workspace. Every page RND opens is recorded in the workspace's audit log, owners and admins see the list under What RND opened, and every owner is emailed when access starts and when it ends. Without a grant, RND still never sees payloads. See Ask RND.
• Invite your team yourself. After RND approves your organisation once, a workspace's owners and admins invite colleagues by email with a role (owner, admin, developer or viewer) from the new Team page, and resend, renew or revoke invitations: an invitation that expired is renewed for another 14 days without asking RND. They change roles and remove members; an owner can hand the workspace to a colleague, and anyone can leave. Admins manage roles up to admin, only owners make or remove owners, nobody can raise their own role, and a workspace always keeps an owner. An invitation works once, only for the invited email, for 14 days; someone new to the portal also gets a sign-in. If the invitation email can't be sent, the page says so and gives you the sign-in link to pass on. Every change is recorded in the workspace's audit log, and owners and admins see recent team changes on the page. See Your team.
• Vendors replay into and redrive their own consumer connections in a house themselves: Replay and Redrive DLQ are on the connection under Houses you're in, with the same roles and limits as in your own workspace (one of each at a time, 3 replays and 10 redrives per connection per day). The house sees on its Consumer connections page that one happened, when, and how it ended, recorded as your organisation, never your people, and no more of your messages than it could already see. See Your connections in a house.
• When a house invitation email can't be sent, the admin who sent or resent it now sees the invitation's sign-up link, with a copy button, to pass on themselves. Nobody else sees it, and it isn't kept. See Invite a vendor.
• Read a consumer queue with your own AWS role, without asking RND. On Consumer connections, a developer, admin or owner registers the IAM role on the connection; the role then proves it is yours by signing a one-time challenge with its own credentials. Once it has, the bus lets that role receive, delete and change the visibility of messages, and read the queue's attributes, on that connection's queue and dead-letter queue only, usually within a minute. Remove the role from the same page. Every step is in your workspace's audit log. Readers RND set keep working. See Read with AWS credentials.
• A new Insights article, The tools in a newsroom, by category, and where each fits in SOM: newsroom and planning systems, wires, graphics, automation, prompters, studio devices, media management, web publishing, verification, AI and dashboards, with a few examples of each and the SOM system type and messages each category uses. See the article.
• Quota tiers now apply. Each workspace has a quota (minimal, standard or high), or limits RND sets for it, and every connection in it gets that allowance on its own. The tier chosen at approval now takes effect: a vendor invited by a publisher starts on minimal (10 requests a second, 25,000 a day). Workspaces approved earlier keep today's standard limits. A vendor's connections in a house get the vendor's quota, never the house's. To get more, ask RND: a change reaches your existing connections within seconds, with no new credentials. See Quota tiers.
• Vendors now get notification emails about their own connections in the houses they joined, from their own vendor workspace: a rotated secret's overlap ending, a connection near its daily allowance, a consumer's growing dead-letter queue or lag, and a new Refusals in houses email when a quarter or more of a connection's messages in an hour were refused, naming the rules that refused them. Your workspace's choice of who gets each email, your lag threshold and the unsubscribe links apply, and each email links to Houses you're in. They never mention other vendors' connections or the house's own; the house still sees counts only.
• House health emails: a house now hears when one of its vendors' producer connections goes silent (it was sending and has sent nothing for 12 hours), comes back, or has 25% or more of its messages in an hour refused. Admins and owners choose the hours (1 to 168) and the percentage (1% to 100%) under Notifications, where the new Vendor connections email has the same choice of who gets it and the same unsubscribe link as the others. The emails carry ids and counts only, never which rules refused the messages. A house's own connections keep their usual emails.
• Coverage for publishers: a matrix of every app in your house, yours and your vendors', against the SOM message families, the suite's consumer scenarios and its skill cases. It is built only from the results statements your vendors chose to share with your organisation and from your house's own traffic in the last 7 days, counted per connection and family. A producer is covered by messages of a family accepted in your house; a consumer or skill executor by a shared statement. Every gap says why it is one and links to the docs page that explains what it needs; a case pending spec is never a gap. A statement kept private, shared only by link or with another publisher, revoked or expired never shows. It works on a phone, one card per app. See Reading the coverage matrix.
• Export your house as a bus config: owners and admins download it from the Routing map as a YAML file, the file RND will use to build your private production bus when you go live. It holds every active connection's grants and filters (message types, sources, topic prefix), your organisation's identities (proven AWS principals, your identity provider's clients) and your story ownership setting, and routes exactly as your house does. It never holds secrets, tokens, messages or payloads, nor another organisation's identities. What it can't express yet (credentials issued by the bus, pull API credentials, per-connection quotas) is listed at the top of the file with the connections it affects. Every download is in the audit log. Going live itself is arranged with RND. See the new Going live, and exporting your house page in the docs.
• House skills: a publisher's house registers the skills it runs, from the SOM skill library 0.2.2, each with its own values, instance label and authority scale (most senior first), and binds each to a vendor's skill executor connected into the house. The bus checks every value against the skill's configuration when you register it, including that every field it reads from the story is a field of SOM 1.0 story.context. The new Your house: skills page shows the chain: which executor runs each skill, which of its trigger message types it's subscribed to and who publishes them, and where its warnings can come from. Members read it; owners and admins register, edit, bind and remove.
• Skill executors read their registrations from the bus: GET /v1/tenants/{t}/consumers/{c}/skills, with the connection's own pull-API credential. An executor gets only the configured instances bound to its connection, never another's. A story's skills_config.active_skills narrows which of them run on it (RND positions P-04 and P-16 are now decided).
• The house export includes your house skills: every active configured instance, with its values, authority scale and the executor that runs it, in a new skills section of the bus config. A bus config checks each one as a registration is checked. An instance whose executor isn't in the file is exported unbound and listed at the top of the file. Bus configs without a skills section are unchanged.
• House rehearsals: a publisher plays one of the newsroom workflows (a breaking story, media arriving, a tip-line clip, a standards gate, an AI skill, a killed story) through its house, and watches on the new Rehearsal page which system played each step and what the bus did with every message, refusals and their rules included. Every member can watch, viewers too; developers start a rehearsal. Its synthetic messages reach every connected vendor's consumers, from the producer sombus-rehearsal, and every vendor in the house is told, in its audit log and on its Houses page. A connection the house casts in a role plays that part: the rehearsal cues it and shows its counts of accepted, refused and duplicate messages, never its verdict detail. One rehearsal at a time, 20 a day per house, each in the audit log.
• Stand-ins: RND reference systems for the newsroom system, web CMS, graphics, playout, media store and the raise-flag-on-match skill executor play the roles no vendor holds yet, so a new house can rehearse a breaking story and see every step answered before its first vendor connects. An admin turns each on; a stand-in steps aside by itself (noted in the audit log) when the house casts a connection in its role, and plays again if that connection ends. They are labelled "stand-in" everywhere, publish as sombus-standin-<role> with synthetic content only, and exist only while a rehearsal plays.
• Reset a house: an admin clears its story state and story timeline, and the messages waiting in every consumer connection's queue and dead-letter queue, after a confirmation that names each connection affected. Grants and connections stay; vendors are told. Five a day per house.
• A Publishers section in the docs, for newsrooms evaluating SOM and their vendors: the publisher track, seven steps from mapping your newsroom to going live (map, set up your house, bring in vendors, rehearse workflows end to end, observe, evaluate vendors, go live), which starts before any vendor has connected. Four pages on skills from the newsroom's side: what a skill is to a newsroom and who acts on a warning, configuring your house's skills, which vendor executors cover them, and adding skill cases to your end-to-end runs, the standards gate first. The vendor pages on readiness, results statements and skills now link to their publisher counterparts.
• A Routing map in the portal: for each message type, which connections of your workspace publish it and which consumer connections receive it, with the organisation that owns each, worked out from producer grants and consumer filters (message types, sources, topic prefix) the way delivery matches them. It reads as a list on a phone: "When the newsroom system publishes story.context, it goes to the web CMS and playout graphics". Every member can read it; it shows no messages or verdicts.
• A Playground dry run the gateway accepts now names its receivers: the consumer connections whose filters match the message. Nothing is delivered.
• A workbench for every publisher organisation: its own vendor-type workspace, labelled "Workbench — grade your in-house apps", where it grades its in-house systems (its CMS, its own tools) with test runs, which never run in a house. It is created with the house when RND approves a publisher, and publishers approved earlier get theirs the next time an owner of the house opens the portal. The same app connects to the workbench to be graded and to the house to work, each connection with its own client secret. Results statements made in the workbench can be shared with your own house, in one click, or with another publisher. Its Overview explains it and has its own first steps: create an app, connect it, grade it with a test run, make a statement.
• Consumer connections can be routed by source: receive only what some producers send, such as story.context only from your newsroom system. Name producer connections of your workspace (shown by app and organisation) or originating_system.system_ids, when you create a connection or later. Revoking a producer connection that a consumer filter names now warns first.
• Edit a consumer connection's filters in place: its message types, topic prefix and sources. The queue, its messages, its dead-letter queue and its client secret stay; every change is in the audit log with the filter before and after. Until now a filter could only be changed by removing the connection.
• Every message carries a new system_id attribute, its envelope's originating_system.system_id, alongside producer_id.
• SOM fit check, in the portal under Test, for every workspace: paste one of your own stories, in any shape, and see whether it fits SOM 1.0 before you write a producer. A SOM message is checked exactly as the gateway would check it, with each failure explained in plain words and the field it points at. A story in your own shape gets suggested mappings onto story.context (by field names and types, the same answer every time, no AI), the required fields it is missing, the values that wouldn't pass, and a starter story.context message you can open in the Playground. Nothing you paste is stored or logged: use synthetic content only. See the new SOM fit check page in the docs.
• Houses: publishers bring their vendors into their own sandbox. On Your house: vendors, a publisher's owners and admins invite a vendor by email (single use, for that address only, 14 days, with limits per house) or pick one from the vendor directory. A vendor new to the bus gets a pre-approved sign-up in the email: its access request is approved at once, on the minimal tier. The vendor asks to connect its apps, and the publisher grants what each may publish or receive, or less, or rejects it with a reason. Either side can disconnect, after seeing what is kept and for how long.
• For vendors, Houses you're in: accept an invitation after reading the house terms, connect your producer, consumer and skill apps, get and rotate their client secrets yourself (the publisher never sees them), see your own connections' decisions in each house in full, and leave. List your organisation in the vendor directory if you want publishers to find you; it's off unless you turn it on.
• New docs: Bring your vendors into your house, Join a publisher's house and Who sees what in a house.
• A new Insights article, The story-centric newsroom workflow, from the wire to every platform, in SOM: how a newsroom turns wires, the diary and tips into stories told on every platform, who does each step, and where each step lives in SOM 1.0, with four new diagrams.
• Story ownership: the first system to publish a story owns it, and your workspace lists which systems may take a story over from which (for example, from the newsroom system to the web CMS). A snapshot from any other system gets the new story.not_owner rule. Each workspace chooses to warn (the default: the snapshot is accepted and the rule is listed under tolerated), refuse it, or not check. Admins and owners set the mode and the hand-offs on the new Story ownership page in the portal; every change is recorded in the workspace's audit log. The Playground judges ownership with your workspace's setting. See Concepts, Story ownership, and the rule's page.
• Replay and dead-letter redrive in the portal. Under Consumer connections, developers, admins and owners can replay a time range from the bus archive into one of their connections' queues (within the archive's 30 days on the Sandbox, 7 on Preview), and move a connection's dead-letter queue back to its queue, all of it or up to 100 messages. Only that connection receives a replay, through its own filter, in order per story. One replay and one redrive at a time per connection, with a daily limit; each start and finish is recorded in the workspace's audit log. In a workspace shared with other organisations, each organisation replays and redrives only its own connections.
• A new notification email, Replay and redrive: sent when a replay or redrive finishes, fails or is cancelled. It goes to developers and up unless your admins choose otherwise.
• The SOM 1.0 schema reference, in the docs under Schema: every field of every SOM 1.0 message family, pinned to the exact schemas the bus validates against. Each field shows its type, whether it's required, its allowed values, an example from the SOM examples, the checks the bus runs on it, and what it means. Every meaning links to its source: the schema, the SOM specification, the SOM glossary, or this bus. Fields SOM does not yet define are marked as such, not guessed. Each schema also lists the SOM must-reject messages and the rule the bus reports for each.
• The SOM glossary in the docs: all 159 terms of the working group's glossary, each with its status and where it appears in the SOM 1.0 schema, including where the glossary and the schema differ.

Changed

• The temporary-password email for a new portal account now says to ask whoever invited you if it expires, rather than an RND admin.
• Another organisation's app that RND connected into your workspace directly is now disconnected, not revoked: an owner or admin presses Disconnect on Apps and credentials or Consumer connections, after reading what happens, and it is recorded in both organisations' audit logs. Its client secret is left as it is; revoking that connection or its secret is no longer possible, as for a vendor's connection in a house. A consumer's queue is kept. See Another organisation's app RND connected.
• The docs now have two tracks. The header reads Start here, Vendors, Publishers, Concepts, Schema and Reference, and each track has its own menu, grouped in the order you'll need it: vendors go from the whole journey through building a producer and a consumer, skills, testing and joining a house; publishers go through the seven-step publisher track, the house pages in the portal and skills in the newsroom. Concepts, the schema, the reference and help are shared by both. Every page keeps its address.
• The workflows page, the landing page and What's next now show rehearsing a workflow in your house as available, where they said it was next.
• system_ids starting with sombus- are reserved for the bus's own rehearsal systems: a connection asking for one is refused.
• Replay and dead-letter redrive are no longer done by RND on request: the docs and the newsroom workflows now show them as available in the portal.
• Public pages and docs now say only what the bus does today. For publishers: a private production bus (when you go live, RND runs a private bus for your newsroom, built from the house you tested) is marked Next, on the home page and on What's next alike; a publisher workspace holds synthetic content only, and shows the results statements vendors share with you. What's next marks registering your own apps and shareable results as available. Retention is stated precisely: payloads up to 30 days in the replay archive, gateway decisions 30 days, test runs 90 days, the audit log a year. Request limits and the quota.exceeded and rate.limited rule pages say per connection; revoked tokens stop within about 30 seconds and are refused with 403 producer.not_registered; message types without a SOM 1.0 schema are accepted with only the envelope checked; the quick start keeps one correlation_id per story. Smaller corrections across the docs: who registers identity providers (owners), the principal verify answers, test-run attributes on the pull API, the consumer tests, envelope fields and SDK retries.
• In a house, every portal page shows another organisation's connection as counts: accepted, refused and duplicate messages, and when it was last seen. Its rule ids, refused messages, credentials and people stay with that organisation. Accepted messages still show in the house's story timeline. Overview adds counts per connection for your own workspace too, and a vendor's connection never ticks off the publisher's first steps.
• Sharing a results statement with a publisher: pick the publisher of a house you're in, instead of typing its organisation id.
• Insights articles are easier to read, in the same type as rnd-solutions.net: larger body text (18px with more generous line spacing), a larger standfirst and headings, larger tables and captions, and table row labels in readable type. Diagrams now show at their full size beside the text instead of shrinking into the column, and open full size when you tap or click them.
• The workflows page now says how story ownership works: the first system to publish a story owns it, your workspace lists hand-offs, and a snapshot from any other system is flagged or, if you choose, refused.
• A tidier menu on desktop. The home page header fits on one line again: its sections (What is SOM?, for vendors, for publishers, how it works) sit under one About menu, and narrower laptop screens get the Menu button. The portal's side menu is more compact, scrolls on its own on short screens, and its first group is now called Monitor.
• Fonts are now served from SOM Managed Bus itself: the site, the docs, the changelog and insights no longer contact Google, or any other third party, when they load. They look the same as before.
• Browsers are now told to reach every subdomain of the site over HTTPS only, not just the site itself.
• A smoother path from your first app to your first publish. The portal menu now follows the order you work in: Set up (Apps and credentials, Consumer connections) comes before Test (SOM fit check, Playground, Test runs, Results statements). In the Playground, one Send as picker chooses the producer app for both the dry run and Publish for real; with one producer connected it's already chosen, the examples carry its system_id, and the dry run now checks its grants too, as a publish would. After an accepted publish, the Playground links to the story and to reading it from a consumer queue. See The Playground.
• No more pasting a secret you were just shown. When you connect an app or rotate its secret, that browser tab keeps the secret in memory until you reload or sign out, and the Playground publishes with it, shown masked. The portal server still never stores it. See First steps.
• Buttons that can't be used yet say why, such as a missing name, message type or client secret. The consumer connection form says when your only apps are producers and links to creating a consumer app with the right kind chosen.

Fixed

• The article on newsroom tools by category is more precise: SOM names one owner per story rather than one writer, Ross's newsroom system is listed as Indigo | Editorial (formerly Inception), Cue is not described as headless, and a few lists and labels are corrected.
• Consumer queue emails (a growing dead-letter queue, or a message waiting past your lag threshold) now reach connections read over the HTTPS pull API with a client secret. Before, only connections with an AWS reader set by RND got them.
• The RND positions page now marks P-15 as decided, as it is applied: a skill harness case fails at 30 seconds, and the 5 seconds to emit stays a recommendation the bus doesn't check.
• A missing file under the docs' assets now answers "404 Not Found", like a missing docs page, instead of "403 Forbidden".
• A message the bus recorded but never published (its function stopped between the two steps, or a failed publish couldn't be undone) is now published by your retry, instead of being answered 200 duplicate. A retry within 30 seconds of the first attempt gets 503 message.in_flight: retry again with backoff. A snapshot whose story has accepted a newer snapshot since is not published, so consumers never receive an older snapshot after a newer one: its retry gets 409 message.superseded. See Retries and idempotency.
• In a house, the house's Apps page can no longer revoke a vendor's producer connection or remove a vendor's pull secret. Those are ended under Your house: vendors, with its confirmation and a record on the vendor's side, or by the vendor.
• A replay whose status the bus can't read no longer stays running for good and blocks new replays. After 24 hours it's shown as failed, status unknown, and you can start another.
• A redrive of all messages that ran is no longer reported as "did not start" when the bus lost track of it; its result is read from the queue instead. A redrive of only some messages whose end wasn't recorded now says some messages may have moved.
• Redriving only some messages no longer delivers a message twice when it was sent but couldn't be removed from the dead-letter queue, as long as the next redrive comes within 5 minutes. Redrives deliver at least once; the dead-letter queue docs say so.
• The producer docs now describe a rare case: a retry answered 200 duplicate for a message that was never delivered, and what to do about it.
• Public wording corrections on the home page, the quick start, What's next, the insights articles and their link previews. Going live is described as it is planned: vendors test today, and next RND runs a private bus for each publisher's newsroom when it goes live. The quick start's 15 minutes are now "about 15 minutes of your own time, once RND has approved your access", and RND's review is the only manual step to get started; adding colleagues goes through RND for now. Access requests are reviewed by RND, rather than "by invitation". SOM 1.0 has six payload families plus the envelope, seven schemas in all. The verdict on the home page is labelled as an example. What's next names what is still planned for the story timeline (live updates, filters and comments); a publisher sees its own rejections and counts of its vendors'. In the articles: SOM is "an open standard", the newsroom sociology is dated to 1973, the Story Archaeology quotation is attributed to the SOM specification, and the MOS Group's "more than 150 companies" is dated to 2021.
• Preview pages now carry a noindex robots tag in the page itself, as well as in their response headers.
• House invitations: when an invitation email can't be sent, the House page now says so and what to do, instead of saying it was sent. After Resend, it mentions a new sign-up link only when one was made. Revoke on an invitation, and Decline on a house's invitation, now ask you to confirm first, and every invitation status starts with a capital letter.
• A house's per-connection counts now show refused and failed messages in separate columns, so Refused means the same on every page, and the note under them explains that a shared results statement shows a vendor's test results, not its rule ids or refused messages.
• Portal wording now matches what happens: a house reset also clears dead-letter queues (and says how many queues were skipped because a purge was already running), rehearsals and resets are noted in your vendors' audit logs and on their Houses page, replay and redrive emails depend on your Notifications settings, and notification emails can name the rules that refused messages. With no hand-offs, the Story ownership page describes what your mode actually does. The workbench is simply called Workbench in the Workspace menu.
• A docs address that doesn't exist now shows the docs' own "page not found" page instead of an error.
• The portal no longer publishes its source maps or its demo-mode sample data.
• The RND positions page no longer says the positions have been offered to the SOM working group. None has been put to it yet; the page now says we intend to offer them. P-17 now cites the SOM open register entry that lists scheme-qualified tag matching as an open question.
• Rehearsals in a house whose story ownership is set to reject: a vendor you cast as the newsroom system can now write the story the rehearsal set up, instead of every snapshot being refused as story.not_owner. The hand-off applies only to the connections cast in that role, only for the rehearsal's own stories, and never changes your ownership setting or its export.
• The skill executor stand-in's warnings now follow the executor contract: each severity is within its skill's range (the hold on the casualty figure comes from hold-while-flagged, not raise-flag-on-match), skill_warning_ref names the declaration as <rule_id>/<scope>/<n>, and every warning names its affected fields and says in plain words what it read and what clears it. The stand-in is now described as what it is: it plays the script's warnings and runs no skill.
• "One rehearsal or reset at a time" and the daily limits now hold when two people start a rehearsal or a reset at the same moment: only one gets through, and the other is told one is under way.
• A house reset now runs. Before, it was queued and never carried out.
• Activity and Overview in a house: a busy vendor connection can no longer crowd your own apps' decisions off the page, and on Houses you're in a vendor's own decisions are no longer crowded out by the house's traffic.
• The house export's header and notes no longer describe the go-live steps as settled. They now say RND will use the file to build your private bus when you go live, and that how each connection gets production credentials is still to be agreed.
• The vendor docs now match how the bus behaves. The pull API page states a consumer connection's own allowance (20 requests a second, bursts of 40, 100,000 a day). The docs now say that readers of a queue with AWS credentials get the producer's exact bytes, while the pull API returns the same envelope, parsed, and list the fields each way returns. Order is described as the order the bus published messages in, and a 202 as accepted and published for delivery. Dry runs count toward a connection's limits. A token for a revoked connection is listed under 403, not 401. Pages written before publisher houses opened no longer describe them as coming. Results read "passes som-bus suite …", as the portal words them. The AWS region is stated for the hosted Sandbox and Preview only. Smaller fixes: the client id format, a consumer secret's rotation choices, the source filter in troubleshooting, and where to find What's next.
• Publisher docs now describe what works today, and nothing more. Your private production bus is marked Next (a new status in the docs' legend): decided, not available yet. What your house is planned to carry over, and what RND will need to settle with you before going live (production credentials, throttling, identity-provider settings), are described as to be agreed. The skill executor stand-in is described as what it is: it publishes the rehearsal's scripted warnings and runs no skill, so to test your own values, cast your vendor's executor. A skill app's connection only receives; its warnings come from a producer connection of the same vendor. Support access to payloads is marked Coming: until it's built, RND never sees payloads. For a vendor's connection in your house, replay and redrive go through RND. The RND positions page now says that the 30-second limit of P-15 fails a skill harness case, and that the library's tool type isn't recorded at registration.
• A long workspace name no longer gives the portal's side menu a horizontal scrollbar; the workspace picker fits the menu and shortens the name, with the full name still in its list.
• A consumer connection's topic prefix that doesn't start with som., such as story.context, is now refused with an explanation, in the portal and when asking to join a house. Every topic starts with som., so such a prefix silently matched no message. Existing connections keep working. See Subscriptions and filters.

Added

• Insights, published at /insights: articles on running a SOM bus and how newsroom standards fit together, with an RSS feed. The first compares MOS and SOM: what each standard is for, side by side, and why a newsroom needs both.
• A vendor quick start, published at /start: on the bus in 15 minutes, as five missions. See how the gateway answers with no account, request access, get your keys, send your first message and play your part, each with one block to copy and a clear "done when". Linked from the home page and the docs.
• The home page shows a story's journey through the bus: newsroom systems publish, the bus checks, orders and delivers each message to the systems that need it, and a stale snapshot is refused at the gate. It stays still for visitors who prefer reduced motion.
• A reference skill executor for raise-flag-on-match in the developer kit, open source: run it against your vendor workspace and grade it with the skill harness in Test runs, or start your own from it. Documentation: Skills and executors, Test runs.
• Newsroom workflows, published at /workflows: seven newsroom moments (a breaking story, media arriving, a tip-line clip, a standards gate, an AI skill, killing a story, adding a new system) told message by message, with who sends what, who receives it and what the bus does at each step. A matrix shows where each kind of product takes part, and the docs have a companion page for vendors.
• This changelog, published at /changelog.
• The Playground can dry-run a message as one of the registered producers, so grant and system id problems show up before you publish.
• Ask RND: send a question, problem or idea to an RND engineer from any portal page. Replies come to your email.
• A What's next page shows what we're building, grouped for vendors, publishers and everyone.
• Documentation is published at /docs, including a page for every gateway rule: what it means and how to fix it. Rule ids in the portal's Playground, Activity, story timeline and Overview link to their page.
• Access requests are reviewed in the portal, and applicants get the decision by email.
• The bus's own token service and workspace routes are documented, and RND can now issue client ids and secrets for them to vendors: get a token, then publish or dry-run messages in your workspace.
• A firewall and rate limits protect the bus API. Each connection has its own request rate and daily allowance on the workspace routes. Over a limit, the bus answers 429 with the rule rate.limited or quota.exceeded; a request refused by the firewall answers 403 request.blocked. Limits are listed in the docs.
• Your own workspace in the portal. Once your access request is approved you're invited to the portal and to your workspace: sign in and accept the invitation. Overview, Activity, the story timeline, the Playground and Apps then show only your workspace.
• If you're in several workspaces, switch between them from the Workspace menu.
• Producer apps are self-serve. In your workspace's Apps page, developers, admins and owners create an app, claim the system_ids it stamps (unique across the bus), choose the message types it may publish, and connect it to get its client id and secret, shown once. No request to RND and no deploy.
• Rotate a client secret with an overlap of your choice: the previous secret keeps getting tokens until the overlap ends (or you stop it early), while tokens issued before the rotation stop working within about 30 seconds. Revoke a connection to stop its secret at once and its tokens within about 30 seconds, then connect the app again for a new credential. Every change is in the workspace's audit log.
• Access tokens from the bus's token service carry a credential_version claim.
• Documentation: Producers › Credentials.
• Consumer connections in the portal: connect one of your apps to read your workspace's messages from its own queue and dead-letter queue, choosing the message types and an optional topic prefix. See the queue's status and depth, and revoke (the queue and its messages are kept), restore or remove it yourself. RND sets who may read each queue. Every change is in your workspace's audit log.
• Consumers can read their messages over HTTPS, with no AWS account. In Consumer connections, get a client id and secret for a connection (shown once), then receive up to 10 messages at a time (long-polling up to 20 seconds) and acknowledge or release them. Order per story and at-least-once delivery are as before. Rotate or revoke the secret as a producer's; a revoked connection can't read. See "HTTPS pull API" in the docs.
• A first-steps checklist on a new workspace's Overview: request access, sign in, create an app, get credentials, dry-run a message, publish it, see it in the story timeline. Each step ticks itself from your workspace's data and links to its page and docs. Hide it whenever you like.
• Publish for real from the Playground: developers choose one of their apps, paste its client secret and publish the message through their workspace's API. The secret is used once, for that request, and never stored, logged or kept in your browser. Available where client secrets are issued in the portal. Documentation: Get started › First steps.
• Test runs in vendor workspaces. The portal's Test runs page plays the suite som-1.0.0+lib-0.2.2 into your workspace: consumer scenarios (replay, duplicates, a late snapshot, unknown types and extensions, SOM 1.1.0 messages) and skill harness cases for a raise-flag-on-match executor. Every case shows what was expected, what your app did, and what the check rests on; cases that need a message SOM 1.0 doesn't define are shown as pending spec. Consumers report their end state from the page. Every run is recorded in the workspace's audit log.
• Documentation: Test › Test runs.
• Results statements: a vendor turns complete, passing test runs into a statement, for one of its apps, of exactly what passed ("passes som-bus suite som-1.0.0+lib-0.2.2", never "certified"), shares it with a publisher organisation or by a link, each until a date it chooses, and revokes either at any time. Publishers see what is shared with them in the portal; a link opens a public page that shows the statement and until when it is valid, or only a notice once it has ended. Every change, and every opening of a link, is in the workspace's audit log. Documentation: Test › Results statements.
• Notification emails about your workspace's own connections: a rotated secret's overlap ending, a connection at 80% of its daily allowance, and a consumer queue whose dead-letter queue is growing or whose oldest message has waited too long. Emails carry ids and counts only, never message contents or secrets. By default they go to the workspace's owners; admins and owners choose who gets each one and the lag threshold on the new Notifications page, and everyone can turn any of them off, in the portal or with the unsubscribe link in every email. Every change and every email sent is in the audit log.
• A "test run finished" email: when a test run in your workspace completes or stops with an error, the people the workspace chose get its pass and fail counts and a link to the run.
• Links from the portal's emails open the workspace they're about.
• Documentation: Help › Notifications.
• Producers that run in AWS can publish as their IAM role, with no secret to store. Register the role on a connection under Sign-in methods, prove it's yours by running the one-time verify command the portal shows (signed with the role), then sign requests to /v1/tenants/{t}/iam/messages and /iam/validate. A role awaiting proof is refused with the new rule principal.not_verified. Signed requests share one rate limit across all AWS signers for now; a per-connection allowance is planned.
• Bring your own identity provider: a workspace owner registers your organisation's OpenID provider (up to three), then a developer binds a client to a connection by pasting a fresh token it got. Its tokens then publish to that connection's workspace, and only there; the bus trusts your provider for your organisation's connections only.
• Revoking a connection also ends its AWS role and identity-provider client, and frees them for a new connection. Registering, verifying, binding and removing them is recorded in the audit log.
• Documentation: Producers › Authenticate.
• The documentation covers every part of the vendor journey: planning your integration, credentials and authentication, a first message and a whole story, the bus's answers, retries and error paths; consumer connections, filters, ordering, dead-letter queues and replay; skills and executors, with RND's positions; the Playground, test runs, results statements and a readiness checklist; a preview of the SDKs; troubleshooting and a glossary. Every page says what you do yourself and what still goes through RND.
• The developer kit, sombus-dev-kit, open source under Apache 2.0: the SDK design, the conformance kit, the TypeScript SDK's first slice, and a reference producer and consumer to run against your vendor workspace. Nothing is on npm yet. Documentation: SDKs.

Changed

• The RND Solutions rd mark is back: the portal, the public pages, the docs and the sign-in page carry it, and it is the site icon, the app icon and part of the share image.
• A 429 from the bus now has the usual { "accepted": false, "violations": [...] } body, and may carry Retry-After.
• The "Coming next" preview pages are replaced by the single What's next page; old links still work.
• The portal works on phones: a Menu button opens every section, tables show each row as a labelled card, buttons and filters are large enough to tap, and form fields no longer zoom the page on iPhone.
• The portal no longer shows everyone the whole environment's traffic: each person sees the workspaces they're a member of. Traffic from apps RND registered in the bus configuration isn't in a workspace yet; ask RND for it.
• The approval email tells you how to sign in and accept the invitation to your workspace.
• Request limits on the workspace routes apply per connection (your app in a workspace) instead of per workspace, so one busy app never spends another's allowance.

Fixed

• Phones: the home page, sign-in, Quick start, Workflows and Changelog have a Menu button with every link in the header and Request access; before, phones showed only Sign in.
• Phones: the Apps page no longer scrolls sideways; long URLs in help text wrap. Text fields, dropdowns, checkboxes and the sign-in password Show button are large enough to tap.
• Test runs: each case in Start a run reads as a normal title and description instead of small capitals.
• Docs on phones: tables show each row as a labelled card instead of a squeezed table that scrolled sideways, the menu links to the portal and the changelog, and menu entries are easier to tap.

Added

• RND admins can invite people to the portal, make them admins, and disable or remove them.
• The landing page explains the Story Object Model and links to RND's field notes on SOM.

Changed

• The product is now called SOM Managed Bus across the portal, landing page and share image.
• The landing page can be found by search engines.

Added

• The bus. A hosted SOM 1.0 bus with one conformance gateway: messages that aren't valid SOM 1.0, or that would break a story's snapshot order, are refused before any consumer sees them. Each refusal names its source (schema, conformance, sequence or policy) and a stable rule id.
• Two ways to publish. Signed AWS requests, or OAuth 2.0 client-credential tokens for systems outside AWS.
• Ordered delivery. Messages are delivered in order per story to one queue per consumer, filtered by message type, with dead-letter queues, and replay through RND.
• The portal. Sign in to see bus health, recent gateway decisions and a timeline per story, dry-run messages in the Playground, and view your app credentials.
• Request access from the landing page. RND reviews each organisation once.
• A branded sign-in page with an authenticator app as the second factor.
• A public health endpoint and a smoke test after every deployment.