Live release (23 October 2026): workspace/API 3fa06fd, schema 47 (release record).
Pre-alpha 0.0.1a (25 October 2026): a sample workspace of your own in the browser (removed after
24 hours, no account) and an unsigned desktop app for Windows and Linux on the Releases page; see https://dynodoc.online/try.
Earlier releases deployed revocable sessions, verified snapshots, restricted API database credentials,
project policy floors/audited metadata, scoped CSP/HSTS and workload admission
after upgrade/rollback rehearsal. Read release evidence
and the next storage/offline priorities.
Version control and provenance for documents edited in your own tools. Collect block changes in Projects, review and merge them, and pull a shared history into another working copy.
Current source (13 October 2026): Schema 38 adds read-only project activity, contributor and profile-activity APIs and project-scoped device sessions: a device key signs a one-use challenge and receives a one-hour token for one project, renewable without a stored refresh secret. The public site, Projects, profile and admin interfaces are rebuilt (see the site design system), and the six editor add-ins carry a marketplace listing kit. Production runs schema 47 (release record); shared writers are off and no marketplace listing exists.
Current direction (10 October 2026): Local/remote document repositories around Word/Docs, Excel/Sheets and PowerPoint/Slides. The target is compact change transfer, shared content storage, offline history, reviewed merges and verifiable provenance. Research instruments remain one supported adapter, not the product roadmap. Product specification · Ordered implementation plan · Current handoff.
Current source (12 October 2026): Typed, chunked shared state now supports periodic checkpoints, draft/rebase/recovery bases and named/deployed/public snapshots. Shared writers are opt-in and preserve verified legacy reads. A durable local project repository provides signed multi-file commits, parents, branches, missing-object exchange, merge bases, comparison and commit-addressed revert/cherry-pick. Signed ref receipts and separate client trust journals add continuity checks, authority rotation and persistent local revocation. Private project transfers now provide authenticated object/commit staging, durable quotas and current access/erasure checks in schema 35; uploading does not publish a shared branch. Schema 36 adds shared publication, protected refs/review and atomic signed receipts. Selected-history CLI synchronization now provides reviewed push, verified fetch, fast-forward pull and separately pinned remote heads. Project-scoped sign-in and web/native adoption of this contract remain open. Read the acceptance ledger and verified handoff for exact source/production boundaries.
The deployed centralized workspace supports Projects, review, proposal bundles, historical recovery, revision-range revert/cherry-pick and supported native history downloads. Test add-in packages and sign-in cover all six editor clients. Projects UI adoption of shared portable refs/reviews, connector adoption of local commits, complete offline convergence, full native capture, external witnesses and large-file/service acceptance remain open. Shared writes still scan full state and reconstruction keeps state resident; packing and incremental publication remain storage priorities. Installed-editor acceptance and marketplace publication also remain open. Licensing: this repository is private and its application is not published as open source; see License.
The new signed-in front page is Projects: member-only profiles, multiple files, per-file main/private drafts, pull requests, comparisons and history. Basic web editors have their own tab. Test uploads are limited to 3 MB (3,000,000 bytes). Hosted project-wide branch/review integration remains planned; see the handoff for source verification and the separate production release state.
- Standalone engine — MIT · extraction and integration notes
- Detailed engineering and product handoff
- Current implementation and remaining work
- Google and email setup
- Vercel and VPS deployment
- Research file compatibility
- ODK Central and KoboToolbox connection
- All research connections and supported preview logic
- Versioning conformance and mathematical limits
- Admin, branding and Search Console
- Expanded pilot scope
Teams revise proposals, policies, reports, contracts and spreadsheets together. Whole-file copies lose the relationship between wording, formatting and decisions. Dynodoc gives structural blocks permanent identities and records changes to text, formatting and position. Teams can explore personal drafts, review overlapping changes, share selected work and restore earlier versions without erasing history. Research instruments remain a supported use case, not the product's organizing principle.
See the product pivot and office editor support and limits.
Dynodoc makes version control and the audit trail part of the data model. Every content change is a typed semantic event, attributable, hash-linked, and replayable. Supported independent edits can merge after validation; overlapping edits and shared constraints can require explicit resolution. A reviewer's suggestion is a proposal the author accepts or rejects with a recorded outcome. Metadata and permissions use a separate operational audit; metadata receipts commit to before/after values without retaining readable copies after erasure.
The system rests on an append-only, hash-chained event log as the system of record:
- Typed semantic events. Every change is an event such as
NodeCreated,FieldEdited,NodeMoved,CommentAdded,SuggestionProposed,SuggestionAccepted— operating on nodes, not text. - Stable-identity nodes. Each supported logical node gets a ULID at creation that never changes for the node's lifetime. Stable IDs provide exact correspondence; total merge cost also includes content comparison, ordered indexes, text diff and validation.
- Materialized state by fold. Current document state is derived by folding the event log; periodic snapshots pin intermediate states so reads are fast. Snapshots are derived, never authoritative.
- Tamper-evidence. Each event is chained:
chain_hash = SHA256(content_hash ‖ prev_chain_hash), genesis from 32 zero bytes. A Merkle root over snapshots commits to the whole tree. Anyone with document access can verify the chain's internal consistency. Detecting a wholesale rewrite by a database administrator also requires an independently retained trusted hash or backup; the current deployment does not publish external integrity checkpoints.
The versioning volumes explain the design and its intended mathematical properties. The pilot uses serialized server writes and explicit merge review; the CRDT convergence layer is deferred. See docs/02-versioning-design-vol1.md and docs/03-versioning-mathematics-vol2.md.
The original prototype provides four questionnaire views. The hosted workspace now has separate document, spreadsheet and questionnaire editors; these legacy views remain in the codebase:
| Mode | What it is |
|---|---|
| Document | Prose-shaped rendering — reads like a printed methodology appendix. Default mode. |
| Outline | Two-pane tree view for navigation and structural reorganization. |
| Spec | The underlying XLSForm as an editable spreadsheet table. |
| Preview | Legacy control-only view. The hosted questionnaire editor executes the documented XLSForm logic subset. |
On top of it sits the suggesting workflow: a reviewer proposes a change without applying it;
it lives as a proposal in the author's queue until accepted or rejected. When two edits touch the
same field, the system surfaces a four-card conflict (Original / current version /
incoming version / compose-new) rather than <<<<<<< markers. Every merge runs a referential
integrity pass — no dangling variable references, no cycles, no duplicate var-names — that
blocks a Deployed event when the instrument would break.
The architectural commitment: the engine never changes between regimes.
- Document version control (the immediate target) — teams editing and reviewing rich text and spreadsheets; research instruments are one use case. This is the current implementation focus.
- Public consultation at national scale (a later extension) — thousands of public contributors on a government policy draft. New layers (identity tiers, moderation, Polis-style deliberation clustering, citizen UX, closeout/legitimacy reports) are added above the engine, never replacing it. See the roadmap below and docs/05–09.
The PoC proves the engine for a 2–6 person expert team. See docs/dynodoc_poc_prd.md and docs/decisions/000-initial.md (authoritative).
In scope: the Rust engine (event log, snapshots, semantic ops, governance gate, integrity + merge), email magic-link auth, REST + SSE API, and the SvelteKit researcher frontend.
Out of scope (deferred): public consultation surface and citizen frontend, Python/ML services, the CRDT live-typing layer (Stage 20 — same-field edits use the four-card conflict instead), T3 civic identity, moderation, deliberation, LLM summary, and multi-tenant deployment hardening.
- Two browsers logged in as different authors open the same document; concurrent edits to different items merge cleanly via the log; live SSE delivers updates within 100 ms.
- A suggestion from author A appears in author B's proposals queue and applies on accept.
- Renaming a
varNamereferenced by another item's relevance expression triggers an integrity violation that blocks theDeployedevent with a clear message. - The auditor CLI returns OK for a clean log and pinpoints the exact event
seqif a row is corrupted. - All Rust property/integration tests and frontend unit tests passing (verified against a live Postgres). Core Playwright workflows are now exercised against a running local stack; Lighthouse and broader accessibility/load audits remain open. See SETUP.md.
| Layer | Choice |
|---|---|
| Engine | Rust — Axum · SQLx · Tokio · ring (SHA-256) · pasetors (Paseto v4) |
| Crates | engine-core · engine-api · engine-cli · engine-shared (Cargo workspace) |
| Database | PostgreSQL 16+ — append-only enforced at the DB layer via triggers |
| Frontend | SvelteKit + TypeScript, server-rendered (frontend/researcher) |
| Design system | Warm parchment background · Fraunces / Source Serif 4 / IBM Plex Sans · terracotta accent |
| Realtime | Server-Sent Events over HTTP/2 — no WebSockets |
| Local dev | Docker Compose (one Postgres) + Rust binary + SvelteKit dev server |
| Task runner | go-task (Taskfile.yml) |
crates/
engine-core/ Rust — event log, hash chain, materialization, snapshots, merge
engine-api/ Rust — Axum HTTP server, SSE, auth
engine-cli/ Rust — admin CLI (migrate, snapshot, verify, replay)
engine-shared/ Rust — types shared across crates
migrations/ SQL migrations (append-only once applied; 0000–0004, 0009_views, 0010_auth, 0011_idempotency in PoC)
frontend/researcher/ SvelteKit researcher UI (Phase-0 deliverable)
infra/ docker-compose.yml (Postgres only for the PoC)
docs/ Design + mathematics + sequential build reference (see docs/README.md)
The build is sequenced; each stage assumes the prior ones are done. Full prompts and checklists
live in docs/{NN}-build-*.md (see .cursor/stage-map.md for the
stage-number → file map).
| Stage | Deliverable | PoC | Status |
|---|---|---|---|
| 12 | Repository & dev environment | ✅ | done |
| 13 | Database schema & migrations | ✅ | done |
| 14 | Event log core (hash chain) | ✅ | done |
| 15 | Snapshot engine & materialization | ✅ | done |
| 16 | Semantic ops & governance gate | ✅ | done |
| 17 | Auth & identity (email link and Google) | ◐ | implemented; provider setup pending |
| 18 | Web API surface (REST + SSE) | ✅ | done |
| 19 | Research IDE frontend (four-mode editor) | ✅ | done |
| 20 | CRDT convergence layer | ⏭ | skipped (PoC) |
| 21 | Referential integrity & semantic merge | ✅ | done |
The original PoC stages have implementations, with verification limits recorded in SETUP.md. The expanded researcher product is still in development; see the current assessment. Public consultation, ML and civic identity remain future work.
The rich-text engine now records compact formatting-aware changes and merges independent edits within text paragraphs. See the research and implementation record for the run model, prior art, benchmarks, current import limits, and the remaining storage/CRDT work.
Full prerequisites and verified setup notes are in SETUP.md. Quick start:
task setup # creates missing runtime/operator env files, installs frontend deps
task up # local PostgreSQL
# Configure separate logins using docs/DATABASE-PRIVILEGES.md.
task migrate # operator process reads .env.migrate
task db:grant-runtime # grant the already-created dynodoc_runtime login
task db:check # verify runtime login and schema
task dev # API (:8080) + frontend (:5173); never migrates
task lint # clippy + eslint + svelte-check
task fmt # format everythingHealth checks once task dev is up:
curl http://127.0.0.1:8080/healthz # engine-api
curl http://127.0.0.1:5173/healthz # researcher frontendRun task test in a separate shell with DATABASE_URL pointing to an isolated
test database owner with CREATE DATABASE and CREATE ROLE. Never use hosted data or
start the API from that test shell. See the database setup contract.
Windows note:
ring's build script is blocked by Windows Smart App Control in Enforce mode — build on a SAC-free machine or in WSL2. See SETUP.md.
Finish the security boundaries and rollout checks, then bounded shared content, portable project commits and branches, durable offline exchange and convergence. Native format fidelity, independently verifiable audit commitments and measured large-file/service limits follow the engine evolution plan. Word/Docs, Excel/Sheets and PowerPoint/Slides connectors also need installed-host acceptance and distribution. The older civic/public-consultation documents are historical adapter proposals, not the current product roadmap.
This repo ships parallel assistant assets so any agent or editor can work within the project's rules (current product scope, immutable migrations, append-only events):
| Path | For |
|---|---|
.claude/ |
Claude Code — subagents, skills, and safety hooks (settings.json) |
.cursor/ |
Cursor — rules, skills, agents, hooks, and the canonical stage map |
.codex/ |
Codex — mirrored prompts and hook scripts |
AGENTS.md |
Single-page guide read by every agent before implementing |
Start with docs/README.md for the full numbered series. Most-used entry points:
- Why the engine works — docs/02, docs/03 (or combined: docs/04)
- UX theory — docs/01-uiux-theory.md
- Stack & layout — docs/11-build-index-and-stack.md
- PoC requirements — docs/dynodoc_poc_prd.md
- Committed decisions — docs/decisions/000-initial.md
This repository is private and proprietary: Copyright (c) 2026 Verne Ltd., all rights
reserved (see LICENSE). The web workspace, website and editor connectors
are not published as open source. Only the
engine, API and command-line tools are
open source, under the MIT licence, in their own repository. The operator is Verne Ltd.,
Dhaka, Bangladesh; see the legal pages notes and
the licensing decision.