# Design question — numeric/aggregate questions in memoria

State your exact model id at the top of your answer.

## Read first

- `docs/superpowers/specs/2026-09-03-memoria-design.md` — especially §0,
  §2 ("Never recomputes a number"), §4.1, §5, §7, §8.1, §8.2's routing
  table (the "Numeric / aggregate" row), §13 (chunking is open)
- `/home/paulca/amadan.net/oficina/sheets-core/docs/superpowers/specs/2026-08-30-sheets-design.md`
  — the calc engine, cell storage, tabs, sheet structure
- `/home/paulca/amadan.net/oficina/sheets-core/AGENTS.md` — especially
  "Cell values are IEEE doubles end to end" and the no-content-in-logs rule
- `/home/paulca/amadan.net/oficina/sheets-core/PRODUCT.md`

## Context

memoria is a per-team knowledge app indexing the team's content across
the Oficina suite (sheets, docs, calendar, external sources) into a
sealed hybrid BM25 + vector index, answering questions with citations. It
never evaluates authorization itself — it asks the owning app, per person,
per query (§4.1). It hibernates. Single Go binary, cgo-free SQLite, no GPU.

## The question, from Paul (the owner), 2026-09-03

He wants numeric questions to work, and gave this motivating example:

> **"what's average revenue in June the last 3 years"**

## The tension you must resolve

§2 of the spec says:

> **Never recomputes a number.** A question with an arithmetic answer
> cites the cell; Sheets' engine is the app of record. A brain that
> recalculates is a second calculator that disagrees with the first.

And §8.2 routes the "Numeric / aggregate" class to **no model**: "Cite
the cell or range; Sheets is the app of record."

But Paul's example has no cell to cite. No cell contains "average June
revenue over three years" — it must be *computed* from three or more
cells that may sit in different tabs, different sheets, or different
files (one per fiscal year). So the rule either forbids the feature Paul
wants, or needs qualifying.

## What I want

1. **Rule on the tension.** Options: memoria computes and shows its
   arithmetic; memoria asks Sheets to compute (a new sibling call —
   "evaluate this expression against these cells" — and what that costs);
   memoria returns the constituent cells and lets the person sum them;
   memoria writes a formula into a scratch sheet and cites it; the rule
   narrows to "never recomputes a value a sheet already computed". Weigh
   and rule. Say which option genuinely preserves "a second calculator
   that disagrees with the first" and which merely evades it.

2. **The sibling call, if you recommend one.** memoria holds no DEK for
   Sheets and must not gain a write path (§6.4). Specify it in the style
   of the spec's S1–S5 table, and say what it leaks that S1–S3 do not.

3. **Chunking a spreadsheet** — §13's open item. A 400-token chunk of a
   grid may be meaningless. Design it. Consider per-tab; per-region (a
   header row plus contiguous block); per-row with headers prepended; a
   structural summary (tab names, header rows, ranges, units) separate
   from value chunks. What makes "revenue", "June" and "2024" findable by
   BM25 *and* by embedding, when the literal cell is a bare number whose
   meaning comes from a row header two columns left and a column header
   eleven rows up?

4. **Retrieval shape for an aggregate.** Paul's question needs three
   facts, one per year, each possibly in a different document, and needs
   to know it found all three rather than two. How does top-k retrieval
   know its recall was complete? What does it say when unsure? This
   codebase treats "a plausible empty list, not an error" as the worst
   available failure shape — and a plausible *wrong average* from two of
   three years is worse still.

5. **What must NOT be built.** Name the version of this feature that
   would be a mistake, so the spec can forbid it explicitly.

Rule, don't survey. Cite spec sections. Be concrete about failure modes.
Do not edit any file. 900-1200 words.