---
name: seasonality-adjustment
description: "Use when someone compares two time periods and wants to know if a metric is trending — a month-over-month, week-over-week, or quarter-over-quarter move they are about to call growth or decline. Neutralizes calendar effects (unequal day counts, working vs holiday days, weekday mix, and seasonal cycles) before concluding a trend, so a mechanical artifact is not reported as a real change. Do NOT use for forecasting a future value, for building the metric's query, or for decomposing a move into mix vs rate (that is metric-change-decomposition)."
metadata:
  decimalai-skill-id: "1d90004a-5a11-4b89-9e5b-70612a7f9a2f"
  decimalai-version-id: "239f4915-7b48-4eb9-b686-046389fc5b56"
  decimalai-version: "1"
  decimalai-body-sha256: "62c9a6fcfe8667d811d62fa967d568eccc206f4bd150c8cb7c014af59fb9159c"
  decimalai-name: "seasonality-adjustment"
  decimalai-format: "1"
  decimalai-invocation: "model"
  decimalai-category: "data"
  decimalai-source: "https://app.decimal.ai/s/seasonality-adjustment@1/SKILL.md"
---
# Neutralize the calendar before you call it a trend

Shown "revenue was $1.0M in February and $1.1M in March — we're growing 10%", the base model tends
to affirm the trend and reach for a cause. But March has 31 days and February has 28; that is ~11%
more selling days before a single thing about the business changed. The entire "growth" can be a
calendar artifact. The raw period-over-period delta is a mix of a real signal and a set of calendar
effects, and until you subtract the calendar effects you do not know which way — or whether — the
metric actually moved.

This skill supplies that discipline: **adjust for the calendar first, then read the residual as the
trend.** A number that changed exactly as much as the calendar predicts is not a trend; it is the
calendar.

## When to activate

- Any "is [metric] up/down / are we growing/shrinking" from comparing two dated periods.
- Month-over-month, week-over-week, or quarter-over-quarter deltas about to be called a trend.
- A daily or weekly series that jumps around and someone is comparing two individual points.
- A "why is this month lower" where the two months differ in length, holidays, or weekend count.

Not this skill: forecasting the next period, writing the SQL that computes the metric, or splitting
a move into composition-vs-rate once the calendar is already controlled (use metric-change-decomposition).

## The one rule

Before naming a trend, ask **"how much of this delta does the calendar alone predict?"** and remove
it. The four calendar effects below, checked in order, cover almost every false trend.

## 1. Unequal length — normalize to a per-day (or per-period-unit) rate

Two periods rarely contain the same number of days. Convert each total to a per-day figure before
comparing, or the longer period wins mechanically.

- February vs March: 28 (or 29) vs 31 days — a 7–11% swing with zero underlying change.
- A 4-week reporting period vs a 5-week one — a 25% swing.
- Month-to-date (say 20 days elapsed) vs a full prior month — never compare a partial to a whole;
  compare same-days-elapsed or annualize both.

> $1.0M over 28 days is $35.7k/day; $1.1M over 31 days is $35.5k/day. Per day the business is flat —
> slightly *down*. The "10% growth" was entirely the three extra days.

## 2. Working vs non-working days — count business days, not calendar days

For anything driven by business activity (B2B orders, invoices processed, support tickets, payroll
runs), the number of **working days** is what moves the total — and it varies with weekends and
public holidays.

- A month with a long holiday can have 20 working days where a neighbor has 23 — a ~15% difference
  that has nothing to do with demand.
- A "December slump" or a "quiet week" is usually a working-day count, not a business decline.

Divide by working days, not calendar days, for these series. State the working-day count for each
period so the reader can see the adjustment.

## 3. Weekday mix — compare like days, not raw months

Many series have a strong day-of-week shape (retail peaks on weekends; B2B peaks midweek). Two
periods can hold a different number of each weekday.

- One month has five Saturdays, the next has four — for a weekend-heavy business that is one whole
  extra peak day.
- Comparing a single Tuesday to a single Saturday, or a holiday Monday to a normal one, compares the
  day-of-week shape, not the trend.

Compare same-day-of-week to same-day-of-week (this Tuesday vs last Tuesday), or count the weekday
composition of each period and adjust. Never conclude from two individual days of a weekday-shaped
series.

## 4. Seasonal cycle — prefer year-over-year for anything with a season

If the metric has an annual rhythm (heating, ice cream, tax software, retail Q4, travel), a
month-over-month move is dominated by the season, not by growth. Ice cream sales rising from March
to June is the calendar, not a win.

- For seasonal series, compare **year-over-year** (this June vs last June): the season is held fixed,
  so the residual is real growth.
- Watch **moving holidays** (Easter, Lunar New Year, Ramadan) that land in different months across
  years — they distort a single-month YoY. Compare the combined window (e.g. March+April together)
  when a holiday drifts across the boundary.

## Volatile series — smooth before you read a point

For a noisy daily or weekly metric, two individual points carry day-of-week and random noise. Read a
**trailing average** (7-day to absorb the weekly cycle, or 28-day for month-scale) and compare the
smoothed levels, not two raw readings. A single-day spike or dip is rarely a trend.

## Output shape

```
Raw: [metric] [P1 → P2], a [raw Δ].
Calendar check:
  - [effect that applies]: [P1 had X, P2 had Y] → predicts [~Δ from calendar alone]
Adjusted: on a comparable basis (per-working-day / same-weekday / YoY), [metric] moved [adjusted Δ].
Read: [real trend, or "flat — the raw move is a calendar artifact"].
```

## Edge cases

- **You lack the day/holiday counts.** Don't declare the trend anyway. Name the exact calendar figure
  you need (working days per period, weekend count, or the prior-year value) and flag the raw delta as
  unadjusted until you have it.
- **The adjustment barely moves it.** Then the trend is probably real — say so, now with the calendar
  ruled out rather than ignored. Ruling it out and finding nothing is a valid, stronger conclusion.
- **Both a length and a seasonal effect apply.** Handle the season first (go YoY), then normalize the
  two same-season periods for their day counts — a leap February, a shifted holiday.
- **Non-seasonal, equal-length periods** (two identical calendar weeks, both full, same weekday
  composition). No adjustment needed — say the calendar is already controlled and read the delta
  directly. Do not invent an adjustment that isn't there.
- **The calendar explains only part of it.** Subtract the calendar-predicted portion and report the
  residual as the trend, with its size — not "it's just the calendar" when a real move remains.

## Evaluation criteria
A good execution of this skill should:
- [ ] Check the day/period-length difference before accepting a period-over-period delta as a trend
- [ ] Use working days rather than calendar days for business-activity metrics
- [ ] Account for weekday mix (or compare same day-of-week) on day-of-week-shaped series
- [ ] Prefer year-over-year over month-over-month for seasonal metrics
- [ ] Report a delta fully explained by the calendar as an artifact, not a real trend