How StateJar keeps the latest fact
When a fact changes, which value wins? One field holds one value, every change is a new version, and you can verify any of them.
People change their minds, move cities and correct themselves. A memory layer that only adds facts will end up holding both the old and the new value. A good one has to decide which one is current, and be able to show its work.
One field, one value
Every fact StateJar accepts is mapped onto a single canonical path, for example one field for the city you live in. A field holds one value at a time. "I live in Pune" followed by "I moved to Goa" does not give you two cities. It gives you one city, and the latest statement wins.
Before a value is stored it is checked for its type. A word that is not an amount is not stored as a budget, and a fragment is not stored as an e-mail address. A value that fails is declined, with a reason you can read.
Updates never overwrite
The old value is not erased. Each change writes a new version of the state that points back to the version before it. History is append-only, so you can see what was true yesterday as well as what is true now.
When two statements contradict each other, the contradiction is kept as a record instead of being silently resolved.
The handle
Each state is written out in one canonical form and hashed with SHA-256. The result, a string starting with `shm_`, is the state's handle. It is a content address: the same facts produce the same bytes and the same handle on any machine.
shm_<64 hex characters>Restoring a handle re-derives the hash from the stored facts and refuses to continue if it does not match. A tampered or corrupted state cannot pass as the real one.
What the model is shown
When your app asks a question, StateJar sends only the fields the question needs once the state is large enough for that to matter, and the whole state while it is small. Every disclosure is written to an audit log with the handle that was used, so you can replay it later and check it.
Where this stops
Extraction is probabilistic: a model reads the message, and our published accuracy figures on frozen test sets are lower than we would like. The deterministic parts are what happens after extraction: the checks, the versions, the handles and the audit trail. That is why we keep the checks strict and the limits written down in the known issues.
Start with the first post if you have not read it: why chat apps forget.