- Step 1
Capture in your editor
An add-in in Word, Excel, PowerPoint, Docs, Sheets or Slides records edits to existing paragraphs, cells and slide text against stable identities. Capture runs while its pane is open; there is no background agent.
- Step 2
Review as a change request
Push the captured changes to a project. Reviewers see what moved, approve or ask for changes, and the project’s rules set how many approvals a merge needs.
- Step 3
Merge and record
A merge records its parents, resolutions and resulting state in an append-only, hash-chained log. The result can be pulled back into the file.
Version control for documents, spreadsheets and presentations
Dynodoc records edits to paragraph text, cell values and slide text in Word, Docs, Excel, Sheets, PowerPoint and Slides, routes them through review, and keeps the merged result in a hash-chained history that can be checked.
Pre-alpha 0.0.1b: a desktop app for Windows and Linux that keeps your workspace on your own computer, or a sample workspace in your browser. Add-ins ship as test installs; marketplace listings are not live. The engine, API and command-line tools are open source (MIT).
Illustration with sample content, not a screenshot of a real file.
WORKS WITH
How it works
Dynodoc runs beside the editor. It records changes against stable identities, routes them through review, and keeps the outcome in a log that anyone with access can check.
Supported editors
All six add-ins use the same capture protocol. Each tab shows an illustration of the pane that opens beside the file, with sample content, and what the add-in captures.
Capture runs while the pane is open, and there is no background agent. Structure and formatting changes go through edited-file push. Add-ins ship as test installs today; marketplace listings are not live, and installed-editor acceptance has not been run. Install steps and limits
Change requests and review
A change request shows which paragraphs, cells and slides moved. Reviewers approve or ask for changes, and the merge follows the project’s rules.
Word-level diffs
Changed words are marked inside the paragraph, cell or slide, so a reviewer reads the edit instead of the whole page.
Approvals with rules
A project can require one to five approvals before a merge. Owners and managers can override, and the audit log records that they did.
Policy floors
A project sets the minimum protection for every file inside it. A file can tighten the rules and never weaken them.
Example diffs in Word, Excel and PowerPoint
-Revenue grew sharply in Q3.+Revenue rose 12% in Q3.-=C4-B4+=C4/B4-1-Launch plan+Launch plan: October betaAn append-only, hash-chained history
Who changed what, and when, is recorded as typed events in a log that anyone with access can check.
Append-only
Events are never updated or deleted. Restoring or reverting adds a new commit that points back at its source; history is not reset.
Hash-chained
Each event’s hash covers the one before it, so changing the past breaks every hash after it. Anyone with access can walk the chain and check it.
Signed commits
Project commits in the open-source engine and CLI carry an Ed25519 signature from the author’s device key. Revoked keys stop signing; older signatures still verify.
- r44 MC Maya Chen 2 h agoMerged “Tighten the Q3 summary”Chained c04a77f2 e7d31b09
- r43 SO Sam Okoye yesterdayUpdated the headcount tableChained 5be2d814 c04a77f2
- r42 PN Priya Nair 2 days agoReworded the risks sectionChained a91f03c7 5be2d814
- r41 MC Maya Chen last weekImported from WordChained 00000000 a91f03c7
- SeqTimeEventActorSignatureChain
- #48 14:32 change_request.merged MCMaya Chen hash · 9c1e07a3 Verified
- #47 14:29 change_request.approved PNPriya Nair hash · 41d8b6f0 Verified
- #46 14:11 change_request.approved SOSam Okoye hash · e2a3590c Verified
- #45 13:58 change_request.opened MCMaya Chen hash · 7b60d4e1 Verified
- #44 10:04 version.named SOSam Okoye hash · 08f5c2a9 Verified
Illustrative project with synthetic names. The hash chain runs in the hosted workspace today; signed project commits are in the engine and CLI and are not yet the hosted default.
Projects, drafts and named versions
A project groups related files and gives people roles. Each file keeps its own history, drafts and change requests.
- Board update.docx Tighten the Q3 summary 2 hours ago
- Q3 budget.xlsx Update travel and contractor lines yesterday
- Launch plan.pptx Add the press embargo date 3 days ago
- README.md Describe the review rules last week
- Word 46%
- Excel 28%
- PowerPoint 18%
- Markdown 8%
Projects
Related Word, Excel, PowerPoint, CSV and Markdown files live together with one set of members and one set of rules.
Drafts
Each person can work in a private draft of a file and share selected changes when they are ready. Project-wide branches exist in the engine, and the workspace lists them read-only under Branches.
Named versions
Name a milestone such as Board pack v3 and return to it. Restoring creates a new change; newer work is not erased.
Recovery
Revert a past change or replay it onto the current version. Either one is a new commit that points back at the change it came from.
Where the project stands
Dynodoc is early software. The test count is from one run of the public engine repository’s CI on 20 October 2026 (UTC), and the schema is the one the hosted workspace has run since 23 October 2026. None of it counts customers, users or uptime.
1,285
Rust tests passing in the public engine’s CI on Linux, macOS and Windows (1,284 on Intel Macs, where one timing test is excluded).
6
editor add-ins, as test installs. No marketplace listing exists, and installed-editor acceptance has not been run.
47
PostgreSQL schema version, deployed on the hosted workspace.
Running the open-source engine
The engine, API and command-line tools are open source under the MIT licence. Run the API on your own machine against PostgreSQL 16. The workspace and website are not published as open source.
- Step 1
Start PostgreSQL 16 on loopback port 5548
task up - Step 2
Apply migrations with the operator login
task migrate - Step 3
Grant the restricted runtime login its allowlist
task db:grant-runtime - Step 4
Run the HTTP API on loopback port 8080
task run
First copy the two example env files, set the keys and create the restricted runtime login, as the engine README describes. The API listens on loopback only and never applies migrations itself. The commands need Docker, Rust and Task.
Common questions
Including what Dynodoc does not do.
What is Dynodoc?
Dynodoc is version control for documents written in Word, Google Docs, Excel, Google Sheets, PowerPoint and Google Slides. It records changes against stable paragraph, cell and slide identities, routes them through change requests and review, and keeps an append-only, hash-chained history that can be verified. Editing stays in those editors.
How is it different from track changes or version history?
Track changes and built-in version history live inside one file in one editor. Dynodoc keeps one history across files and editors: a project with private drafts, change requests with approval rules, named versions and a hash-chained log of who changed what and when. A change made in Excel and a change made in Word are reviewed in the same place.
Which editors and file types does it work with?
Word, Excel and PowerPoint through task-pane add-ins, and Google Docs, Sheets and Slides through Apps Script add-ons. You can add DOCX, XLSX, PPTX, CSV and Markdown files to a project. Dynodoc also has basic web editors for documents and spreadsheets, which are not the main product.
How does capture work?
An add-in watches the open file while its pane is open and records edits to existing paragraph text, cell values and formulas, and slide text. There is no background agent, so edits made while the pane is closed are picked up by pushing the edited file instead. A reviewer sees what was captured before anything merges.
Is the history tamper-evident?
Every event is appended and hashed together with the one before it, so altering an earlier event breaks every later hash, and anyone with access can verify the chain. That is tamper-evident, not tamper-proof: spotting a wholesale rewrite by a database administrator also needs a hash or backup you kept independently. External witnesses are planned, not shipped.
Can I self-host it?
Partly. The engine, HTTP API and command-line tools are open source under the MIT licence. The engine repository explains how to run them against PostgreSQL 16 with Docker, Rust and Task: task up, task migrate, task db:grant-runtime and task run. The workspace and website are not published as open source, so the full hosted application cannot be self-hosted from public source. Private document content you put in the hosted app does not become open source.
What does it not do?
There is no character-by-character co-editing and no live collaborator cursors; collaboration works through drafts, change requests and deliberate merges. The add-ins do not run in the background and do not capture every keystroke, layout change or embedded object. Dynodoc is not a replacement editor for Office or Google, and it makes no compliance claims.
What does it cost, and who can use it?
There is no paid plan and no payment flow yet. The hosted workspace at app.dynodoc.online is a test deployment with email and Google sign-in, and projects are invite-only: only their members can see them. You can start a sample workspace without an account (removed after 24 hours), or download the unsigned desktop workflow manager: Windows 0.1 alpha 1 and Linux 0.0.1c pre-alpha. It manages repositories, reviews, history and sync while you edit in Office or Google editors through the add-ins and extensions. The add-ins are test installs, not marketplace listings. The engine, API and command-line tools are open source, so you can run those yourself today. The terms and privacy policy are drafts and are not yet effective.
Try the pre-alpha
Start a sample workspace of your own (no account, removed after 24 hours), sign in to create your own projects, or install the desktop app for Windows or Linux. The hosted workspace is a test deployment with no paid plan.