How Tally Confirms a Cue Actually Aired

Sending a command and having it actually happen are two different things. Here’s how Tally tells the difference, and why it checks after instead of before.

Most show-control tools stop at “command sent.” Tally is the part of Showcaller — the AI co-pilot for live production — that doesn’t.

Here’s the distinction, and it matters more than it sounds like it should: sending a command and having that command actually happen are two different events. A network hiccup, a desk that’s mid-save, a device that’s slower than usual to respond — any of these can mean the instruction went out and the hardware just… didn’t do it. Most systems have no way to know the difference. They sent the command, so as far as they’re concerned, the job is done.

How Tally actually works

Tally checks. After a command goes out, it waits for the hardware to report its actual state, and only then confirms the cue took. Not before — Tally isn’t a pre-flight check that holds a command up to inspect it first. It’s a confirmation that runs right after, fast enough that it doesn’t slow anything down, but real enough that “confirmed” actually means something.

If a cue doesn’t take — the scene didn’t recall, the input didn’t switch, the mute didn’t latch — you hear about it immediately. Not when someone in the room notices something looks wrong. Not after the show. Immediately, while there’s still time to do something about it.

This is also where Air Check picks up the thread. Every one of these confirmations — pass or fail — gets written into the same permanent timeline as everything else that happens during a show, so the record isn’t just “what we told the system to do,” it’s “what actually happened.” If it didn’t happen in the rack, it didn’t happen in Showcaller.

It’s a small mechanical difference — verify after, not before — but it’s the difference between a tool you have to double-check and one you don’t.

Read about Air Check, the permanent record this feeds into →