Why this matters
When a developer makes a mistake in code, they revert the commit. When an analyst makes a mistake in a production database, the original data is gone. Most data systems treat every write as a destructive overwrite: no undo, no diff, no history. Versioned knowledge applies the discipline that reshaped software engineering to data.
What it is
Versioned knowledge records every change to a dataset as an immutable commit: a snapshot whose hash fixes its content. Commits form a chain, and on that chain you can:
- Branch. Take an isolated copy of the data to work on, without touching anyone else's view.
- Merge. Bring one branch's changes into another, with conflicts detected when both changed the same thing.
- Read the past. Query the data as it was at any earlier moment, not only as it is now.
- Diff. Compare any two versions to see what changed, when, and, with signed commits, by whom.
How it works
The key is immutability. Instead of changing data in place, the system writes a new version beside the old. Each commit records:
- What changed: the additions, modifications and deletions.
- Its parent: a hash pointing at the previous state.
- Its metadata: time, author, message, signature.
Because each commit names its parent by hash, the whole history is a linked chain. Altering an early commit changes every hash after it, so the audit trail is not only logged but checkable by anyone who holds it.
A branch is a new pointer at an existing commit. From there it collects its own commits. A merge reconciles two branches that diverged into one new commit that carries both. This is how Legra keeps history: a branch costs nothing to create, and storage grows only with what changed.
Is this event sourcing?
Event sourcing records what happened. Versioned knowledge records what the state was at every point, and lets you query it directly. You do not replay events to rebuild a past state; you go to it. For regulatory reporting, audit response and historical analysis, that difference decides how fast you answer.
What it gives you
Safe experiments. Analysts, data scientists and pipelines branch the data, run their transformations and judge the result with production at no risk. A failed experiment is a discarded branch. A good one is merged.
A complete trail. Every change carries who, when and why. It is not a separate log that can be edited; it is the data structure itself. "What did the data say on the fifteenth of March?" is one query.
Work in parallel. The engineering team restructures the schema on one branch while analytics keeps querying the stable one. Changes meet through explicit merges with conflict detection.
Reproducible AI. A model's decision needs the exact data it was trained on or retrieved from. Versioned data gives every run a commit: a permanent, checkable reference.
Evidence on request. Lineage, the state at a given date, and a hash chain that exposes any later change are structural properties, not reports assembled afterwards.
Rollback. When a bad import lands, point the branch back at the last good commit. No restore from backup, no replaying transactions.
What it costs
Growth. Immutable history accumulates. Shared unchanged data keeps it small; a retention policy removes what it may.
Merges. Two branches that changed the same thing need a resolution: automatic where a rule fits, human where it does not. The tooling around a merge matters as much as the algorithm.
Speed on history. Reading a past state must be as fast as reading the present, or nobody uses it. That takes indexes that span versions, and not every system has them.
Habits. Teams used to mutable databases learn to branch before changing, commit with a message and review a diff before merging. The tooling has to make that feel natural.
What to ask
Is history immutable? Some systems offer soft versioning, where old versions can be overwritten or purged. If the trail can be edited, the guarantee is decoration.
Can you query any past state directly? Time travel that replays a log is slow and brittle. Direct access to snapshots is operational.
How does branching work? Is a branch a pointer, or a copy of the whole dataset? Copying does not scale.
What happens on conflict? Look for clear detection and resolution. A system that silently keeps the last writer hides data loss behind convenience.
Are commits signed? Signatures prove authorship and stop attribution from being rewritten later. That matters in a dispute.
Is the schema versioned too? If the ontology is versioned with the data, you can reconstruct not only what the data was, but what it meant.
Try it in Legra
Use the branching guide to create a proposal and compare its query results with main before merging.