Why we won't let an AI fire your hazer
The HitLight team · · 8 min read
In June 2026 the moderators of the largest lighting subreddit banned self-promotion outright. The reason they gave was a massive influx of vibe coded apps, and the honest admission that they could not vet the code or the intentions behind it for 61,000 members. We are an AI lighting app asking those same people to plug our software into equipment that heats, moves and ignites things. It would be strange of us to be offended.
a massive influx of vibe coded apps
So this is not a reassurance piece. Reassurance is exactly what a moderator cannot verify. Below are four specific things HitLight does, each of which is either observable on your own rig or readable in a public repository. Check the ones you care about and discard the rest.
The four guarantees
- A watchdog outside the interface
- A native watchdog running outside the interface latches DMX output to an all-zero frame within two seconds if the app stops responding. Output stays down until an operator explicitly restores it.
- Hazardous channels stripped in code
- Smoke, haze, fan and flame-ignition channels are removed from every automatic path in code, not by convention. The assistant cannot arm them either.
- Signed, notarised, pinned key
- HitLight builds are Apple Developer ID signed and notarised. Updates are verified against a public key committed in the repository, so a rotated key cannot silently push you a build.
- The assistant reads the real frame
- The assistant never invents your fixture's channels. It works from the profile you patched and the values actually on the wire, and generated fixture profiles stay a draft until you test them.
Why did a lighting community ban AI app promotion?
Because the failure mode is physical. A badly built productivity app wastes an afternoon; a badly built lighting app drives a hazer into a smoke detector, holds a strobe on someone with photosensitive epilepsy, or freezes with a flame channel armed. Moderators of a 61,000-member community have no way to audit a stream of new tools, and the cheapest safe policy is to stop the stream. That is a defensible call, not an unfair one.
It also puts a real cost on us. If nobody will vouch for a category, the only currency left is specifics — claims narrow enough that someone can check them and catch us out if they are wrong. So here are ours.
What happens if the software hangs mid-show?
A native watchdog running outside the interface latches DMX output to an all-zero frame within two seconds if the app stops responding. Output stays down until an operator explicitly restores it. It does not try to recover the show for you, and it does not resume on its own when the app wakes up.
The design decision worth explaining is why zero is the chosen failure state. Lighting software that hangs usually keeps sending its last frame, because the last frame is sitting in a buffer and nothing is left running to change it. That frame is whatever happened to be on the wire at the moment things stopped — which can be a strobe mid-burst, a blinder at full, or a moving head halfway through a sweep. A frozen look is the most dangerous thing a lighting rig can do, because it is indistinguishable from an intentional one until someone works out that nothing is responding.
Going dark is disruptive and obvious. That is the point: it fails in the direction where a human immediately knows something is wrong and reaches for the house lights. And because the watchdog runs outside the interface, it does not depend on the part of the system that just stopped responding to notice that it stopped responding.
Can automatic control fire a hazer, a laser or a flame projector?
No. Smoke, haze, fan and flame-ignition channels are stripped from every automatic path in code, not by convention. Auto Show cannot reach them, and neither can the assistant. This is not a setting that ships switched off, and it is not a prompt instruction telling a model to behave itself. The channel types are removed before anything automatic gets a chance to address them.
The distinction matters more than it sounds. A rule expressed in a prompt is a request; a channel class that never enters the data structure is not reachable by anything downstream, including a model that has been talked into ignoring its instructions. We chose the second because the first is only as strong as the worst input anyone ever sends.
| Channel type | Automatic control | Manual control |
|---|---|---|
| Smoke, haze and fans | Never driven. Removed from every automatic path in code. | Available to you in the inspector and in scenes you build yourself. |
| Flame, ignition and pyro | Never driven, and never armed by the assistant. | Available manually, subject to the arming behaviour the fixture itself enforces. |
| Lasers | Never driven automatically. | Available manually, with the fixture's own safety interlocks unchanged. |
| Flashing strobes and blinders | Not driven. Auto Show holds a steady open shutter instead. | Available manually, where the operator is making the photosensitivity decision. |
| UV | Not driven automatically. | Available manually. |
| Macros and unverified effect channels | Not driven. A macro can mean anything on any fixture, which makes it unsafe to guess at. | Available manually once you know what the values do on your unit. |
What Auto Show does drive is colour, intensity, a steady open shutter and eligible movement. That is a smaller feature than the one we could have shipped, and it is smaller on purpose. The full list lives on the lighting safety page.
How do you know the build on your Mac is the build we shipped?
HitLight builds are Apple Developer ID signed and notarised, and updates are verified against a public key committed in the repository. Because the key is in the repo rather than only on our build machine, a rotated key cannot silently push you a build — a change to it is a visible commit rather than an invisible server-side switch.
Signing tells you the build came from us. Notarisation tells you Apple scanned it. Neither tells you the software is good, and we would rather not pretend otherwise. What they do rule out is the specific scenario people are right to worry about with small tools: a compromised or replaced update channel quietly delivering something else to a machine that is plugged into a rig.
The tradeoff is real and worth stating. Pinning a key means rotating it is a deliberate, visible, slightly painful event rather than a routine one. We think that is the correct place to put the friction.
Does the assistant know what your fixtures actually do?
The assistant works from the fixture profile you patched and the values actually on the wire. It never invents your fixture's channels. When you ask for a warm wash it resolves that against the real channel layout of the real fixtures in your rig, and when it reports what the rig is doing it is reading the current DMX frame rather than describing what it intended.
This is the guarantee that quietly does the most work, because the classic failure of a language model near hardware is confident invention: a plausible channel number, a plausible macro value, a plausible confirmation that something worked. Reading the frame is what turns "I set the moving heads to blue" from a claim into an observation.
It also sets the limit of the guarantee, which we would rather state than have you discover. If the profile is wrong, the assistant will be wrong with complete confidence — it is faithful to the profile, not to physics. That is why generated fixture profiles stay marked as drafts until you have tested the channels on the real fixture, and why verifying a drafted profile is a step we ask you to do rather than a step we skip.
What can you do while it is running?
Three controls, always available, all immediate in the sense that matters: none of them wait for the current scene, cue or automatic sequence to finish. Blackout in particular sits next to the Auto toggle rather than in a menu, because the one thing you should never have to search for is the off switch.
| Control | What it does |
|---|---|
| Stop | Holds the last safe look on the rig. Nothing changes until you act again. |
| Fade Out | Takes the rig down over one second. |
| Blackout | Immediate. Sits next to the Auto toggle and takes effect at once. |
A browser or iOS remote can issue Stop or Blackout too, which means the person holding the phone at the back of the room does not have to reach the laptop to stop the show.
Is a list of guarantees the same as trust?
No, and we are not going to argue that it is. Anyone can write four confident paragraphs. The only thing that separates this page from a page we made up is that each of these four claims is checkable, and three of them are checkable by you without taking our word for anything.
- The watchdog: run a show, force-quit the app, and watch the rig go to zero within two seconds and stay there.
- The exclusions: patch a hazer and a flame projector, turn on Auto Show, play something loud, and watch those channels sit at zero for as long as you care to leave it.
- The signing: inspect the signature and notarisation of the downloaded build with the tools already on your Mac.
- The real frame: change a value by hand in the inspector, then ask the assistant what the rig is doing.
If any of those does not behave as described, that is a bug and we want to hear about it. The alternative — asking a community that has been burned to extend credit on the basis of tone — is not a request we are entitled to make.
If you want the shorter version of all of this, the lighting safety page keeps the current channel exclusions and operator controls in one place, and AI and your data covers what is sent to a model and what never is.
Try it on your own rig
Patch your fixtures, describe the look you want, and watch it on the 3D stage before you connect anything.
Free during the public beta, with no credit card. Launch pricing has not been announced. Requires macOS 14 or later for hardware output.