SignalOS
SignalOS is a measurement tool that refuses to guess. It exists because most AI visibility numbers can't survive a client asking how you know. It asks each question five times on every engine, shows the sample behind each figure, marks estimates as modelled, and shows nothing at all when there isn't enough data. Everything else in the product is built on that.
Why does SignalOS exist?
Buyers now ask an AI assistant for options in a category and get back a short list of names. Those brands are on the shortlist before anyone reaches a search results page. The people responsible for those brands can't see the conversations, so a category of tools has grown up to measure them for them.
Most of those tools ask an AI a question once and report the answer as a fact. Ask the same assistant the same question again and the list of brands often changes. One answer is a single roll of the dice. A dashboard built from single rolls moves for reasons that have nothing to do with anything the brand did, and nobody looking at it can tell which movements are real.
That matters most to the people who have to explain the number to someone else. An agency that reports a visibility score to a client will eventually be asked how it knows. If the honest answer is that it asked once, the report can't be defended. We built SignalOS so that the measurement is defensible first, and everything built on top of it — the diagnosis, the worklist, the impact reading — inherits that. What this means for someone running it across several clients is on the agencies page.
What rules does the product hold itself to?
Four rules that decide what SignalOS is allowed to show you. Each is enforced in code rather than left to good intentions, and the methodology sets out the detail behind every one of them.
Real data, or an honest “not enough data”
Below the sample threshold a figure is replaced by Not enough data and the sample it would have needed. Nothing in the interface can force a percentage to render for a reading that thin, and a blank or a bare 0% never stands in for it.
Every number traces to an answer
Open the evidence behind a figure and you read the raw AI answer, the model version and the time it ran. When a provider changes the model behind an engine, we record the change against the run that first revealed it, so a moving score can be checked against a moving model.
Estimates are labelled as estimates
Some figures are modelled rather than measured, such as a recommendation's quality score. The interface has a distinct Modelled marker for them, and the API returns nature: "modelled" alongside them, so an estimate never borrows the authority of a measurement.
Rules draw the conclusions, not a model
Reading an answer — was the brand named, in what tone, cited from where — is done by written rules. In the one place a model helps classify, the reason it gives must appear word for word in the answer before we store it. If it doesn't, the rule-based result stands.
How do we decide what ships?
We ship what we can verify. A capability that isn't built doesn't appear on this site as if it were: Google AI Overviews, answers in languages other than English and revenue attribution are all listed as things we don't do. When two capabilities were found listed on a plan without ever having been built, they were taken off the plan rather than left in the sales copy.
We say what we can't. Answers that aren't in English are detected and excluded rather than scored, because our classifiers read English, and a confident-looking verdict on text they can't read would be an error nobody could see. Five samples per question is the default. If a budget limit means fewer are affordable, we never go below three — and when even three isn't affordable, that engine is left out of the run and you're told which one and why.
When we find something wrong, we write it down rather than quietly fix it. Each stage of the build keeps a decision log, and a defect we discover goes into it: what was wrong, what it affected, and what is still unproven. When the rules behind a number change, the change is recorded with the date it took effect, so a trend that spans it is read against the right rules. Those logs are internal working records, not a public page. What reaches you is the result — a methodology that states its own limits, and a product that says when it doesn't know.
Why aren't there customer logos on this page?
You won't find customer logos, testimonials, ratings or a headline figure about how many people use SignalOS. A reader can't check any of those, and a product that sells defensible numbers shouldn't introduce itself with numbers it can't defend.
What you can check is the work. The methodology sets out how we sample, when we refuse to show a figure and what we can't measure, in enough detail to test us against. Ask a question five times yourself and compare. If something doesn't add up, or you want to see it run on a brand you know, get in touch.
Who builds SignalOS?
SignalOS is built by XONIK. It's the same name you'll see on a card statement: payments for SignalOS are set to appear there as SIGNALOS.XONIK, so a charge is recognisable as ours.
Check our numbers against a brand you know.
A walkthrough runs on a brand you actually care about, so you can compare what we measure with what you see yourself. Or read the methodology first and bring your questions.