A file shows what it says now. It does not record who changed it, who agreed, or what it said last week. Dynodoc keeps that record next to the file.
Most documents keep only their latest state, and teams make copies to keep the rest.
Six copies of one document. None of them records which edit came from whom, or why.
Each save replaces the last. A budget or a contract keeps its conclusion without the reasoning, the discarded alternative or the person who objected.
Track changes names are metadata stored in the file, and whoever holds the file can edit them. A name in a margin is not evidence of who made a change.
Who agreed is in an email thread, a chat message or someone’s memory. The file does not know it was approved, so it cannot show it.
Each answer says how Dynodoc handles the question and whether that runs in the hosted workspace today.
Typed events name the node, the field and the before and after values, down to one paragraph, cell or shape.
The authenticated account that made the change, not a name typed into the file. Project commits are also signed with a device key.
Change requests record each approval, the rule that required it and the merge that applied it.
Every retained revision can be read. Recovery restores selected parts as a new reviewed change, so newer work survives.
A hash chain and verified snapshots expose edits to old events. Signed receipts and pinned heads extend the check to branches.
Export supported files and retained originals. In source, a full project repository lives on your own device.
Each comes from the versioning design volumes in the engine repository.
Every paragraph, cell and shape gets an ID once, and it never changes or comes back under another meaning. Rewording or moving something edits the thing; it does not delete one thing and create another. The design volume treats the identity rules as more important than the choice of architecture.
Design volume 1, section 4.2 (stable identity).
@@ paragraph · Q3 summary @@-text: Q3 budget draft+text: Q3 budget, approved id: 01K7R2M4XQ (unchanged)Current state is computed from recorded events. Snapshots are shortcuts that are checked against the log, never the authority. A correction is a new event, not an edit to an old one, so earlier events are not rewritten in place.
Design volume 1, section 5.2 (event log) and section 2.2 (content addressing).
a91f03c75be2d814c04a77f2each event hashes the one before it
Merging matches parts by ID, applies a rule for each kind of field and validates the outcome. The same inputs give the same result. Independent edits combine without conflict markers. Anything ambiguous stops for a person, who sees the whole paragraph, cell or slide, and the resolution is recorded.
Design volume 1, sections 1.1, 4.4 and 4.5 (typed merge and validation).
@@ conflict needs a person @@-Sam Okoye: 7,600+Priya Nair: 7,900 neither is chosen automaticallyA hash chain, signed commits and receipts can be checked by anyone with access, and each has a limit. Integrity does not show authorship, a signature does not carry a trusted time, and observed editor activity is not a keystroke log. The list beside this says which claim each piece of evidence supports.
Design volume 1, section 7.4, and the correctness contract in the product specification.
A hash chain proves a record has not been edited in place. It does not prove a person typed the words, or that a person rather than a tool did.
The editor add-ins compare snapshots while their pane is open. They capture observed changes, not who or what composed a sentence, and not edits made while the pane is closed.
Only an anchor kept somewhere else would reveal that. Independent witnesses are on the roadmap and are not built.
Reconstructing and reviewing versions needs the content stored with its history. Storing changes is not storing nothing. A client-encrypted mode is not built.
No. It is an append-only log in which each event includes a hash of the one before it, the same idea Git uses for commits. There is no token, mining or distributed consensus.
It complements it. Track changes lives inside one file. Dynodoc records changes across files and adds review rules, recovery and a verifiable history. It does not offer live co-authoring.
No. It records the authenticated account that submitted a change and, in the project repository, the device key that signed a commit. The add-ins observe changes while their pane is open. None of that proves who or what composed the words.
On the Dynodoc server. Reconstructing and reviewing versions requires the content to be stored there with its history. Access is rechecked on every read, and audited erasure removes content. A client-encrypted mode is not built.
No. You save a version, create a draft, review changes and merge them. The ideas come from version control; the vocabulary does not.
The features page describes each part with a mockup, a status label and its limits.