Rehearse a newsroom workflow in your house

Available now A rehearsal plays one of the

newsroom workflows through your house: a breaking story, media arriving, a tip-line clip, a standards gate, an AI skill, a killed story. You watch it step by step on the portal's Rehearsal page, in your publisher workspace, and see for every step which system played its part and what the bus did with each message.

Anyone in your workspace can watch, viewers included, with no app credentials: an editorial or product lead can follow a workflow play. Developers, admins and owners start a rehearsal. Admins and owners reset the house, turn stand-ins on and decide which connection plays which part.

Want to watch the bus at work before casting anything? The demo newsroom plays made-up systems and synthetic stories through your house, one scenario at a time.

Who plays each part

Every step of a workflow belongs to a system: the newsroom system, the web CMS, graphics, playout, the media store, the skill executor, the standards desk or automation. For each rehearsal, each part is played by:

1. A connection of your house that you cast in that role. On the Rehearsal page, under Connections in your house, pick the part each active connection plays. When the rehearsal reaches that system's step, it cues it and waits 30 seconds for the vendor's own system to publish. You see the vendor's connection and how many of its messages of that type the bus accepted, refused or found to be duplicates in that window. Counts only: the detail is the vendor's (see who sees what).
2. Otherwise, that role's HyperContent stand-in, if you turned it on. It publishes the step's message itself, as sombus-standin-<role>.
3. Otherwise, the rehearsal reads the part itself, as sombus-rehearsal, so the story still reaches the systems that are connected. The standards desk and automation have no stand-in: the rehearsal reads their parts unless you cast a connection in them.

A step that people take rather than a message (the verification desk checking a clip, for example) is noted and passed. The "adding a system" workflow is done entirely in the portal, so it has nothing to rehearse.

What happens to the messages

Every message the rehearsal or a stand-in plays goes through the bus's own checks, exactly like your vendors' messages: SOM 1.0, what the role may publish, duplicates, story order and story ownership. So the steps the workflow page says are refused are refused here too, with the rule behind them: a stale snapshot, a killed story coming back, graphics trying to clear its own gate.

When you cast a connection as the newsroom system, the rehearsal still sets up the story itself (as sombus-rehearsal-ncs), and then hands it over: your cast connection's systems may write that story even when your story ownership is set to reject. This hand-off covers only the connections cast in that role and only the rehearsal's stories. It is not added to your ownership setting or to your house export.

Accepted messages go onto your house's bus like any other:

• They reach every connected vendor's consumers whose filters match, as any message in your house does. For each step the page lists the connections that received it, and the stand-ins.
• They carry the producer sombus-rehearsal or sombus-standin-<role>, so a vendor's system can tell a rehearsal from other traffic.
• Every vendor in the house is told that a rehearsal started, in its own audit log and on its Houses you're in page.
• They are recorded in your Story timeline, like any message, for 7 days.

The stories are synthetic: the SOM 1.0 hurricane run, a tip-line clip and a court story, with ids that are new for every rehearsal (hurricane-2026-0911.<rehearsal id>). Two rehearsals never meet, so you can play the same workflow again at once.

The skills step

After the workflow's last step, the rehearsal runs your house's configured skill instances on the story snapshots it just played. So you see, before going live, whether each one gets a warning back. Under Skills the page lists every configured instance that isn't paused and says, for each one:

• Who ran it.
  • Your executor, if the instance is bound to an active executor connection in your house. The rehearsal's snapshots reach that executor like any story, and the page says how many did. If none did, check that the executor subscribes to story.context.
  • The skill executor stand-in, if no executor runs the instance, the stand-in is on, and HyperContent has a reference executor for the skill. Today that is raise-flag-on-match only. The stand-in evaluates your instance's own values (the field, the value, the flag name, the severity) on each snapshot. Its warnings go through the bus's checks as sombus-standin-skill and onto your house's bus like any other message.
  • Nothing, and the page says why: the instance isn't bound (or its executor's connection has ended) and either the stand-in is off or HyperContent has no reference executor for the skill yet. Nothing is made up in its place.
• Whether warnings came back, and how many of each severity. For your executor, these are the skill.warning.raised messages carrying the instance's label as rule_id on the rehearsal's stories. They are read from your story timeline when you open the rehearsal, and counted as they arrive for 30 seconds after the rehearsal ends.
• The stories a story's skills_config leaves it out of, with the reason (narrowing per story).

A removed configured instance isn't run.

Reset the house

Reset starts the house clean. It clears:

• the story state the bus keeps for the stories your house saw in the last 7 days, so the next snapshot of a story is its first again;
• your story timeline for those stories;
• the messages waiting in every consumer connection's queue and dead-letter queue, your vendors' included.

Grants and connections stay. Before you confirm, the page names every connection whose waiting messages will be cleared, and every vendor in the house is told, in its audit log and on its Houses page.

Limits

• One rehearsal or reset at a time per house.
• 20 rehearsals and 5 resets per house per day.
• Rehearsals and resets are kept for 90 days. Starting, finishing, resetting, and every change to the stand-ins or who plays which part, is in your workspace's audit log.

Known limits

• A vendor's answer is counted by message type in its 30-second window, not matched to the rehearsal's story: a newsroom system cast in your house publishes its own stories, not the rehearsal's.
• The answers are read from the bus's decision log when you open the rehearsal, and can take a minute to appear.
• Vendors are told in the portal, not by email.
• The skills step runs on the snapshots the rehearsal or a stand-in played. When you cast a vendor's newsroom system, its own snapshots aren't among them.
• The stand-in's reference raise-flag-on-match doesn't evaluate clearances (an assertion by your clearing_authority): the rehearsal's stories carry none. A declaration closes when a later snapshot no longer matches.