Time-Series Plotting

When to use

• Authoring a workflow output that includes a trend over time, such as monthly product detection from company_install_time_series.
• Reviewing a generated chart that's the wrong shape for its audience.

Which data is a series

Only company_install_time_series returns a series: one point per month per product, where data_points[].intensity is the number of days the product was detected that month (1 to 31). Intent (company_intent), headcount and spend are snapshots. Never draw them as a line over time, and never fill in past values. If the user asks for intent over time, show the current snapshot with its trend value and last_seen_at, and say no history is available.

Prepare the series before plotting

1. Drop the current month. The last point is a null tail because the month is incomplete.
2. Drop partial months. The last complete month is often only partly loaded: detection stops at product_last_verified_date. Drop the month containing that date (unless it is at month end) and any later month. Plotted as-is, it looks like a collapse.
3. Mid-series null = no detection that month. Plot it as 0 and say so; don't interpolate.
4. Never mix scales. current_intensity is an all-time aggregate, not on the 1 to 31 scale. Keep it off the chart.
5. One country scope per chart. With granularity:"country" the same product repeats per country_code; plot one country per line or use the global rows.

Shape decision rule

Data Shape	Best Representation
3 to 12 points, single series, trend matters	Sparkline (▁▂▃▅▇)
3 to 12 points, single series, exact values matter	Compact table (month / value)
12+ points, single series	Line chart (image or rendered)
Multiple series	Multi-line chart (rendered)
Comparing 2 or 3 specific months	Inline prose ("detection fell from 29 to 8 days a month between May and Aug")

Sparkline conventions

When the shape of the trend matters more than the exact values:

Product X detection days, Mar to Aug 2026: █▇▇▅▃▂

Use the Unicode block characters ▁▂▃▄▅▆▇█, scaled to 0 to 31 days so sparklines for different products are comparable. Always prefix with the metric name and the time window. Don't use sparklines without labels.

Table conventions

When the exact values matter (an audit or a follow-up question):

Month	Detection Days
Mar 2026	30
Apr 2026	28
May 2026	29
Jun 2026	21
Jul 2026	12
Aug 2026	8

• Prefer "Jan 2026" month format; avoid "1/26", which is ambiguous between day and month.
• Title Case for table headers.
• Add intensity_momentum beside the table or in its caption: it is the direction signal (-20 or below = declining, +20 or above = growing).

Axis labeling for non-technical readers

A non-technical reader includes most CROs and AEs.

• Time axis: months or quarters, never timestamps.
• Value axis: include units: "Days detected per month (0 to 31)". Core products saturate at 28 to 31, so a flat line at the top means steady use, not a lack of growth.
• Annotations: when a sourced event explains a change (an acquisition, a migration announcement), annotate inline and cite it: "Jun 2026: migration announced [web_search]". Don't annotate with guesses.

Common pitfalls

1. Plotting the null current month or a partly loaded month as 0. It creates a fake collapse.
2. Charting intent or headcount over time. No tool returns those as a series.
3. Rendering a 30-row table when a sparkline would do. The table buries the trend.
4. Rendering a sparkline when the reader needs a specific value. "Did detection drop below 10 days?" can't be answered from ▁▂▄▅▇█.
5. Unitless axes. "Went from 30 to 8": thirty what?

Reference

• V2 tool docs: https://phoenix.hginsights.com/docs/mcp-tools/v2/company-install-time-series
• Full docs for LLMs: https://phoenix.hginsights.com/docs/llms-full.txt
• Related skills: tabular-summary-discipline, executive-prose-conventions, hg-momentum-signals