The 90-day activity cap wasn't arbitrary: it kept ClickHouse query costs down given Spec's event volume. But 90 days often wasn't long enough to establish behavioral patterns.

Rather than lift the cap, I kept the cost-conscious default and gave users an optional window up to 365 days. Most analysts rarely needed past two or three quarters, so 365 was a deliberate test boundary: enough to validate real demand before expanding further.

Every entity shows a status chip (Allowlist, Blocklist, or No List), editable in place and synced both ways with Lists. The same treatment carries through every table, search result, and flyout in the product.

A search bar in the side nav lets analysts look up any identifier without leaving context. Live suggestions surface as they type; one click lands in the right profile.

It's arguably the highest-leverage unlock, so why M3 and not M1? Dependencies. A true global search would have been prohibitively expensive at Spec's data volume, so I scoped it with PS to a semi-global lookup on key entities. That still needed a new search table from the platform team first, so I sequenced lighter milestones ahead of it and landed it as early as the release chain allowed.

Events split into four tables (Payments, Refunds, Logins, Signups), each with tailored columns and breakdowns. A new event_context field lets PS add plain-language explanations to failed events.

A node graph surfaces first-degree connections grouped by identifier type, node size scaled to volume. Selecting a node filters the linked entities table and updates the event volume chart live.

This wasn't the first attempt. An earlier graph had been scrapped for good reason: nodes drifted when selected, and color noise buried any pattern. The rebuild was a series of corrections: scope links to first degree, strip the palette, lock the nodes static, and scale each by its event count so volume reads at a glance. From there it hands off to the real analytical work: aggregates, timelines, and click-throughs into event search.

The Site Sentry home view is a route table: one row per route key, automatically populated by sampling the proxy. Each row surfaces the route key, sampled call rate, a 7-day velocity visualization, and the associated spec name and event type if one has been deployed. ID-heavy paths are algorithmically compressed into wildcard routes, and irrelevant routes are filtered by MIME type and HTTP verb before they ever reach the table.

Clicking into any route opens a detail view with the full picture: velocity history, spec name and event type, a breakdown of the route key (URI, query parameters, headers, body), and a sample request and response from the actual customer environment. This was the answer to the question PS had been asking manually for every deployment: what data is available on this route?

Site Sentry isn't a read-only view. It's a working surface. PS can full-text search across all routes to check for specific cookies, headers, or form data keys. Routes can be split by adding match criteria that distinguish one variant from another, or merged via wildcards when ID segments clutter the table. When a route is ready to become a spec, match criteria can be exported as JSON and fed directly into the spec catalog. No transcription, no translation.

The sampled call rate for any route doubles as an insertion rate estimate: telling PS teams roughly how many events a new spec will generate before they commit to it. This closed a key gap in the configuration workflow: teams could now validate the scale of new coverage before deployment, rather than discovering it after the fact.

The lists manager now lives in a Model Settings tab (the start to a self-service UX which will eventually hold other self-service actions) and opens to all 20 allow and block lists displayed simultaneously. A filter panel on the left lets users search by list name or by values within lists, so finding a specific entry across all lists takes seconds. No toggling between tabs. No hunting through menus.

Adding entries was designed to support both the single-value case (one email to block right now) and the batch case (a report of 200 suspicious IPs). Users type a single value or paste a comma-separated list directly into the input field and press Enter. Both paths feel the same: no separate import modal, no file upload flow required.

Validation catches duplicates across lists and format errors where the element type has a consistent format to check against. Entries are not case-sensitive. But the system is transparent about its limits: some element types, like zip codes, vary enough by country that format validation would produce false negatives. For those, the product doesn't attempt validation it can't do reliably.

The Change Log sub-tab gives clients a full history of every modification. Each line item represents a save event, so if a user updated three lists in one session and hit save once, those changes appear grouped together, reflecting how the action actually happened. Especially valuable in multi-user environments where multiple team members have access.

Color was one piece of a broader product audit covering IA, interaction design, styling, and typography. On the color side: every value in the product was catalogued, the inconsistency documented, and then a real research phase began.

I initially thought I needed 15 colors. After testing with Viz Palette and working through Paul Tol's color theory research, I landed on 12, including Spec's brand blue as the anchor. The research phase was extensive and essential. This wasn't territory I had deep color theory experience in, so I built the foundation before making decisions. Accessibility was a core part of that exploration: Viz Palette simulates how color sets read across different types of color blindness (deuteranopia, protanopia, tritanopia) and flags pairs that become indistinguishable. Several early candidates that looked strong in isolation failed those checks entirely. That feedback loop was what made the tool so valuable; it caught issues no swatch review would surface.

With the chart palette established, the next layer was semantic: a set of colors that would communicate risk and informational states consistently across the product. Five states: red (malicious), yellow (suspicious), green (good), grey (neutral), blue (secondary informational). Yellow was the hardest. It had to read clearly as "suspicious" without veering into orange or washing out into something too bright to be taken seriously. Getting it right took significant iteration, but landing on a yellow that was unambiguously moderate risk, not too orange, not too light, was one of the most important decisions in the whole system.

I tried and tried and tried again. The palettes that came close to being greenlit kept running into the same wall: too similar to a competitor, or too close to another well-known product. Which raised a harder question: how do you differentiate without diverging for its own sake? Being different just to be different isn't design. It's noise. And noise, in a data product, is the last thing you want. At the same time, if a palette works, if it's accessible and legible and users already understand its language, is replicating it actually wrong? That was the quandary. There's no clean answer to it, which made it one of the most genuinely difficult parts of this project.

Where we landed: anchor to meaning. The risk and status colors didn't need to be original. They needed to be correct. Green means good. Red means bad. Yellow means watch out. Those associations are too deep to fight, and fighting them in the name of differentiation would have made the product harder to trust. The distinctiveness came from how the system was built around those anchors, not from the anchors themselves.

Midway through the project, a surprise: Spec rebranded with a new brand blue and purple. The palette had to go back to the drawing board. The goal expanded: not just update the chart colors, but build a full color system: 8 main color families (red, orange, yellow, green, blue, purple, pink, grey) with stops up and down from each main to support future dark mode. Brand blue and purple were subbed in directly. Grey was edged toward Spec's blue tones to keep blacks away from true black. Red and green carried over from the risk color work in Phase 2. The one exception: the risk yellow stayed protected. It had taken too long to find and was too precisely calibrated to risk touching. A distinct orange and yellow were drilled into separately for the chart palette. Four accent colors (for chips, icons, categories, future product features) were also defined as part of this phase.

With the expanded palette defined, the same validation process from Phase 1 ran again: every color put through Viz Palette to check for distinguishability and accessibility issues. The rebrand had introduced new values that hadn't been tested in data visualization contexts before, so this wasn't a formality. New blue, new purple, adjusted neutrals, all of it needed to hold up at small sizes, in overlapping series, and across the range of visual impairments the tool flags. Some colors needed nudging. Some passed cleanly. The color report became the documentation of what was intentional and what was a known tradeoff, so future decisions could be made with context rather than from scratch.

A color system without usage guidance is just a swatch set. The output of Phase 3 included how each color category applied across UI contexts (backgrounds, borders, icons, text) with clear rules for where each role belonged. This layer also laid the groundwork for a future dark mode: the color stop structure across each family was designed with that in mind, so it wouldn't require starting from scratch when the time came.