SumSheet — what it is

An embeddable, Excel-class spreadsheet processor: where the core lives, how the layers connect, and what the public interface is proposed to become.

SumSheet is the spreadsheet part of the SumOffice platform: a spreadsheet engine with formulas, edit history, import and save, and with it a ready-made editor surface that you can replace with your own. It keeps only filled cells in memory, so large workbooks open without being expanded in full.

Your product — the document card, users, permissions, versions, audit, approval processes.
The editor shell — the ribbon, the grid, dialogs, the keyboard, displaying the result.
The operation contract (Compute Contract) — a single language of commands, results, errors, revisions, and events.
The SumSheet core in Rust — the workbook, formulas, operations, history, import and export, save.
The execution adapter — the core in the browser (WebAssembly) or a separate process on a computer or a server.

How to read this document

First — which parts SumSheet consists of and who is responsible for what: Architecture. Then — the path of one operation from a click to a saved file: Lifecycle. After that — where the core runs: in the browser, on a server, on a desktop computer, and on a phone (Runtimes). At the end — strengths and limitations and the capability map next to Excel.

Terms that come up across every section — workbook session, revision, viewport, explicit refusal — are collected in the glossary.

Six design principles

Six decisions that make SumSheet the way it is, and what each one gives you.

Principle	What it means for you
One Rust core	Formulas, cells, history, and the meaning of the file are not duplicated in JavaScript. The workbook computes the same way in the desktop app, in the browser, and in the shell.
One operations contract	The interface, automation, and application adapters go through one verifiable boundary. You get a stable set of calls instead of access to the internals.
Computing by visible area	Not the whole workbook goes into memory, only the requested part. Large workbooks open and are edited without being expanded in full.
A refusal instead of a silent error	A stale revision, an invalid request, and a rule-based denial give an explicit refusal — before anything changes. The workbook is not corrupted unnoticed.
An atomic history	An operation creates one record in the shared history — or does not change the workbook at all. Undo, redo, and the log stay consistent.
Ownership stays with you	Sign-in, storage, the metrics sink, network rules, and the brand are yours. Data does not leave your perimeter.

The future public interface

For developers — seven methods, from creating the engine to closing the workbook.

Method	What it returns	What it guarantees
`F1.create(...)`	A ready engine	Choosing the runtime, checking clearance, and agreeing on the contract version.
`engine.open(...)`	A workbook session	Its own identifier, declared capabilities, and the starting revision.
`document.getSnapshot(...)`	A projection of the requested range	The workbook is never unfolded entirely into memory without your knowledge.
`document.execute(...)`	The operation’s result	Either full success, or an explicit refusal with a reason.
`document.subscribe(...)`	A subscription	Session events arrive in a defined order.
`document.save(...)`	The save result	The format and the right to save itself are both declared explicitly.
`document.close()`	Nothing	A repeated call is safe, and resources are released exactly once.