From c5b12aac7639d1d18aea60130410e0f39a3337c5 Mon Sep 17 00:00:00 2001 From: Paul Trowbridge Date: Mon, 17 Aug 2026 21:47:55 -0400 Subject: [PATCH] Record DuckDB virtual-server spike findings; choose display-grain pre-aggregation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Document the outcome of the Option C spike (server-side DuckDB as a Perspective virtual server) and the resulting architecture decision. pf_perspective_options.md: - Spike findings: latency is excellent (~12ms round trip, 5-29ms aggregation, ~1.5-1.9s to materialize 534,902 rows) but Perspective's GenericSQLVirtualServerModel ignores group_by_depth and has no ViewConfig field for per-node expansion state, so interactive drill-down is not achievable. This affects options B, C and D alike since they share that SQL model. - Decision: the real lever is grain, not transport. Pre-aggregating to display grain collapses 534,902 -> 4,642 rows (~115x) on osm_stack while keeping the native Perspective engine, so expand/collapse/ depth/sort/filter continue to work. - Two candidate designs (Path A live virtual server vs Path B pre-aggregated extract) with the deciding question: do real cuts ever exceed the browser's leaf-row ceiling? pf_spec.md: - Concrete Path B design: pf.col_meta.in_grain, GET /api/versions/:id/agg, synthetic pf_gkey index, and the append-deltas write/undo model that mirrors the prior Excel pivot-cache workflow. Drop pf_ux_mockup.md — an ASCII mockup of UI that is now built; the views in ui/src/views are the current reference. Co-Authored-By: Claude Opus 5 --- CLAUDE.md | 1 - pf_perspective_options.md | 210 ++++++++++++++++++++++++++++++++++++++ pf_spec.md | 124 ++++++++++++++++++++++ pf_ux_mockup.md | 112 -------------------- 4 files changed, 334 insertions(+), 113 deletions(-) delete mode 100644 pf_ux_mockup.md diff --git a/CLAUDE.md b/CLAUDE.md index 1554c39..9591095 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -6,7 +6,6 @@ A web app for building named forecast scenarios against any PostgreSQL table. Th Full spec: `pf_spec.md` Data transport architecture options: `pf_perspective_options.md` -UX mockup: `pf_ux_mockup.md` --- diff --git a/pf_perspective_options.md b/pf_perspective_options.md index da07388..00eb32d 100644 --- a/pf_perspective_options.md +++ b/pf_perspective_options.md @@ -255,3 +255,213 @@ A reasonable phased path: do A first (fast, low risk, ships value this week), live with it while planning, then move to D when row counts demand it. C is a different shape and probably not warranted unless multi-user emerges as a requirement. + +--- + +## Spike findings — Option C (server-side DuckDB virtual server), 2026-06-18 + +A working spike was built to measure Option C on the real ~535k-row forecast +(`pf.fc_osm_stack_20`, version 20). It is opt-in behind `?engine=duck` and does +not touch the default client-side WASM path. + +**Architecture built.** Perspective's `VirtualServer` + `GenericSQLVirtualServerModel` +run in the browser (reusing the already-loaded viewer WASM) and turn each +interaction into SQL. That SQL is POSTed to a new server endpoint +(`routes/perspective.js`, `POST /api/perspective/sql`) and executed against a +persistent in-process DuckDB that has the forecast table materialized from +Postgres. Only generated SQL + the aggregated viewport (Arrow IPC) cross the +wire. Files: `routes/perspective.js`, `ui/src/duckServerHandler.js`, a branch in +`Forecast.jsx`, and the `duckdb` node dependency. + +**Latency — excellent, not the bottleneck.** + +| Measure | Result | +|---|---| +| Materialize 534,902 rows into DuckDB (one-time, startup) | ~1.5–1.9 s | +| Pivot aggregation in DuckDB (1-col / 3-col rollup / filtered) | 5–29 ms | +| Per-query round trip incl. HTTP + Arrow (browser ↔ server) | **~12 ms** | +| Initial load (no rows over the wire — just schema + first viewport) | sub-second | + +This is far below the doc's earlier 50–200 ms estimate and dwarfed by today's +~2-minute cold load on this dataset. + +**Blocking limitation — no interactive group-tree drill-down.** Perspective's +generic SQL virtual server cannot drive the expandable rollup tree this app is +built around: + +- `group_by_depth` is **ignored** by the SQL generator — verified by running + `GenericSQLVirtualServerModel` headlessly: the generated `tableMakeView` / + `viewGetData` SQL is byte-identical for depth 0/1/2/undefined. It always emits + the full `GROUP BY ROLLUP(...)`. +- The imperative `view.set_depth()` emits a `ViewSetDepthReq` the virtual server + does not handle → `Abort(): Unhandled request`. +- `ViewConfig` has **no field to express per-node expansion state**, so + expand/collapse cannot be communicated to the SQL model at all. The server + returns a static full rollup; the grid cannot reflow it. (Per-node +/- fires + the SQL round trips but produces no visual change.) + +What makes expand/collapse/depth work *today* is Perspective's own WASM view +engine computing the tree. The virtual server **replaces** that engine with the +SQL model, which does not implement dynamic expansion. + +**This limitation is not Option-C-specific.** Options **B, C, and D** all use the +same `DuckDBHandler` / `GenericSQLVirtualServerModel`. Any DuckDB-backed virtual +server therefore inherits the same loss of interactive tree expand/collapse/depth. +**Only Option A** keeps rows in a native Perspective `Table`, preserving full +interactivity. + +**Implementation gotchas worth recording:** + +- The SQL generator must be constructed from the *initialized* viewer WASM module + (`customElements.get('perspective-viewer').__wasm_module__`), not the bare + `@perspective-dev/client` default export — the latter's wasm glue is undefined + and `new perspective.GenericSQLVirtualServerModel()` throws. +- The handler must implement **both** `viewColumnSize` (→ `COUNT(*) FROM (DESCRIBE v)`, + column count) **and** `viewSize` (→ `COUNT(*) FROM v`, row count). The reference + `duckdb.ts` only shows `viewColumnSize`; omitting `viewSize` breaks row-count + rendering. +- DuckDB Arrow IPC output needs `INSTALL arrow FROM community; LOAD arrow;` + (the `to_arrow_ipc` table function is not built in to 1.x). +- DuckDB reads the pg forecast tables directly via `postgres_scanner` + (`ATTACH ... TYPE postgres, READ_ONLY`); the spike materializes a native copy so + aggregations are pure-columnar (writes would require a re-materialize/refresh). + +**Conclusion.** The latency case for server-side DuckDB is strong, but the generic +SQL virtual server cannot support this app's expandable pivot UX. Choosing any +B/C/D path means either (a) writing a custom virtual server that implements +depth/expansion in SQL (rebuilding what the generic model omits), or (b) accepting +flat/fully-rolled-up views with no interactive drill-down. To keep the current UX, +**Option A** (optimize the encode/transport, keep the native Perspective table) is +the path. + +--- + +## Decision — display-grain pre-aggregation (2026-06-18) + +The spike showed the real lever isn't the *transport*, it's the *grain*: the +browser pivots at a coarse display grain (e.g. `rep × customer × month`) but we +ship raw transaction rows. Pre-aggregating to that grain server-side (DuckDB or +plain pg `GROUP BY`) collapses **534,902 → 4,642 rows** (≈115×) on `osm_stack`, +and adding more dimensions barely moves it (4,642 → 4,743 with director + +channel) because the raw detail (part/plant/day/currency…) all rolls up. + +This is the chosen direction. It is essentially "Option A done right" — reduce +**rows** by aggregating to grain, not just trim columns — and it keeps the +**native** Perspective engine, so expand/collapse/depth/sort/filter keep working +(the capability B/C/D sacrifice). The DB does the heavy aggregation (~25 ms); +the browser receives a few thousand native rows. + +**Why it beats the alternatives here:** + +- vs. current: ~250 MB / ~2 min → a few hundred KB / sub-second; render instant. +- vs. B/C/D (DuckDB virtual server): keeps interactive drill-down; no per-drag + round trips; no custom SQL generator to own. +- The undo "full reload" wart disappears — a re-pull is now ~25 ms. + +**Trade-offs accepted:** additive measures only (sums exact; averages = sum+count; +distinct-counts not pre-aggregatable — fine for forecast); a view only supports +the dimensions in its grain (handled by re-fetching at a new grain when the user +changes group/split/filter, or by choosing a grain that covers the pivot set +while avoiding high-cardinality dims like `part`). + +**This is a port of the prior Excel model.** The forecasting process previously +ran in Excel: pre-aggregated rows were sent to a data tab, pivot tables cut them +locally any way the user wanted, double-clicking a pivot cell let VBA capture the +slice and present an adjustment UI, and incremental rows were built in the DB, +**appended** to the data tab, and the pivot cache refreshed to include them. That +maps 1:1 onto native Perspective (pivot cache = the WASM view) — which is *why* +the native engine matters and the virtual server was the wrong fit: Excel never +re-queried the DB on every pivot move. + +**Write/read model** (append deltas, let the view sum — the pivot-cache pattern; +single source of truth = pg raw rows): + +- **Initial load** — `GET /api/versions/:id/agg`, `GROUP BY` grain × `pf_iter` × + `pf_logid` → Arrow → native table indexed by a synthetic `pf_gkey`. +- **Write (scale/recode/clone)** — operation's final CTE returns just the new + `pf_logid`'s rows aggregated to grain → `table.update()` **appends** them; the + view re-sums. No bucket-total recomputation (keying on `pf_logid` keeps each + op's contribution a distinct row, so appends accumulate). +- **Delete (undo)** — `table.remove()` that logid's `pf_gkey`s; the view re-sums. + No re-aggregation, no emptied-bucket handling. (Or re-pull `/agg`, now cheap.) + +**Concrete design** (schema flag `col_meta.in_grain`, the `/agg` endpoint, the +synthetic `pf_gkey` index, and the operation/undo SQL templates) is specified in +`pf_spec.md` → §Display-grain pre-aggregation. + +--- + +## Two candidate designs for server-side aggregation (open — 2026-06-18) + +Both keep **Perspective as the client** and **DuckDB/pg as the aggregation +engine** over raw pg rows (the source of truth), and both rely on additive +measures (sums; avg = sum+count; no distinct-count). The target experience for +both is "Excel PivotTable against a Power BI / SSAS tabular model": a good-looking +pivot driven by a fast columnar engine. They differ in **where the rollup happens** +and therefore **what crosses the wire** — which trades off against each other. + +### Path A — Live server aggregation (virtual server) + +- **Reads:** Perspective runs as a virtual server; each interaction → + SQL → DuckDB → just the viewport cells. Requires a **custom depth-aware SQL + generator** replacing `GenericSQLVirtualServerModel` (honor `group_by_depth`, + reproduce the `__ROW_PATH__`/`__GROUPING_ID__` contract, and eventually + `split_by`'s dynamic pivot + expression columns). +- **Writes/undo:** write raw rows to pg; the next query reflects them (re-query / + invalidate) — no client-side row bookkeeping. +- **Pros:** unbounded dataset — only the visible viewport ever ships; always live; + the truest "any cut, any size." +- **Cons:** the generator is a real component to build and own; **per-node** + expand/collapse is a hard frontier (the protocol delivers only a global depth to + the JS handler, not per-node expansion state — that needs a Rust/protocol fork); + per-interaction latency (~12 ms + RTT, measured in the spike). +- **Excel analog:** live SSAS / Power BI **MDX** connection. + +### Path B — Pre-aggregated extract per cut (native table) + +- **Reads:** the server ships a flat `GROUP BY` to the **current pivot's field + grain**; the result loads into a **native** Perspective table, and Perspective's + own engine does all rollup/expand/collapse/depth/sort **locally, with zero + calls**. A server round trip happens **only when the field set changes** + (add/remove a dimension, or filter on a non-grain dimension) — not on + expand/collapse/sort or moving a field between rows and columns. +- **Writes/undo:** append grain-aggregated delta rows keyed by `pf_logid`; the view + sums them. Undo removes that logid's rows. (The append model — concrete design in + `pf_spec.md` → §Display-grain pre-aggregation.) +- **Pros:** the server SQL is trivial and fully owned (no tree contract to + reproduce); zero-latency native interaction; native look/feel; payload is small + (only the pivot's columns, only distinct grain rows). +- **Cons:** ships the **entire current-grain leaf set**, not just the viewport — so + a high-cardinality cut (anything × `part`-like) can be large and eventually hit + Perspective's ~1–2M-row WASM ceiling; pays a re-fetch when the field set changes. +- **Excel analog:** Power Query **extract → pivot cache**. + +### Comparison + +| | Path A — live virtual server | Path B — pre-agg extract | +|---|---|---| +| Where rollup happens | server, per interaction | client (native), per cut | +| Crosses the wire | visible viewport only | whole current-grain leaf set (pivot cols only) | +| Expand/collapse/sort | server round trip each | local, zero calls | +| Server-side code | custom SQL generator (large) | flat `GROUP BY` (trivial) | +| Dataset ceiling | none (viewport only) | ~1–2M rows per cut (WASM) | +| Per-node expand | needs protocol/Rust fork | native (free) | +| Interaction latency | ~12 ms + RTT | 0 (local); re-fetch only on field-set change | + +### The deciding question + +It comes down to one thing: **do real cuts ever produce a leaf grain too large for +the browser?** + +- If practical cuts stay under ~1M leaf rows → **Path B** — dramatically less code, + all of it yours, native feel, no generator to maintain. +- If you need truly unbounded any-cut-any-size → **Path A** — at the cost of + building/owning the generator and accepting the per-node-expand frontier. + +**Hybrid (future option):** default to B; when a requested grain's distinct count +exceeds a threshold, fall back to A (virtual server) for that cut. Best of both, +more moving parts. Worth noting but not for a first build. + +Next step toward deciding: map which dimensions are safe in a Path-B grain vs. +which are high-cardinality landmines (`part`, day-level dates, etc.) on the real +data — that tells us where B's ceiling actually bites. diff --git a/pf_spec.md b/pf_spec.md index b8c85cd..62b2362 100644 --- a/pf_spec.md +++ b/pf_spec.md @@ -714,6 +714,129 @@ DELETE FROM pf.log WHERE id = {{logid}}; --- +## Display-grain pre-aggregation (planned) + +**Status:** designed, not yet built. This is the concrete design for **Path B** +(pre-aggregated extract → native Perspective table) of two candidate designs; +rationale, the Path A alternative (live virtual-server aggregation), the spike +evidence, and the A-vs-B trade-off live in `pf_perspective_options.md` +(§Two candidate designs, §Spike findings). + +**Problem it solves.** The current transport ships every raw forecast row to the +browser (≈535k rows / ~250 MB / ~2 min on `osm_stack`). Perspective then pivots +them in WASM. Pre-aggregating server-side to the grain the pivot actually +displays collapses the payload dramatically — measured 534,902 → **4,642 rows** +at `rep × customer × month` (≈115×) — while keeping Perspective's **native** +engine, so expand/collapse/depth/sort/filter all keep working (unlike the DuckDB +virtual-server path, which loses them). + +### Grain definition — `pf.col_meta.in_grain` + +Add a boolean `in_grain` to `pf.col_meta`. At **Generate SQL** time the flagged +columns (plus `pf_iter`, always) define the display grain; `value`/`units` +columns are the additive measures summed to that grain. The grain is baked into +the stored `pf.sql` templates, so initial load and operations agree on it. + +- A date column enters the grain at **period** resolution (via `dim_period_col`, + e.g. month `sdat`), not raw date. +- **Constraint — additive measures only.** Sums (sales, qty, units) are exact. + Averages must ship as `sum` + `count` and be derived; `count(DISTINCT …)` + cannot be pre-aggregated. Forecast measures are sums, so this holds. +- Dimensions **not** in the grain are unavailable for pivot/filter on that view. + Either include every dimension users pivot on (cardinality permitting — a + high-cardinality dim like `part` explodes the grain back toward raw), or + re-fetch at a new grain when the user changes `group_by`/`split_by`/`filter` + (each change = one ~25 ms aggregate returning a small native dataset). + +### Initial load — `GET /api/versions/:id/agg` + +Replaces the raw `/data` stream for grain-based versions. Aggregates the forecast +table to the stored grain and returns Arrow IPC: + +```sql +SELECT + {{grain_cols}} + ,pf_iter + ,pf_logid + ,{{grain_key}} AS pf_gkey -- synthetic index, see below + ,SUM({{value_col}}) AS {{value_col}} + ,SUM({{units_col}}) AS {{units_col}} +FROM {{fc_table}} +GROUP BY {{grain_cols}}, pf_iter, pf_logid +``` + +Client loads the result into a native `worker.table(buffer, { index: 'pf_gkey' })`. +The Perspective **view** sums measures across these rows for whatever the user +pivots on — exactly as an Excel pivot cache sums the data tab. + +**Model — append deltas, let the view sum (the Excel pivot-cache pattern).** This +is a direct port of the prior Excel workflow: pre-aggregated rows go to the table, +the pivot cuts them locally, and each adjustment is *appended* — never a +recomputed total. So rows are aggregated to grain **per `pf_logid`** (one row per +grain × `pf_iter` × originating log entry), and the view sums them. This is also +the smallest change from today's code, which already appends operation results via +`table.update()` and lets the view sum — we just feed pre-aggregated rows. + +**Synthetic key.** Perspective's index is a single column, so emit +`pf_gkey = {{grain_cols}} || pf_iter || pf_logid` (concatenated). Including +`pf_logid` keeps each operation's contribution a **distinct** row, so appends +accumulate (rather than replacing a bucket) and a delete can remove exactly that +operation's rows. + +### Write path (scale / recode / clone) — append the new log entry's rows + +Operations INSERT raw rows into `{{fc_table}}` under a new `pf_logid` as today; the +final CTE returns just **that log entry's rows aggregated to grain**: + +```sql +WITH +ins AS ( + INSERT INTO {{fc_table}} ( … ) SELECT … RETURNING {{grain_cols}}, pf_iter, pf_logid +) +SELECT + {{grain_cols}} + ,pf_iter + ,pf_logid + ,{{grain_key}} AS pf_gkey + ,SUM({{value_col}}) AS {{value_col}} + ,SUM({{units_col}}) AS {{units_col}} +FROM ins +GROUP BY {{grain_cols}}, pf_iter, pf_logid +``` + +Client applies `table.update(rows)` — these are new `pf_gkey`s, so they append and +the view re-sums. No bucket-total recomputation. (Aggregating `FROM ins` is safe +because each row carries the new, unique `pf_logid`.) + +### Delete path (undo) — remove that log entry's rows + +A logid's rows are uniquely keyed, so undo just removes them and lets the view +re-sum — no re-aggregation, no emptied-bucket handling, no snapshot caveat: + +```sql +DELETE FROM {{fc_table}} WHERE pf_logid = {{logid}} +RETURNING DISTINCT {{grain_cols}}, pf_iter, pf_logid; -- → pf_gkeys to remove +DELETE FROM pf.log WHERE id = {{logid}}; +``` + +Client applies `table.remove(pf_gkeys)`. (A wholesale re-pull of `/agg` is an even +simpler fallback and is now cheap — ~25 ms.) + +### What this preserves / changes + +- **Preserves:** native Perspective interactivity, layout persistence, and the + slice-click → operation flow (a clicked grain cell still maps to a `WHERE` on + raw rows). pg raw rows remain the single source of truth. +- **Changes:** operation responses return grain-aggregated rows for the new + `pf_logid` (not raw `RETURNING *`); `/data` is superseded by `/agg` for grain + versions; the table is indexed by `pf_gkey` instead of `pf_id`; undo becomes a + targeted `table.remove()` and the "full reload" wart disappears. +- **Lineage:** this is a port of the prior Excel model — pre-agg rows → pivot + cache → double-click slice → VBA adjustment UI → append incremental rows → + refresh cache. The append-and-sum write/undo model mirrors that directly. + +--- + ## Admin Setup Flow (end-to-end) 1. Open **Sources** view → browse DB tables → register source table @@ -741,6 +864,7 @@ DELETE FROM pf.log WHERE id = {{logid}}; ## Open Questions / Future Scope +- **Display-grain pre-aggregation** — ship the pivot at its display grain instead of raw rows; see §Display-grain pre-aggregation above and `pf_perspective_options.md`. This is the chosen direction for the load-time + interactivity problem. - **Baseline replay** — re-execute change log against a restated baseline (`replay: true`); v1 returns 501 - **Approval workflow** — user submits, admin approves before changes are visible to others (deferred) - **Territory filtering** — restrict what a user can see/edit by dimension value (deferred) diff --git a/pf_ux_mockup.md b/pf_ux_mockup.md deleted file mode 100644 index 1c6c2ce..0000000 --- a/pf_ux_mockup.md +++ /dev/null @@ -1,112 +0,0 @@ -# Pivot Forecast — UX Mockup - -``` -┌─────────────────────────────────────────────────────────────────────┐ -│ Pivot Forecast │ -│ ① Setup ② Baseline ③ Forecast ◀ (default landing) │ -└─────────────────────────────────────────────────────────────────────┘ - - -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - ① SETUP -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -┌──── All Tables ──────────────┐ ┌──── Registered Sources ─────────┐ -│ schema table rows │ │ │ -│ ────── ────────── ────── │ │ sales_orders ✓ SQL ready │ -│ public sales_orders 48,291 │◀─│ invoices ✓ SQL ready │ -│ public invoices 12,004 │ │ + Register table │ -│ public products 891 │ └──────────────────────────────────┘ -│ rpt summary_mv 3,442 │ -└──────────────────────────────┘ ┌──── Col Meta: sales_orders ─────┐ - │ column role key label│ - │ ────────── ──────── ─── ─── │ - │ customer dimension ✓ │ - │ channel dimension ✓ │ - │ part dimension │ - │ geography dimension │ - │ order_date date │ - │ ship_date filter │ - │ status filter │ - │ units units │ - │ revenue value │ - │ internal_id ignore │ - │ │ - │ [Generate SQL ▶] │ - └──────────────────────────────────┘ - - -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - ② BASELINE -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - - Source [sales_orders ▾] Version [FY2026 Plan ▾] [+ New version] - -┌──── Segments ──────────────────────────────────────────────────────┐ -│ # description rows by date │ -│ ─ ──────────────────────────── ────── ────── ────────────── │ -│ 1 FY25 actuals +1yr 41,204 paul Apr 24 │ -│ 2 Open orders 3,109 paul Apr 24 [Undo] │ -│ │ -│ Total baseline rows: 44,313 [Clear all baseline] │ -└────────────────────────────────────────────────────────────────────┘ - -┌──── Add Segment ────────────────────────────────────────────────────┐ -│ │ -│ Description [ ] │ -│ │ -│ Filters [+ Add filter] │ -│ ┌─────────────────┬──────────┬─────────────────────┬───┐ │ -│ │ order_date │ BETWEEN │ 2025-01-01 2025-12-31│ x │ │ -│ └─────────────────┴──────────┴─────────────────────┴───┘ │ -│ │ -│ Date offset [1] yr [0] mo │ -│ │ -│ ·───────────────────────────· source │ -│ Jan 2025 Dec 2025 │ -│ ·───────────────────────────· projected (+1 yr) │ -│ Jan 2026 Dec 2026 │ -│ │ -│ Note [ ] [Load Segment] │ -└────────────────────────────────────────────────────────────────────┘ - -┌──── Reference (optional) ──────────────────────────────────────────┐ -│ Load prior-period rows for comparison in the pivot │ -│ Date range [2024-01-01] to [2024-12-31] │ -│ Note [ ] [Load Ref] │ -└────────────────────────────────────────────────────────────────────┘ - - -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - ③ FORECAST source: sales_orders -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - - Version [FY2026 Plan ▾] [Refresh] [Save layout] [Reset layout] - -┌──── Pivot ───────────────────────────────┐ ┌──── Operations ───────┐ -│ │ │ │ -│ (Perspective viewer) │ │ Slice │ -│ │ │ channel = WHS │ -│ channel │ Jan 2026 │ Feb 2026 │ ... │ │ geo = WEST │ -│ ──────────┼──────────┼──────────┼─── │ │ │ -│ DIR │ 412,000 │ 388,000 │ │ │ [Scale][Recode] │ -│ WHS ◀ │ 290,000 │ 310,000 │ │ │ [Clone] │ -│ ──────── │ │ │ │ │ ─────────────────── │ -│ Total │ 702,000 │ 698,000 │ │ │ Value incr [ ] │ -│ │ │ Units incr [ ] │ -│ │ │ Pct? [ ] │ -│ │ │ │ -│ │ │ Note [ ] │ -│ │ │ │ -│ │ │ [Submit] │ -└──────────────────────────────────────────┘ └───────────────────────┘ - - ▼ Change log (12 entries) - ┌────┬───────────┬──────────┬─────────────────────────┬────────────┐ - │ id │ operation │ by │ slice │ │ - │ ── │ ───────── │ ──────── │ ───────────────────── ─ │ │ - │ 12 │ scale │ paul │ channel=WHS geo=WEST │ [Undo] │ - │ 11 │ recode │ paul │ part=OLD-SKU │ [Undo] │ - │ 10 │ scale │ paul │ channel=DIR │ [Undo] │ - └────┴───────────┴──────────┴─────────────────────────┴────────────┘ -```