Newsroom Computer Systems: Why the Rundown Breaks Ninety Seconds Before Air

Why the rundown is the most fragile object in the building

It is 5:58pm. The 6 o'clock rundown has 22 stories and a hard out at 6:28:30 for the network feed. At 5:58 the assignment desk calls in: the courthouse story is dead, the sentencing was continued. The producer kills it. That single action has to ripple through six systems in ninety seconds. The prompter has to drop the script so the anchor does not read a name that no longer belongs on air. The automation system has to drop the associated graphics events and the two-shot. The back-time has to recompute so the weather block does not get squeezed into 40 seconds. The digital producer has to pull the story off the website. In most newsrooms, at least two of those happen because a human remembered.

The stack is a newsroom computer system, a MOS gateway, a prompter chain, graphics, playout automation, an asset manager, and a separate web content management system. The newsroom computer system is meant to be the spine. In most groups it is one of several systems that each believe they own the story, connected by a protocol designed to move objects rather than to keep state consistent.

The cost is that producers spend the last twenty minutes before air reconciling systems instead of doing editorial, and digital publication lags broadcast on breaking stories because the web version gets written a second time by a second person.

Problem 1: the rundown is a live multi user document with no transactional discipline

Four people edit one rundown at once: the producer reordering, the writer editing script, the director adding automation events, the editor updating a clip duration. Vendor systems handle this with row level locking designed for thick clients on a station LAN. It stops working when a producer in another market is in the same rundown, or when the same story sits in three shows and someone edits the wrong instance.

Avid iNEWS, Dalet, Octopus Newsroom and Ross Inception all model a story as a row with attached script and MOS items. What they model poorly is the same story having broadcast, web and social instances with different lifecycles, or a group level pool where a piece produced in one market is used in another with attribution and expiry. The workaround is duplicate stories with drifting content, and by the 11 o'clock show nobody knows which copy is current.

What a custom build does: treat the story as the durable object and the rundown row as a placement of that story in a show, with its own timing, its own script variant and its own MOS bindings. Every edit is an event on an append only log, so a kill at 5:58 is a single fact that every subscriber reacts to rather than six manual actions. That log is also what lets you replay exactly what the rundown looked like at 6:04:12 when a complaint arrives three weeks later, which no vendor system gives you cleanly.

Problem 2: MOS is a protocol, not an integration

The Media Object Server protocol is the standard that lets a newsroom system talk to graphics, video servers and prompters. It works, and it is also where broadcast integration projects go to die. Most facilities run a mixture of protocol versions, and the plugin model means graphics ordering often happens inside an embedded control hosted in the newsroom client, which is why so many stations still pin workstation operating system versions to keep a graphics plugin alive.

The vendors speak MOS competently. That is not the problem. The problem is that your specific chain of graphics templates, your archive naming conventions, your automation event model and your station branding rules live in the gap between MOS messages. A MOS item tells the graphics system to play template 4102 with three text fields. It does not know that your lower third for a live remote must carry the market abbreviation, or that a killed story must also clear the ticker.

What a custom build does: put a real integration layer between the rundown and the devices, so MOS is one transport among several rather than the whole architecture. Graphics ordering becomes a typed request against your template catalogue, validated before it reaches air, with field level rules you can change without a vendor ticket. Device state gets reconciled continuously rather than assumed, so the system can tell a producer that the prompter has an older version of story 14, which is exactly the failure that produces an on air stumble.

Problem 3: digital first means the story gets written twice

Almost every newsroom now publishes digitally before or alongside broadcast, and almost none have a system where the broadcast script and the web article are the same object. The script is written for the ear in all caps with phonetic spellings and prompter markup. The article needs a headline, a deck, prose written for the eye, a cleared hero image, alt text and tags. So the digital producer rewrites it, and the two versions drift within an hour.

Vendor newsroom systems have web publishing modules. In practice they push a flattened script into a content management system and produce something nobody wants to read, which is why most digital desks turn the feature off. Ross Inception is more digitally minded than the older systems and still assumes its own publishing surface rather than the WordPress, Arc or bespoke stack a group actually runs.

What a custom build does: model one story with typed variants, where the broadcast script and the web article share sourcing, credits, media references and legal status but not prose. This is the one place a language model earns its budget in a newsroom, and only under supervision: draft the web version from the approved script, preserve every attribution, flag any sentence introducing a claim absent from the source, and route it to the digital producer for approval. Never auto publish. What you are buying is eight minutes off the clock on a breaking story, not a robot journalist.

