Why we're building it this way

Picture a store manager on a Tuesday afternoon, pulling up the week's sales numbers and finding revenue down fifteen percent from the week before. There's no obvious reason. Nothing changed on the shelves, staffing looks normal, and the weather wasn't unusual.

The only way to actually find out what happened is to sit down and scrub through six hours of security footage from that day, hoping something jumps out. Nobody has six hours for that, so the number gets chalked up to a slow week, and the manager moves on without ever knowing if a register was understaffed, if something blocked an aisle, or if people just got tired of waiting in line and left.

The footage exists. It just never gets watched.

Here's the plain version. One part of Brelisk is always watching the video, quietly keeping track of where people are in the store and how long they've been standing in one spot. It doesn't try to explain anything. It just counts and measures, the whole time, for every camera.

Say a line starts forming at checkout. Six people are waiting instead of the usual two or three, and the last person in line has been standing there for almost ten minutes. That's the kind of moment the tracking part flags as worth a second look. A second part of the system, one that doesn't run constantly, gets pulled in at that point. It looks specifically at that stretch of footage and writes a plain sentence about what's probably going on: a line built up at checkout starting around 5:15, and people were waiting close to ten minutes at the peak.

You get that sentence instead of a graph or a wall of numbers, because a sentence is what you'd actually want to read if someone asked you what happened at the store at 5 o'clock today.

The reason it's split into two parts like this comes down to a simple fact: you can't rewind a live camera feed. If the tracking part misses a moment because it's busy thinking too hard about what something means, that moment is just gone. So that part has to be fast and cheap enough to run on every single frame, all day, without falling behind, and that means keeping it simple: track positions, measure time, flag zones. No deep interpretation happens there.

But here's the thing. Nobody is actually sitting in front of a screen watching this in real time, waiting for an answer the instant something happens. A store manager checking in on their store wants to know what happened an hour ago, or yesterday, or last Tuesday. Given that, there's no reason the part that actually explains things needs to be instant. It can take a few extra seconds, or even longer, and it only gets involved once the tracking part has already flagged something as worth explaining. That's a much smaller job than watching everything all the time, which is exactly why it can afford to think a little harder about each one.

It would be easy to list out every possible thing a store might want to know: how many people walked in, which displays got attention, how staffing levels affect sales, how conversion changes by time of day. All of that is genuinely useful, and eventually some of it will probably be part of what Brelisk does. But trying to build all of it at once, before proving the core idea actually works, would be a mistake. It's easy to end up with a system that sort of does twenty things instead of one thing that actually works well.

So the current focus is narrow on purpose. Right now, that means one well-defined situation: checkout queues, and how long people are waiting in them. That's specific enough to test properly and see whether the whole idea, tracking plus explaining, actually holds up in practice. Once that's solid, the same approach can expand to the rest.