Customizing for your brand

White-label delivery isn’t a cosmetic wrapper over someone else’s product; it’s a division of responsibility. The outward-facing product and the user journey belong to you. The meaning of the document and the spreadsheet — how the file is parsed, calculated, and written — stays in the core and doesn’t fork.

For the business this means one thing: the editor carries your name and lives in your process, but you don’t end up with your own version of the engine that you’d have to maintain, update, and audit for security.

Area	What you can change	What you can’t do
Brand	The product name, logo, tab icon, links to legal documents, shell colors.	Change document content bypassing the core.
Styling	Documents have five theme variables and a choice of light or dark theme. Spreadsheets don’t have such a list yet: the public embedding kit is still being finalized — what’s in it today.	Changing the canvas geometry with styles: page layout is calculated in the core, and the screen will diverge from the file.
Navigation	Your application’s routes, where open and save live, your own side panel, tooltips, and onboarding.	Relying on the internal structure of the interface: it changes without notice.
Commands	Showing commands based on declared capabilities, enabling and disabling them by your own rules, adding your own panels. For spreadsheets, the list of commands ships in the delivery as a registry: 472 commands on 28 interface surfaces, each recording where it lives and which checks cover it. You can plan from the registry; you can’t plan from screenshots.	Show commands that aren’t in the declared profile: the user will click and get a refusal.
Storage	Your own open and save adapters — or the ready-made WOPI client, if your document management system speaks it; version history, autosave rules, auditing.	Bypass the save contract or write to the document file directly.
Users	The account from your sign-in system, workspace context, roles.	Pass credentials into document data or into logs.
Events	Analytics and audit through the public set of events.	Treating internal interface events as a public contract.
Localization	Language packs, your own terminology in labels.	Split the meaning of the same command across different brands.

How deep you can go

• The ready-made shell. The ribbon, grid, dialogs, and File menu entirely from us, inside your window. For documents, the server option provides such a shell: the whole editor opens in an embed on your site. The standalone SumDoc surface for your own window isn’t it: today it’s a limited set that proves the embedding boundary, not a ribbon with dialogs (what’s in it).
• The mixed option. The document or spreadsheet canvas from us, while the interface frame, panels, and industry-specific commands are yours. The only one of the four that starts with a conversation rather than a download: for documents, the set of your own panels and menu items is fixed in the pilot; for spreadsheets, the public embedding kit is still being finalized.
• Core only. Your interface calls the public operations and renders what it gets back itself.
• Automation only. A headless process: batch processing, agents, checks, and document creation.

For developers

• Theme variables of the SumDoc surface: --fastdoc-accent, --fastdoc-background, --fastdoc-foreground, --fastdoc-muted, --fastdoc-paper.
• The SumSheet interface is driven by a registry of 472 commands — each records which of the 28 surfaces it lives on — besides the File menu and the Data, Insert, View, Layout, and Review ribbons, these are the canvas, the formula bar, dialogs, and the contextual ribbons for tables, pivots, and charts — and at which stage it becomes available; five commands are marked as not exposed outward — your own shell has nothing to show them with.
• Allowed and forbidden customization points of SumDoc — Responsibility and security; the boundary between the surface and the SumSheet core — the embedding kit.