---
title: 'Disambiguate the fixed annotation: column pinning versus decimal places'
type: task
status: draft
description: >-
  The query-view deriver reads annotation.fixed as 'pin this column' while react-table reads
  columnDef.fixed as decimal places, so a query column asking for decimals is pinned out of
  table_state.columns and can never be shaded.
base_uri: user:task/league/data-views/disambiguate-fixed-annotation-pin-versus-decimals.md
created_at: '2026-09-20T15:40:41.115Z'
entity_id: b2348fd8-5934-416d-8607-731509bb8453
owner_identity_uri: █████████████████████████
public_read: true
relations:
  - relates [[█████████████████████-████████████████-███████-█████-██████-████████]]
  - relates [[█████████████████████-█████████-█████-██████-████-████████]]
tags:
  - user:tag/league-xo-football.md
  - user:tag/software-task.md
updated_at: '2026-09-20T15:40:55.784Z'
visibility_analyzed_at: '2026-11-05T23:48:47.590Z'
---

# Disambiguate the `fixed` annotation: column pinning versus decimal places

## The collision

One key name means two unrelated things on the two sides of the query-backed view boundary.

- **The server deriver** reads `annotation.fixed` as "pin this column". `libs-server/data-views/derive-view-from-query-result.mjs` copies it onto the descriptor and pushes the alias into `prefix_columns`, which takes it OUT of `table_state.columns`.
- **react-table** reads `columnDef.fixed` as the number of decimal places to render (`src/table-cell/table-cell.js`, the `fixed` branch around the value formatter).

## The consequence

A query column that asks for three decimal places is instead pinned to the left of the table, removed from `table_state.columns`, and can therefore never carry percentile shading — shading is computed over the columns in `table_state.columns`. So the author gets the opposite of what they asked for, silently, and loses a feature they did not know was connected.

This is pre-existing and caps [[█████████████████████-████████████████-███████-█████-██████-████████]] rather than being caused by it. It is also a live trap for any author of a sandboxed-SQL view, including the generation agent on its query branch.

## Why it was not absorbed into the shading work

Renaming an annotation key is its own migration: stored `column_annotations` blobs in `data_view_queries` carry the old spelling, the deriver's reconciliation is total in both directions so an unknown key is a hard rejection, and there is a deploy-ordering question between the server that accepts the new name and the rows that carry the old one.

## What a plan here has to settle

- Which side keeps the name `fixed`, and what the other one becomes. react-table's meaning is the one shared with every other consumer of that component, so the deriver's pinning sense is the likelier one to rename.
- Whether the deriver accepts both spellings for a window, and for how long, given that reconciliation is total and an unknown key is a rejection rather than an ignored field.
- Whether any stored row actually uses `fixed` today — measure before designing the migration, since the population may be zero and make most of this moot.
- The `AGENT_INSTRUCTIONS` and the three annotation-key enumerations (`scripts/create-data-view-query.mjs`, `scripts/ABOUT.md`, `docs/data-views-architecture.md`) all need the settled name.