What's coming next
What's not yet in the platform, in what order it will appear, and what each piece of work gives you. Plus a short formula for the offer.
Part of the platform hasn’t been brought to delivery yet, and it’s more honest to say so directly. Below is the order of work and what each piece will give you. You can plan a rollout by this list: it says what will appear before the rest.
| Order | What’s being built | What this gives you |
|---|---|---|
| 1 | A single capability matrix | One list for both products: what opens, what can be edited, what’s preserved without loss, and where the boundaries are. You can check it before the pilot, not after. |
| 2 | Evaluation kit | Both surfaces, a sample application, a quick start, and a correct result known in advance — to compare with what you got. |
| 3 | A set of documents for comparison | Twenty to fifty real files, run through us and through other office suites. The difference shows up in the documents, not in promises. |
| 4 | What happens with macros | Which calls are supported, which are deliberately rejected, under what security rules, and what to do with the ones that aren’t supported. |
| 5 | What happens with data queries | On real workbooks: what’s recognized, what’s preserved on write, what you can view, what you can refresh, and what you can create from scratch. |
| 6 | Stable names and versions | Package and type names will stop changing between releases, and versioning rules will tell you in advance whether an update will break your build. |
| 7 | A kit for the security team | The delivery inventory, signatures, the update and rollback process, vulnerability-fix timelines, and telemetry rules. |
Where the conversation starts
Section titled “Where the conversation starts”The platform’s formula fits in one sentence: your product plus SumOffice’s engines equals your own office platform. The detailed account exists as a foundation, so the short materials don’t promise more than they should.
The final formula of the offer
Section titled “The final formula of the offer”| What you get | What the end user gets | What the security team gets |
|---|---|---|
| Libraries and cores for documents and spreadsheets | Editing documents and spreadsheets inside the product they already use | A versioned call contract, a delivery inventory, and signatures — to the extent they exist in the current release (the seventh row of the queue above covers what’s still missing from this kit) |
| A ready-made interface — keep it as is, or replace it with your own | The work never leaves the application they already use | Document content never goes into logs — this is a condition of delivery; policies, leak control, audit |
| Adapters and scaffolding for your stack | Real documents open and save on day one | The lifecycle under control, acceptance that verifies no leaks |
| A capability matrix and a set of acceptance documents | Fewer unexpected losses during migration | Promises you can verify on your own files |
| A path for automation and agents | Scenarios run without manual clicking | Preview, approval, audit, and rollback |
The platform in brief
Section titled “The platform in brief”SumOffice gives your product its own embedded office engine: Word-grade documents and Excel-grade spreadsheets under your brand, in your storage, inside your security perimeter and your processes. The delivery includes the document and spreadsheet cores in Rust, an interface under your brand, a developer kit — working for documents, being finalized for spreadsheets — automation, and measurable compatibility through capability profiles and acceptance checks.
What already works
Section titled “What already works”Plans are easier to read next to what already works today: what SumDoc can do with a document, SumSheet’s capability map, and the boundaries we state outright.