Signal Index

Every studio ends up with the same problem it solves for clients. Content lives in a repository, releases live in a pipeline, performance lives in a vendor dashboard, and nobody can answer a simple question — what changed, when, and did it make anything worse — without three tabs and a guess.

We wanted one internal surface that reads the same sources our client work is instrumented with, so the tooling we recommend is tooling we run ourselves. The constraint was that it had to cost almost nothing to operate: no separate database to keep alive, no dashboard subscription, no scheduled job that quietly dies.

We treated it as a content problem rather than a data problem. Every entity the studio cares about — a page, a project, an article, a release — is already declared in a typed model. If those models are the source, an index over them is a rendering exercise, not an integration project.

Field performance and availability are read from the measurement layer on a schedule and written back as static records. Nothing queries a vendor API at request time, so a slow third party can never slow down the page that reports on speed.

The index reads field performance at the 75th percentile, release history and content state. It reads nothing about an individual visitor: there is no user table, no session replay and no identifier that survives a visit.

What it cannot tell us is whether a change was good for the business. It reports that a release moved a number; a person still has to decide whether that number mattered.

The index is in daily use inside the studio and is the reference implementation for the measurement layer we build for clients. It is deliberately unglamorous: it exists to make the invisible half of a system legible to the people responsible for it.

Internal tool. No client data passes through it and no performance figures are published from it on this site.