Architecture: objects and relationships

The solution consists of seven objects, and each has one responsibility. Two boundaries matter for you: what stays in your application and what passes to SumDoc. Everything about the window, brand, permissions, and storage is yours. Everything inside the open document is SumDoc’s.

[User / agent]
          | action
          v
[Your product: brand, permissions, card, process]
          | embed, open, save, receive events
          v
[Surface] <--> [Bridge to the application and the session contract]
                          | typed commands
                          v
                       [Rust core]
        model → layout → scene → write to file
                          |
                          v
                  [DOCX bytes and storage]

Object	What it does	Owner
Your application	The product window, brand, permissions, document card, and workflow.	You
The editor surface (Web Surface)	The ribbon, pages, input, selection, dialogs, and response to actions.	SumDoc, customizable under your brand
Bridge to the application	Connects your application and the editor; holds no document of its own.	The shared boundary
Document session	The lifecycle of one document and its revisions.	SumDoc contract
The Rust core	Reads, models, computes, validates, and writes the document.	SumDoc
Storage	The source file, versions, retention periods, and an access log.	You
Capability profile	The available features and limits of a specific delivery.	Agreed

The simplifying rule

One document — one main session. The surface shows the document and sends intents; the core decides whether an operation is allowed and what the saved file will become.

Why two parts

The core and the surface solve different problems and are joined by a narrow contract. This isn’t duplication: there’s no second document engine in JavaScript.

The core owns the document: it parses the DOCX, keeps its model and revision, computes the layout, checks every command — permissions, protection, an outdated revision — and writes the file. To every command it responds with a result, a warning, or an explicit refusal with a reason.

The surface shows the pages and turns a click, gesture, or input into a command for the core. It manages focus, language, theme, and reading mode, and sends events to your application. It doesn’t write the file and doesn’t stand in for the document.

Why Rust

A document is more than visible text. Inside a DOCX are relationships, styles, sections, tables, headers and footers, review data, and objects. Writing this back without loss needs a single owner of meaning, strict types, and the same core for the desktop, server, and mobile variants.

Why Web

The same surface embeds in any web view — on a computer, in a browser, on a phone. You don’t need to rewrite the editor for every platform, and the product’s look stays yours.

The boundary test

If an action changes the document’s meaning or what ends up in the file, the core decides. If an action changes only how it’s shown and how you interact with it, the surface and your application handle it.

Next

• What happens from opening the document to saving it — Lifecycle.
• What the product does with the document — the capability map.
• Where it embeds: computer, browser, server, phone — Platforms and deployment.
• Your first call on your own machine — Quick start.