Score the upgrade before you run it.
A firmware change is the most common way an AV-over-IP system goes down: a clock that will not re-lock, multicast that stops flowing, audio that loses its priority. CrossCheck checks your change against a model of your own gear and gives you a straight Go, Caution or No-Go, with the exact fix when it is risky.
Read-only and advise-only. CrossCheck reads your gear, models the change against it, and hands the change back to you to make. You can keep it away from the device and type the firmware version in by hand instead; it tells you the model is weaker for that and scores the verdict down to match.
The verdict. One number, one band, and the single thing holding it down.
The problem
The release notes were written for the device, not for your room.
The thing that takes the boardroom down on Monday is almost never the bug in the changelog. It is the clocking domain that quietly stopped agreeing with itself, or the multicast group that had nowhere to go because snooping was on and no querier existed. Often it is the switch you also had to bump to get there, whose new build resets a queue you were relying on.
The vendor has never seen your room, so the release notes stay silent on all of it. You find out at 7am, with the room booked at 9, and the rollback you assumed you had was never tested.
Nobody pays to avoid a truck roll. They pay to avoid the four hours the boardroom was dark.
What it checks
Model it once. Check every change against it after that.
The arithmetic you just watched runs against a model you build once. You describe the environment a single time: the devices, the firmware they are on, the change you want to make. Type it in, import it, or bind it to the live gear. Then you save it, and every future change window starts from that model, so you never rebuild it.
- The sixteen checks Version floors, clocking and PTP, multicast and IGMP, QoS and DSCP, link headroom, PoE budget, MTU, end-of-support dates, and the blast radius of the switch firmware you also have to move. Each one tells you what it found, how many points it cost, and the fix. Two more run when the room has a persona to check against, so a single window can run eighteen.
- 23 AV protocols, 7 room types Dante, AES67, Milan, ST 2110, NDI, SDVoE, Q-LAN, PTP and fifteen more, each modeled against six readiness dimensions. The room is checked as the thing it is: an all-hands, a divisible conference room, a lecture capture, a broadcast studio, a NOC video wall, a huddle room, signage. A boardroom and a signage screen do not fail the same way.
- Published bands, so the number means one thing Go at 75 and above. Caution from 50 to 74. No-Go below 50. The bands are fixed and published, so the number means the same thing every time, and a score you can compare across two change windows is worth more than a score that flatters one.
- Fidelity scored by provenance The score is multiplied by how well CrossCheck knows the gear. A live read from the device counts at 100%, a vendor export or design file at 80%, and a firmware version you typed from memory at 60%. A device you never modeled at all counts zero. The multiplier is published because you should be able to raise it.
- Twelve device connectors Nine of them read the live device: Q-SYS, Dante Domain Manager, Crestron XiO, NMOS, ONVIF, AVDECC, SVSI, switch SNMP and gNMI. Bind one and the model reaches 100% fidelity while you type nothing. A build test fails if this page names a protocol with a connector missing behind it.
- Formal equivalence proof Optional. Proves your switch configuration forwards the AV control, clock and discovery flows identically before and after, across every path and not a sample of them. It proves the network. It does not claim to prove the closed firmware running on it, and it says so.
- Digital-twin rehearsal Optional. Boots the real target network operating system in a twin and runs the change against it, so what you rehearse is the vendor's actual behavior. One switch OS pulls with no account. The rest need a vendor account or a license, which you supply.
- Firmware X-Ray Optional. Opens the vendor's firmware image before you flash it and shows what changed in the subsystems you depend on. Many images open. Some are encrypted. Those it reports as sealed, and asks you for the release notes.
When an optional capability cannot run, it says so on the screen and names what would let it run. It never reports a pass it did not earn. Missing data on a check you needed caps the verdict outright.
See it work
One switch, one version bump, one No-Go.
A real scenario: an AV switch with IGMP snooping turned on and no querier anywhere on the segment.
Start here. You will run one check and read the verdict it produces. It takes about a minute.
CrossCheck
preflight for AV upgrades
Sample
Start a check
Name one firmware change and get an honest go, caution or no-go before you apply it.
Everything else on this page is optional and already set to a sensible default, so you can ignore it.
The same change scored 36 when you guessed and 60 when you knew.
You get one change back as one honest number, with the fix to hand your vendor. It measures your evidence, so it climbs when you feed it and holds when you argue with it. About a minute per change window.
Sample data. This verdict was computed from built-in demo data, not from a reading of your environment.
The limits
Nothing in CrossCheck can flash your firmware.
CrossCheck only ever issues reads. The code to write a setting, push an image or open an SSH session was never written, so the worst it can do to a device in your rack is ask it a question. It answers that question once, in the window before you touch the gear, and then it is finished. It stands alone and works whether or not you own the other three.
The score is capped rather than rounded up. A check that applied but had no data to run on holds the verdict at 74, one point below the Go line, so a Go always means CrossCheck evaluated the thing it is clearing. An unearned green light would be worse than no tool at all.
Your first run
You cannot get a Go out of a firmware version you typed from memory.
You saw in the demo that a typed-in version scores lower than a read one. Here is the rule behind that. The demo scored 36, and twenty-four of those points went missing for a reason that has nothing to do with the switch: nobody had read it. The version came from a person, so CrossCheck trusted it like a person, and the arithmetic says so out loud.
There is a second brake, and it works the same way. Any check that applies to your change but had no data to run on caps the score at 74, one below the Go line of 75. So a single unanswered question about your own network puts a Go out of reach until you answer it.
How the demo above reached 36
Ceilings do not add up. They compete, and the lowest one wins, so the other two did nothing. Then the whole thing is multiplied by how much CrossCheck trusts the model you gave it. Read the switch instead of typing it and the same change scores 60.
The number goes up as you feed it, and it tells you what to feed it. Your first check reads like a to-do list; your tenth reads like a verdict you would stake the window on.
Before you ask
The eight questions we get on the first call.
What access do you need?
A read-only look at the gear you are about to change. Or nothing at all: you can keep CrossCheck away from the device entirely and type the firmware version in by hand. It tells you the model is weaker for that and scores the verdict down to match.
Will it change anything?
No. Read-only and advise-only. It models the change against your gear and hands the change back to you to make. It never touches the device.
How long until I have something useful?
One change, one rehearsal, before you touch anything. That is the whole loop, and it happens before the change window rather than during it.
Does this replace the tools I already run?
No. Nothing you own rehearses a firmware change against your actual gear and tells you what quietly takes AV down. Your monitoring finds out afterwards.
What happens when it is wrong?
It caps its own verdict rather than guessing. Without Docker the formal proof and the digital twin do not run, both say so on screen, and the verdict is capped to match what was actually checked. It does not return Go on a model it could not build.
Can I start with one change?
One upcoming change is the unit. Bring the next firmware upgrade somebody is nervous about.
What data leaves my environment?
Nothing. It binds to 127.0.0.1 and runs on the machine you launch it on.
Will it work in a restricted or air-gapped environment?
Yes. Docker is the only optional dependency, it is used for the formal proof and the twin, and when it is absent CrossCheck says which checks it lost instead of quietly skipping them.
What happens next
Four steps, and you can stop after any of them.
- Install it on your laptop. A double-click launcher. Nothing is installed on your gear.
- Tell it what you are about to change. The device and the firmware version you are moving to, read from the gear or typed by hand.
- It rehearses the change and returns a verdict. Go, Caution or No-Go, with what would break and the fix, and the verdict capped to whatever it was actually able to check.
- Make the change yourself, or do not. CrossCheck never makes it for you. That is the point of it.
The buying unit is one change. Not a subscription you have to justify before you have seen it work. One upgrade, rehearsed, and then you know whether the next one is worth rehearsing too.
Bring us the change in Saturday's window.
Send the model number and the version you are moving to. You get back the verdict, the findings and the fix.