Dynodoc brings personal drafts, reviewable changes, and attributed history to documents and spreadsheets. Designed for teams that need to know what changed and who changed it.
Each paragraph, question, and spreadsheet row gets a permanent identifier when it is created.3,5 Edits are stored as typed events with an author, and each shared event is chained to the one before it with SHA-256.3,4 A restore adds a new event instead of rewinding the log.
How the record grows · illustration
Team versionv1
Field methods
NodeCreated5d1e…a09c
1 / 5 Maya writes the Sampling paragraph.
NodeCreatedMaya · 5d1e…a09c · prev 0000…0000
Illustrative names and shortened hashes. Draft revisions stay private and outside the team chain until shared; each shared event's hash covers its content, its author, and the previous hash.
Version control in everyday language.
01
Start with your work
Write a document or import a supported document, spreadsheet, or questionnaire file.
02
Make a personal draft
Try a change without altering the shared team version. Keep some work private while sharing selected changes.
03
Review the difference
Compare versions, see attribution, and resolve overlapping edits before combining the work.
04
Keep the record
Save named versions and restore earlier content as a new recorded change. Restoration preserves the intervening history.
What is implemented
One workspace, an accountable history.
Document editing with styles, comments, tracked changes you accept or reject, and supported Word interchange.
Spreadsheet editing with a documented formula subset, formatting, supported charts, and XLSX exchange.
Personal drafts, selective sharing, comparisons, explicit review of overlapping edits, named versions, and restore as a new recorded change.
Organization, team, and folder roles; revocable links to frozen public copies.
Imports from ODK Central, KoboToolbox, REDCap, SurveyCTO, and SurveyMonkey, plus CSV or XLSX files exported from CSPro.1 Imports are read-only: they create a new document, keep its provenance, and do not modify the source project or retain credentials.
Try a pilot with representative files and the people who will review them. Format compatibility and provider connections need acceptance testing against your actual workflow.
For engineers
Inspect the engine.
The standalone Dynodoc Engine is published under MIT as an early 0.1 source release, written in Rust with PostgreSQL. It covers append, verify, replay, snapshots, and merge; it does not include the browser editors or any production data.3 The Dynodoc application has its own AGPL licence and deployment requirements.
Verification recomputes the chain from stored events. It detects an inconsistent recorded chain; detecting a wholesale rewrite also needs a hash you kept elsewhere.
dynodoc-engine · verify and replay
# Build the MIT engine and check one document's recorded history.git clone https://github.com/ArefinAlter/dynodoc-enginecd dynodoc-enginecp .env.example .env # set PASETO_LOCAL_KEY and WEB_SERVICE_KEYtask up && task test # PostgreSQL 16 for the integration tests# Recompute the hash chain over the stored events and report any break.cargo run --locked -p engine-cli -- verify DOCUMENT_UUID# Rebuild the document state by replaying its events from the start.cargo run --locked -p engine-cli -- replay DOCUMENT_UUID
Sources
Evidence and further reading
Product claims on this page are checked against the live pilot and the published engine repository.
Dynodoc roadmap (opens in a new tab)Dynodoc · accessed 25 September 2026What is planned rather than available, including offline collaboration and higher-fidelity Word and Excel exchange, with no promised release dates.
03
Dynodoc Engine: README, guarantees and limits (opens in a new tab)GitHub, ArefinAlter/dynodoc-engine · 0.1 source releaseThe MIT engine's scope, its SHA-256 event chain and ULID node identities, the engine-cli verify and replay commands, and its stated limits: no CRDT, no offline replica, no external anchoring.
