From concept to pilot

The path from concept to delivery has several forks, and it’s best to walk through each before the work starts. They’re collected below as a table: the question, the possible answers, and what the choice changes.

Question	Options	What the decision affects
Where does the core run?	WebAssembly on the user’s side, a desktop app, or a process on the server.	This determines the deployment scheme.
Who owns the file?	A document management system, a local file, or object storage.	This determines the open and save sequence and how versions are handled.
Which objects are needed?	Cells, formulas, tables, charts, shapes, imported data.	This makes up the pilot’s capability matrix.
Which interface?	The ready-made surface, either under your brand or as a fully custom interface.	This determines what goes into the public call set and how deeply you can customize the look.
How are permissions passed?	View-only or editing, sheet protection, separation by tenant, permissions on data sources.	This makes up the session contract and the access checks.
How does the session live?	One tab, a desktop app process, a job on the server, returning to the app on a phone.	This determines timeouts, cancellation, and recovery.
Who operates it?	You yourselves, jointly, or us turnkey.	This determines availability commitments, monitoring, updates, and support.

The minimal architectural pilot

• One real, anonymized XLSX, and one business route.

• One chosen scheme: browser with WebAssembly, or a desktop app. Don’t mix the server and mobile variants into the first prototype.

• Your application starts an integration session and passes the file’s content and permissions; SumSheet returns the saved result and events.

• Reopening, behavior under concurrent edits, a refusal with no partial write, memory use, and response time are all verified.

• The outcome locks in the first version of the public interface, the capability matrix, what’s delivered, availability commitments, and the plan for reaching a production product.

The object model in one line

Your system starts an integration session → the core opens a workbook session → the surface shows the visible area → the user sends an operation → the core changes the revision and the history → saving creates a file → your system creates a new version. In other words, SumSheet is a surface around a single processor, sitting between your user’s session and your storage.

A ready-made statement and the API delivery plan

What’s already available

In short

SumSheet has programmatic access to the workbook’s structure inside it: sheets, ranges, cells, tables, and graphic objects. The Rust core returns typed projections and applies changes through a single operations contract. The surface already handles selection, clicks, double-clicks, invoking the context menu, and picking objects. This will open outward not as access to internal markup, but as a separate embedding kit: reading, semantic events, commands, and your own context menu items. Exactly what goes into the kit and which objects it covers is locked in by the pilot’s capability matrix. There’s no public kit yet — see the embedding kit.

What goes into the first embedding kit

These packages don’t exist yet

The names below are a plan, not something you can install today. The packages will be published together with the public embedding kit; the way to reach the workbook today is through the operations contract.

What remains a plan is the packages themselves, not the language they’ll speak. The embedding contract has already shipped as a separate version: event names, refusal codes, and the list of accepted formats are declared and don’t change arbitrarily — what’s in it. So you can design around these names right now; all you have to wait for is what implements them.

This is a separate kit from the @sumsheet/* packages collected in the embedding examples: those ship with the delivery and aren’t published to the public npm registry.

Package	Minimal contents
@sumsheet/embed	Creation, open and close, embedding in the page, session state, choosing the runtime.
@sumsheet/document	Workbook contents, selection, cell details, a range of values, an object inventory.
@sumsheet/events	Selection, activation, double-click, object selection, menu-opening, and workbook-change events.
@sumsheet/commands	Running operations, undo and redo, revision checking, typed results and refusals.
@sumsheet/ui-extensions	Context menu item providers, registering your own commands, panels, and actions within the allotted boundaries.

What needs to be finished before production handoff

• Separate the public types and names from the large internal operations contract.

• Lock in the event delivery order, whether they can be canceled, timeouts, and resource-release rules.

• Compile the list of object kinds under the pointer, and the selection rules based on permissions and available capabilities.

• Add versioning, a compatibility period, examples, test scaffolding, and a migration guide between versions.

• Run a pilot on your real scenarios with cells, tables, charts, and shapes, in the chosen environment.

The boundary of API stability

What’s worth promising is the interface model itself and the agreed contents of the first version, not the stability of today’s internal events, utility attributes, and global objects prefixed __f1. That’s the product’s internal design, not a delivery contract: it changes without notice.