## The Why Engineering leaders want to compare "this period vs. last period" — for example, activity over the last 30 days against the 30 days before that — in a single chart or view. Calendar-aligned `daily`/`weekly`/`monthly` buckets can't express a rolling "today minus N days" window, so these comparisons aren't possible in GLQL today. This is a key building block for the [DAP Impact Dashboard v1](https://gitlab.com/groups/gitlab-org/-/work_items/23225) epic, and depends on the backend aggregation engine adding origin-anchored dynamic day granularity support, tracked in [this work item](https://gitlab.com/gitlab-org/gitlab/-/work_items/609138). ## Proposal GLQL should accept dynamic day-based granularity values, such as `30d`, `65d` up to `399d`, anywhere a `granularity` parameter is accepted, alongside the existing `daily`/`weekly`/`monthly` values. This applies uniformly across all existing and future sources that expose a granularity parameter, not just a specific subset. For example, a query could use `timestamp(granularity: "30d")` to bucket results into fixed 30-day windows, enabling rolling period-over-period comparisons in a single view. GLQL should also accept the new optional `origin` parameter that anchors fixed-day buckets at a given timestamp (only valid with an `Xd` granularity). Anchoring is what makes the current-vs-previous comparison line up with the query's date range, for example: ```yaml mode: analytics query: group = "gitlab-org" and mergedAt > -60d dimensions: merged(granularity="30d", origin="2026-07-16T00:00:00Z") metrics: count ``` --- ## Technical Proposal The `granularity` parameter's accepted values expand from a fixed enum (`daily`, `weekly`, `monthly`) to also accept a dynamic `XXXd` pattern (any number of days), applied uniformly across all sources rather than implemented per-source. Date dimensions additionally accept an optional `origin` datetime parameter, passed through to the engine's `origin: Time` GraphQL argument. ## Implementation details 1. **`Xd` granularity**: extend `ParameterConstraint` (`src/types/field_parameter.rs`) with a variant that accepts the enum values plus a fixed-day pattern (`\d+d`, bounded 1–399); validate in `validate_param_values` (`src/analyzer/analytics.rs`), quote like enum values in `format_graphql_params` (`src/codegen/graphql.rs`), serialize the new constraint kind in the schema builder and regenerate `schema.json`. 2. **Unify granularity allowlists**: drop the per-source restrictions in `code_suggestions.rs` (monthly only) and `agent_platform_sessions.rs` (weekly/monthly); all analytics sources use the shared `daily`/`weekly`/`monthly` + `Xd` set. Widening is backwards compatible. 3. **`origin` parameter**: add a datetime parameter kind (`ParameterValue`/`ParameterConstraint`), close the multi-parameter default-backfill TODO in `resolve_named_args` (`src/analyzer/analytics.rs`), validate that `origin` is only combined with an `Xd` granularity, ensure alias slugs stay valid GraphQL for ISO timestamp values, and carry `origin` through sort parameter emission (`src/codegen/graphql/analytics.rs`). 4. **Labels**: parameterized field labels ("Merged: Weekly") need a sensible form for `Xd`, e.g. "Merged: 30d". 5. Verify with `DUMP_GRAPHQL=1 cargo test && npm run test:graphql` and an end-to-end run via the Ruby gem. ## Acceptance criteria - [ ] A GLQL query using a dynamic granularity (e.g. `granularity: "30d"`) returns results correctly bucketed into fixed N-day windows. - [ ] Dynamic day-based granularities work consistently across all sources that expose a `granularity` parameter, without per-source exceptions. - [ ] An optional `origin` parameter anchors `Xd` buckets at the given timestamp; combining `origin` with a calendar granularity produces a clear error. - [ ] Existing `daily`/`weekly`/`monthly` granularity values continue to work unchanged. - [ ] An invalid or malformed granularity value produces a clear, actionable error message. ## Out of scope The underlying aggregation engine and backend support for `Xd` day-based granularities is handled in the linked backend work item, not here.