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.

1. 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.

1. 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?

1. 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.

1. 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.