Embedding modes

You don’t have to adopt the whole platform at once. You can start with a ready-made surface inside your product and then deepen the integration—to headless operation, to a separate process or to the core right in the browser. The meaning of a command doesn’t change along the way: it’s defined by the contract, not by the way data is transported.

Two things matter for the decision: where your product lives and where the data must stay. The mode is chosen by these two questions.

Mode	When to choose it	Readiness and boundaries
SumDoc inside a desktop application	You need a full DOCX editor inside your Windows or macOS program.	Verified on macOS; acceptance on Windows must be run separately. The reason is not a formality: on macOS text width is measured by the system font engine, on Windows and Linux by a portable one, so identical pagination across systems is not promised. That is exactly what to check at acceptance—on your own documents and your own fonts.
SumDoc in the browser	Your product lives on the web, and the user doesn’t need to install anything.	Works. The document is computed by the core on your server, one process per user. Several people edit one document at the same time: others’ input is visible immediately, the one who opened it first writes to the file, the rest are co-editors or observers as chosen at sign-in—the editor in the browser.
SumDoc headless	Batch processing, services, and agents that don’t need a screen.	Works as the session protocol; which part of it becomes public is agreed separately.
SumSheet in the browser	Embedding in a web product when data must not leave the browser.	Works. The core computes in the page’s memory and itself picks the fastest build the browser allows; if it didn’t take a faster one, it names the reason. The fastest, multithreaded build requires configuration on your site and a separate delivery—the core in the browser.
SumSheet as a separate process	Offline operation, local files, full speed.	Works. The process must be monitored, shipped with updates and shut down correctly—a separate core process.
Hybrid mode	A web interface, but with access to the file system and OS rules.	You need a secure channel between the interface and the core and a well-thought-out window lifecycle.
A server inside your own perimeter	Centralized processing, agents, pipelines.	A separate production architecture: access checks, isolated sessions, quotas and operations tooling—the processor on a server.
Preview without an editor	You need thumbnails, read-only pages or PDF from DOCX and XLSX, but no editor.	Works. One container with the SumDoc and SumSheet cores; the file is erased after the response, and no network is needed once the image is downloaded. PDF from a workbook is not produced yet, presentations and ODS are not accepted—preview without an editor.

What’s required in every mode

• One open document per process — the simplest and safest isolation for a pilot.
• The application learns the contract version before it shows the interface or sends the first command.
• Tokens, addresses, credentials, document text, and its source markup don’t go into logs by default.
• Closing releases everything: listeners, connections, background threads, files and child processes.
• An unknown command or capability is never executed silently: work stops, or a refusal with a reason comes back.

For developers

• How each mode works: SumDoc—platforms and deployment; SumSheet—the core in the browser, a separate core process, the processor on a server, phone and tablet.
• SumDoc desktop mode: your application plus a local service per document; HTTP and WebSocket on the local interface only; a WebView2 or WKWebView window. Headless mode: JSON lines over standard input/output, or WebSocket with a token.
• The multithreaded SumSheet build in the browser is enabled only when two conditions hold at once: the COOP and COEP isolation headers on your site and SIMD support in the browser; without either of them the core takes a simpler build and names the reason—the core in the browser.
• For the processor, the contract version is reported by the greeting line—it is read first; in the browser there is none, and the version is requested from the session with a contract_version() call—SumSheet runtimes.
• The success flag in the response envelope is not the whole story: for a document edit, the outcome is named in a separate field—how to read a response.