How it works
jMemoria does not store the current state and let people overwrite it. It stores the history of accepted changes, and computes the current state from that history — so nothing is lost, and everything is traceable.
The write path
There is no CRUD. Every factual change travels the same path:
- Change Set A proposed change, stated against the exact version it builds on.
- Acceptance The change is validated and accepted — or refused (for example, a stale version is rejected, not merged silently).
- Knowledge Commit An accepted change becomes an immutable commit in an append-only log.
- Projection & Timeline The current state is a deterministic projection of the commit log — rebuildable at any time — and the timeline shows how it got there.
The knowledge model
Six concepts carry everything jMemoria remembers.
Workspace
The top-level container; ownership and membership are themselves recorded as commits.
List
A grouping of items within a workspace.
Item
The unit of knowledge — attributes, tags, artifact references, and a version.
Relation
A typed link between items.
Artifact
An external reference by locator plus checksum.
Actor
Who acts: human, ai-agent, automation and others — recorded on every commit.
Versions and domain packages
Versions and concurrency
Every change names the version it is based on. If two writers change the same item from the same starting point, the second is refused (acceptance.staleVersion) rather than silently overwriting the first — disagreements stay visible instead of being merged away.
Domain packages
Item types, status models and validation rules come from a domain package. The built-in basic package ships a small set of item types and a whitelisted status machine; a software-development package builds on it. The model is the same whatever the domain.