Stand-ins

Available now Most publishers evaluating SOM have no vendors on the bus yet,

and their vendors wait to see whether the publisher cares. A stand-in is a reference system run by HyperContent that plays one role in a house rehearsal, so a brand-new house can rehearse "a breaking story" and see every step answered before any vendor has connected.

The stand-ins

Stand-in	Producer	What it does in a rehearsal
Newsroom system	sombus-standin-ncs	Owns the story: publishes every story.context snapshot the workflow gives the newsroom system
Web CMS	sombus-standin-cms	Receives story snapshots, tellings and skill warnings
Graphics	sombus-standin-graphics	Books and withdraws lower thirds (link.committed, link.withdrawn)
Playout	sombus-standin-playout	Airs cleared links: telling.started, telling.ended
Media store	sombus-standin-mam	Announces arriving media (delivery.media_available) and files tip-line clips
Skill executor	sombus-standin-skill	Publishes the workflow's scripted skill.warning.raised messages. In the rehearsal's skills step it also runs HyperContent's reference raise-flag-on-match on your configured instances of that skill that no executor runs, with your values. It never edits a story

Each stand-in publishes only what that system would be granted in a house. The graphics stand-in, for example, can book a lower third but never clear its gate, so that step of the standards-gate workflow is refused by the bus, as the workflow says.

The standards desk and automation have no stand-in: the rehearsal reads their parts itself.

The skill executor stand-in's scripted warnings, in the tip-line and AI-skill workflows, don't come from your configured instances. Your instances are tested in the skills step: by your executor where one is bound, else by the stand-in for raise-flag-on-match. For any other skill with no executor, the step says that nothing ran it.

Turn them on

On the Rehearsal page, under Who plays each part, an admin or owner turns each stand-in on or off. The change is recorded in your workspace's audit log. A stand-in that is on plays its part in every rehearsal where no connection of yours holds its role.

They step aside

When you cast one of your house's connections in a role (a vendor's newsroom system, say), that role's stand-in steps aside by itself, and your audit log records it. From the next rehearsal, that step is your vendor's: it is cued, and you see its connection's counts. If the connection ends, or you take it out of the cast, the stand-in plays the part again. So the rehearsal keeps working as your house fills up.

In the skills step, what counts is the binding, not the cast: the stand-in runs a configured instance only while no active executor is bound to it. Bind the instance to your vendor's executor on House skills and, from the next rehearsal, that executor's warnings are the ones counted.

The demo newsroom plays the same parts, and a few more, as a made-up newsroom of its own, with synthetic stories you can play at any time.

What they are, and aren't

• Clearly labelled. Everywhere they appear (the Rehearsal page, your story timeline, your vendors' consumers) they carry their own producer id, sombus-standin-<role>, and system id.
• Synthetic content only. They publish the workflow's own synthetic stories, never anything else.
• Only during a rehearsal. They live inside the rehearsal, not in your house: they hold no queue, no credential and no subscription, answer only the rehearsal's script, and nothing a vendor sends can make them publish.
• House traffic. Their accepted messages are delivered on your house's bus, reach your vendors' consumers whose filters match, and are in your story timeline. They count against no vendor's allowance.
• Audited and rate-limited with the rehearsal: 20 rehearsals per house per day.