## Why The DAP Impact v1 Spend tab panel "Credits over time excluding Chat" wants every flow type except `chat` and `agentic_chat/v1` (https://gitlab.com/groups/gitlab-org/-/work_items/23470#note_3836601176). Aggregation-engine filters only include today, so the panel ships with an explicit include list (gitlab!255865), which breaks whenever a new flow type appears. The engine is adding exclusion: - https://gitlab.com/gitlab-org/gitlab/-/work_items/629295 - framework `exact_not_match` filter (`NOT IN`), 19.5 - https://gitlab.com/gitlab-org/gitlab/-/work_items/629296 - rollout via an `exact_match_pair` helper to all 27 include filters across the 8 engines, so every list filter gets a twin exposed in GraphQL as `<name>Not: [String!]` (for Spend: `workflowDefinitionNot` on `duoWorkflows`) GLQL cannot express this yet. Analytics list filters are declared with `scalar_or_list_field_type`, i.e. `=` and `in` only, so `flowType != "chat"` is rejected at compile time rather than silently ignored. The grammar has `!=` but no `not in`. ## What Three layers, in dependency order: 1. **Compiler mechanism** - resolve a negated analytics list filter to the engine's `<name>Not` argument. `FilterKey` resolution (`src/analyzer/sources/mod.rs`) does not look at the operator today; it needs a negatable variant (or an operator-aware `resolve`) that appends `Not` for `!=`. The analytics list field type needs a variant admitting `!=`. `transform_expression` (`src/transformer/expression.rs`) needs the negated counterpart of its `In` on has-one lists rule so a negated list reaches codegen in the same shape as a positive one. Shared by every analytics source, no grammar change. 2. **Multi-value exclusion** - the Spend panel excludes two values. Either `!=` accepts a list on the right-hand side (`flowType != ("chat", "agentic_chat/v1")`) or `not in` becomes an operator (`flowType not in (...)`). Both are grammar changes; #69 already asks for `not in` on Status, so this issue should settle the spelling once for the whole language. Decide before implementing layer 1 so the operator set is final. 3. **Per source** - admit negation on each filter as the rollout gives it a twin. Spend needs `flowType` on DuoWorkflows; the natural first batch is every string-list filter on the analytics sources (`flowType`, `status`, `event`, `feature`, `targetBranch`, `state`, ...). Numeric-ID filters (`user`, `project`) follow the same mechanism. ## Semantics to document - `NOT IN` drops rows where the column is NULL (engine decision in gitlab#629295). Irrelevant for `workflowDefinition`, relevant for nullable columns such as `projectId` on DuoWorkflows. The docs table for each source should say so per field. - `!=` with an empty list and the `ANY` / `NONE` tokens already have standard-mode meanings in `transform_expression`; the analytics path must not change them. ## Example ```yaml mode: analytics query: type = DuoWorkflow and group = "my-group" and created > -6M and flowType != ("chat", "agentic_chat/v1") dimensions: created(monthly), flowType metrics: creditsUsedSum ``` compiling to `duoWorkflows(createdAtFrom: "...", workflowDefinitionNot: ["chat", "agentic_chat/v1"])`. ## Sizing Layer 1 is shared compiler machinery without a language change; layer 2 is a language change; layer 3 is a per-source extension. Not on the DAP Impact v1 critical path - the include list works today - but the rollout needs a GLQL consumer or it ships unused. ## Blocked by - https://gitlab.com/gitlab-org/gitlab/-/work_items/629296 (rollout; itself blocked by https://gitlab.com/gitlab-org/gitlab/-/work_items/629295) ## References - #69 - `in`, `not in` and `!=` on Status (the `not in` spelling question) - #173 - every operator on the `type` filter compiles silently (the failure mode layer 1 must avoid on other fields) - Spend tab GLQL scan: https://gitlab.com/groups/gitlab-org/-/work_items/23470#note_3836601176 - Tracking: https://gitlab.com/gitlab-org/glql/-/work_items/188