How to read this documentation

The documentation is split into four levels — from the big picture for an executive to the reference for a developer. You don’t need to read it all in order: pick your section and your route.

Structure

Section	For whom	Contents
Platform	Executive, product, presales, procurement, security team	Why this instead of someone else’s office suite, what you get, what is delivered, customizing under your brand, parity with Word and Excel, security, the pilot, and commercial terms.
SumDoc	Architects and integrators of the document part	How the document editor works, how to install it, run it, and embed it in your application.
SumSheet	Architects and integrators of the spreadsheet part	How the spreadsheet editor works, where it runs, how to install and embed it.
SumDoc reference	Developers	All session commands (41), editor window methods (321), events and data types (487) — with fields.
SumSheet reference	Developers	All contract operations (208) by area, with request and response fields.

Reading paths

See it with your own eyes without installing anything. Document editor → spreadsheet with a cost estimate → twenty-three embedding examples and a project for documents. Both editors open right on the page and work for real: you can edit a paragraph in the document and change numbers in the estimate. The code of each example is shown right there.

An evaluation in one evening. What SumOffice is → What you get → Feature parity → Pilot and acceptance.

A technical prototype with SumDoc. Installing SumDoc → Quick start → Request and response objects → Session commands.

A technical prototype with SumSheet. Installing SumSheet → Quick start: the first project → How the API session works → Compute Contract reference.

Designing an SumDoc integration. Architecture → Lifecycle → Host API → the interaction contract → What to fix before integrating. The two pages in the middle describe an interface that is still being proposed rather than working: they are what the shape of the future contract is agreed on. What is available today — Readiness and boundaries.

Designing an SumSheet integration. Architecture: four layers → What happens from opening to saving → Runtimes → Integrating into an application → Readiness checklist.

A security review. Platform security → SumDoc responsibility and security → Risks and boundaries.

Status of the material

The documentation describes the verified foundation of the product. The exact set of calls and commands, availability commitments, the license, and the final capability profile are fixed by the appendices to the pilot and the agreement.

What the documentation is based on

The documentation is assembled from the specifications of both products and checked against their source code. Every number, command name, refusal code, and capability boundary is verified against the code before every change. If the documentation diverges from the product, the edit goes no further.

When the site is built, the checks run again — on a machine where there is no source code. There it is verified that the pages match their generator, that all links lead to existing pages, and that no internal material has made it into the public text. Command names are checked against a list taken from the delivery itself, and the number of operations against a list taken from the release’s core. If a check fails, there is no deployment.

This does not apply to the comparison with Excel: it relies on official Microsoft documentation, and the sources are named right on the page Capability map next to Excel.

The through line

The product and the business perimeter belong to you, and SumOffice is responsible for what happens to the document and the workbook inside. The boundary between them is narrow, verifiable, and fixed by the contract.