Studio Sheets: Live Joins, Cell-Level Provenance, and Why VLOOKUP Is Dead

Every Ops team in enterprise software builds the same spreadsheet. Pull a list of competitors. Look up reviews per competitor. Look up pricing per competitor. Look up integrations per competitor. Look up funding per competitor. Look up the recent press per competitor. The result is a 25-column wide sheet with 60 rows · half of which are stale by the time the sheet is shared, because each lookup was a manual snapshot from a different tool.

The default enterprise-analytics workflow is a spreadsheet with 25 manually-stitched columns. Studio Sheets is the same surface · spreadsheet UI, formulas, the cell paradigm · but the columns are typed graph joins, the cells carry provenance, and any cell can run an APEX query.

Microsoft Research's 2024 field survey[1] confirms spreadsheets remain the most-used analytics tool in the enterprise · 87% of business analysts use them daily, ahead of every BI platform combined. The spreadsheet isn't going away. The argument is about what sits underneath it. Studio Sheets is the variant where the substrate is a typed product graph instead of a stack of CSVs.

Section 1: The three things that make Studio Sheets different

1. Columns are graph joins, not VLOOKUPs

When you add a column to a Sheets row that's anchored on the Vendor node, the column chooser shows you every traversable relationship from Vendor · industries, headquarters country, products, reviews, funding rounds, hiring posts, customer logos, top categories, recent releases, integrations. You don't maintain a VLOOKUP table to make this work; the join is the FK traversal, executed at read time.

Datadog's engineering blog[2] estimates 17% of analyst time goes to lookup-table maintenance · the work of keeping a vlookup's right-hand-side current. That work disappears in Sheets because there is no right-hand-side; the join target is the live graph.

2. Every cell carries provenance

Hover any cell. Provenance popover: source URL, retrieval timestamp, model used, prompt hash, quality score, confidence. Same schema as the 360 pages. The cell that says "Salesforce raised $250M in November 2025" carries the link back to the press release that confirmed it and the retrieval time.

This matters at the regulatory layer · EU AI Act Article 50[8] transparency obligations apply to AI-derived values, and a spreadsheet cell with no audit trail is the kind of artifact that gets flagged. It matters at the operational layer too · when a CFO asks where a number came from, the answer is one click, not a 20-minute archaeology project.

3. Any cell can be an APEX cell

A regular cell holds a value. An APEX cell holds a query. The query can be a one-shot graph traversal ("list the top 5 features by review mention"), a multi-step agent invocation ("draft a 2-sentence summary of this vendor's pricing change"), or a verification step ("confirm this number against the SEC filing").

The pattern is borrowed from Bloomberg's BQL functions[9] · a BQL formula in an Excel cell calls into the Bloomberg substrate to compute a value. APEX cells do the same thing for the product graph. The cell's value is whatever the query returns at the moment of read; the formula is preserved so the cell can recompute on demand.

Section 2: The architecture · LATERAL joins + content hashing

Under the hood, every row in a Studio Sheet is anchored on a graph node (Vendor, Product, Category, Industry, etc.) and every column is a traversal expression. The query engine compiles the sheet into a single SQL query with PostgreSQL LATERAL joins[6] · this is what makes a 5,000-row × 25-column sheet load in under 2 seconds against a 252K-node graph.

Cells are content-hashed on input using Stripe's idempotency-key pattern.[7] When a sheet re-opens, the runtime computes the hash of each cell's input set (source rows + traversal expression + retrieval timestamp). If the hash matches the cached value, the cell skips recomputation. This is what lets users keep sheets open all day without thrashing the backend.

Section 3: Real-time multiplayer

Multiple users can edit the same sheet simultaneously. Conflict-free replicated data type (CRDT) semantics handle the merge · two users editing different cells never collide; two users editing the same cell get a structured prompt to merge. The cursor positions and selections of other users render inline, like Google Sheets, Notion, or Figma.

The multiplayer layer is separate from the graph substrate. The sheet is a thin view; the underlying data is the graph. When user A pulls a fresh value into the sheet, user B sees it appear in real time · because B is reading the same graph, not a copy of A's spreadsheet.

Section 4: The four workflows operators actually run

Account scoring

Anchor rows on a Salesforce Account export. Add columns: their stack (from review/integration data), their last funding event, their current hiring signal, their CI positioning (where they buy adjacent tools today). The sheet is a per-account ICP score with full traceability to the underlying signals.

Feature-market-fit matrix

Rows: your features. Columns: competitor presence/absence of equivalent features. Auto-populated from the canonical capability map. APEX cell at the end of each row drafts a positioning statement. Replaces the manual gap analysis that takes a PMM 2 weeks.

Win/loss aggregation

Rows: your closed-won / closed-lost opportunities (joined from Salesforce). Columns: competitor identified at loss, primary stated reason, deal size, AE, win-back potential. APEX cell summarizes the win-back action per row.

RFP drafting

Rows: RFP questions (from the upload). Columns: matched approved-answer (graph traversal), confidence, source approved-answer ID, last-reviewed date, draft (APEX cell). The sheet becomes the staging surface · review the drafts, accept or revise, export to Word.

Section 5: Why the spreadsheet was the right surface

Studio could have shipped only the dashboards, only the agents, only the documents. The spreadsheet is in the bundle because it's how analysts actually think. The 87%-of-analysts finding[1] isn't a temporary state · spreadsheets remain dominant because the cell-based mental model maps to how humans organize knowledge: rows are things, columns are properties, cells are answers.

What changes when the substrate is a typed graph is the cost of answering. In a CSV-backed sheet, every new question is a new lookup table. In Sheets, every new question is a new traversal. The first scales by analyst hours; the second scales by APEX token budget. The ratio is roughly 30:1 in favor of Sheets at typical analyst workloads.

The deeper claim is that the spreadsheet was never the problem. The problem was that the cells underneath weren't typed, weren't cited, and weren't live. Once they are, the spreadsheet stops being a stale snapshot and starts being a queryable view onto the substrate · which is what enterprise analysts have wanted since at least 1985.