How It Works
When you write to a key that already exists:- The current version is marked as superseded
- A new version is created with an incremented version number
- The new version becomes the current version
Viewing History
history() returns every version of one key, oldest first. Each version is a
full snapshot, not a delta, so you can read any past state directly:
since and until, which is how you reconstruct what an agent
knew at the moment it decided something.
To see all versions across an entity rather than one key, use list():
Comparing Versions
Because every version is kept, SenseLab can show exactly which fields changed rather than just that something did.diff() returns structural, field-level
changes addressed by RFC 6901
JSON Pointer paths:
path, an operation of add, remove, or replace,
and the old and new values. The surrounding result also reports diff_type
(added, modified, or deleted) and the two versions’ confidence.
This works on nested dicts, lists, and scalars, so a change buried deep in a
config object is reported at its exact path instead of as a wholesale
replacement of the value.
Version Retention
Every version is kept. Superseding a key never overwrites the previous value — it marks it as no longer current and stores the new one alongside it, so the full chain stays queryable throughhistory() for as long as the entry exists.
Running SenseLab yourself? How versions are laid out on disk depends on the
storage backend you pick — see the adapter
reference.
Conflict Handling
When two agents write to the same key concurrently, theconflict_policy determines behavior:
Why CoW?
- Auditability — Every change is recorded. You can always trace how knowledge evolved.
- Safety — No data is lost. Mistakes can be identified by comparing versions.
- Outcome tracking — Outcomes create new versions with updated confidence scores, preserving the score history.
