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 the Product Success (PS) team 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 home view is a route table, one row per route key, auto-populated by sampling the proxy. Each row shows the call rate, a 7-day velocity trend, and any deployed spec name and event type. ID-heavy paths compress into wildcards; irrelevant routes are filtered out before they reach the table.

Clicking any route opens a detail view: velocity history, spec name and event type, a breakdown of the route key (URI, query parameters, headers, body), and a real sample request and response from the customer's environment. It answers the question PS used to chase manually: what data is available on this route?

Site Sentry isn't read-only, it's a working surface. PS can full-text search every route for specific cookies, headers, or form keys. Routes split by match criteria or merge via wildcards when ID segments clutter the table. When one's ready to become a spec, its match criteria export as JSON straight into the spec catalog, no transcription, no translation.

The sampled call rate doubles as an insertion-rate estimate: roughly how many events a new spec will generate before PS commits to it. Teams can now size new coverage before deployment instead of discovering the scale after the fact.

The lists manager lives in a Model Settings tab, opening to all 20 allow and block lists at once, with a filter panel to search by list name or by values inside them, so finding an entry takes seconds. How the lists were grouped came from close work with the PS team, who field these requests daily.

Adding entries supports both the single-value case (one email to block now) and the batch case (200 suspicious IPs). Users type a value or paste a comma-separated list into the same field and press Enter, no separate import modal or upload flow.

Validation catches duplicates across lists and format errors where the element type has a consistent format to check. But it's honest about its limits: some types, like zip codes, vary too much by country to validate reliably, so the product doesn't try.

The Change Log sub-tab gives clients a full history of every change. Each line is a save event, so updating three lists and saving once groups those changes together, reflecting how it actually happened, especially valuable when 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 thought I needed 15 colors. After testing in Viz Palette and working through Paul Tol's color-theory research, I landed on 12, with Spec's brand blue as the anchor. This wasn't territory I knew deeply, so I built the foundation first. Accessibility drove it: Viz Palette simulates how a set reads across types of color blindness (deuteranopia, protanopia, tritanopia) and flags pairs that become indistinguishable. Several candidates that looked strong in isolation failed outright, issues no swatch review would have surfaced.

The next layer was semantic: colors that communicate risk and status consistently. Five states — red (malicious), yellow (suspicious), green (good), grey (neutral), blue (informational). Yellow was the hardest. It had to read as "suspicious" without veering into orange or washing out too bright to be taken seriously, and landing on one that was unambiguously moderate risk was one of the most important decisions in the system.

The palettes that came close kept hitting the same wall: too similar to a competitor, or 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 is the last thing a data product wants. But if a palette is accessible, legible, and already understood, is replicating it actually wrong? That was the quandary, and there's no clean answer, which made it one of the hardest parts of the project.

Where we landed: anchor to meaning. The 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 for the sake of differentiation would only make the product harder to trust. The distinctiveness came from how the system was built around those anchors, not the anchors themselves.

Midway through, a surprise: Spec rebranded with a new brand blue and purple, and the palette went back to the drawing board. The goal expanded from updating chart colors to building a full system: 8 color families (red, orange, yellow, green, blue, purple, pink, grey), each with stops up and down to support a future dark mode. Brand blue and purple subbed in directly; grey was edged toward Spec's blue tones to keep blacks off true black; red and green carried over from Phase 2. The one exception: the risk yellow stayed protected. It had taken too long to find and was too precisely calibrated to touch. Four accent colors for chips, icons, and categories were defined here too.

With the expanded palette defined, the Phase 1 validation ran again: every color through Viz Palette for distinguishability and accessibility. The rebrand introduced values never tested in data-viz contexts, so this wasn't a formality — new blue, new purple, and adjusted neutrals all had to hold up at small sizes, in overlapping series, and across the impairments the tool flags. Some needed nudging, some passed clean. The color report became the record of what was intentional and what was a known tradeoff.

A color system without usage guidance is just a swatch set. This layer defined how each category applied across UI contexts — backgrounds, borders, icons, text — with clear rules for where each role belonged. It also set up a future dark mode: the stop structure across each family was designed so that wouldn't start from scratch.