Problem 4: back-timing and the hard out are computed in a producer's head

Timing is where the rundown becomes arithmetic. Every story has a read rate, a package duration, a tag, a toss. The show has fixed break positions and a hard out. Vendor systems total durations and show over or under, which is useful and insufficient. What producers actually need is what happens if. If the live shot fails and we fall back to the VO, where does that leave us at the C block. If the interview runs long by 45 seconds, which story is the natural drop.

Read rates are the specific gap. Every anchor reads at a different pace, and the standard words per minute constant in a vendor system is a guess. Your own system can learn actual read rates per anchor from as-run logs and apply them per story, which changes timing estimates materially on a script heavy show.

What a custom build does: continuous back-timing from the hard out, per anchor read rates learned from as-run data, and a float model where the producer marks stories as droppable with a priority order so the system can present the drop sequence rather than the producer inventing it at 6:22. Combined with the automation link from problem 2, a drop becomes one click that is consistent everywhere.

Problem 5: the archive is three archives and none of them are searchable at speed

A producer needs file of the mayor at the ribbon cutting last spring. It might be in the asset manager, on a near line array, on LTO, or in the old system nobody migrated, and the only search terms are whatever an editor typed into a slug field at 11pm. So the producer asks the room, and that is the retrieval system.

Newsroom vendors integrate with asset managers rather than solving retrieval, and the asset manager searches metadata that was never written properly. This is where speech to text and visual indexing genuinely pay: transcribe the archive once, index faces and on screen text, and let a producer search for what was said rather than what was labelled. That is a well bounded engineering job with a clear payoff, unlike most artificial intelligence pitched at newsrooms.

What a newsroom build costs and how long it takes

In our delivery experience the honest shape is this. A first release covering the rundown and story model, scripting with prompter output, MOS device control for graphics and video servers, and a supervised digital publishing path runs $90,000 to $180,000 and ships in 14 to 20 weeks. That is a system a producer can run a show on, deployed alongside the incumbent rather than instead of it. A full newsroom computer system covering multi market story sharing, assignment desk and planning, archive search, as-run reconciliation, mobile field capture and reporting runs $250,000 to $600,000 phased over 9 to 18 months.

What drives the price up in broadcast specifically: the number of distinct graphics and automation systems in the group, since each is its own integration and each version behaves differently. Legacy MOS plugin dependencies during transition. Multi market deployment, because branding, ticker rules and legal review differ per market. Redundancy expectations, because a newsroom system that goes down at 5:55 is a career event. And live migration, the underestimated one: you cannot take a newsroom dark for a weekend, so you run parallel across several show cycles.

Build versus buy for a newsroom computer system

Buy if you are a single station or a small group running conventional shows with a stable graphics and prompter chain, and your digital operation is a separate team you are content to keep separate. Avid iNEWS is proven, Octopus Newsroom is capable and considerably lighter to run, Dalet gives you a strong media spine if you are already in their ecosystem, and Ross Inception fits well when the rest of the control room is Ross. Any of them beats a bespoke build when your requirements are close to the shape they assume.

Build when two or more of these are true. You operate multiple markets and want a real shared story pool rather than an email chain. Broadcast and web must be one editorial object, not two. Your graphics, archive or publishing stack sits far enough outside the vendor's assumptions that you pay for integration work every year anyway. You have a complaints process requiring you to reconstruct what the rundown said at a given second. Or you face a seven figure licence renewal for a system your producers work around daily, in which case the build case is arithmetic rather than ideology.

How to choose a developer for newsroom and broadcast software

Ask them to describe the difference between a story and a rundown row, and what happens to both when a story is killed after air time. A developer who has done broadcast will talk about instances, placements and event ordering. A developer who has not will describe a table with a status column, and you will discover the difference at 5:58 on a Tuesday.

Ask specifically what they have integrated over the Media Object Server protocol and with which devices. Graphics ordering, prompter output and video server control are three different problems, and each vendor implementation has its own quirks. Ask for the device, the version, and what broke.

Ask how they will run the migration without taking a show off air. The right answer involves running parallel through real show cycles with producers comparing both systems, not a cutover weekend. Anyone who proposes a big bang has not worked in a live environment.

Ask who owns the code, the repositories and the cloud accounts, and get it written before kickoff. At Digital Heroes the client owns everything from the first commit, and we would tell you to walk from any developer who wants to hold the keys to the system that runs your six o'clock.