Hi Alex,

consistency model of an AtomSpace is (specifically, the ACI in ACID)

I cannot give you a clear, easy answer, because the AtomSpace doesn't fall into either the conventional relationalDB model, nor into the key-value model (BASE). The following might illuminate the situation:

• Atoms are immutable; you can add or delete them, you cannot modify them.
• There is one specific type, the StateLink which does provide a peculiar form of atomic update.
• Attached to each Atom is something called Values, (in retrospect a terrible name choice, should have been "properties".) Values can, in a certain sense, be modified (they're still atomic and thread-safe, though.) The prototypical Value is the TruthValue; in certain sense, this is "really" where the computations happen. In a different sense, the Values provide an alternative to Atoms, with different performance properties, different mutabiility constraints, and different searchability. One can think of Atoms as pipes, and the Values as the fluid in the pipes. (thus relatively immutable and fixed vs endlessly changing). There are other ways to think of it, too.
• The mutexes are all about thread safety and atomic access. Once a thread has a handle to an Atom or Value, it will not disappear from under that thread.
• Temporary results during query are held in temporary AtomSpaces, that are invisible to the user. They don't "leak". Search results can be placed in the AtomSpace, if you use BindLink, GetLink, or not, if you use MeetLink / QueryLink. So the latter two do not alter the AtomSpace at all.

Jepson Test

This seems to be about distributed datastores. The "raw" atomspace is not distributed, so this does not apply. However... There is an API called StorageNode It allows any given AtomSpace to connect to ... storage! Currently, this is RocksDB, Postgres, flat files, or other remote AtomSpaces on the network. What is saved/restored, or exchanged on the network, is up to the user. The network storage node is just a peer-to-peer API: what Atoms the peers trade with one-another is up to them. I don't know what the Jepsen test implies for this. If a remote peer crashes ... well, whatever Atoms you are holding are what they are. They're not damaged.

p.s. creating new StorageNodes to other systems is really pretty easy. It'll take more than a day or two, but should take less than a week or two. So if you have some favorite system .. have at it! It's not hard.

RocksDB

This uses the StorageNode mechanism, so the only things saved there are what you explicitly write out. It's designed that way, because saving everything automatically, all the time would be a huge performance bottleneck, esp. for rapidly changing data. (If you're clever you can write a thread to do this, if you feel you really need to. But if you really need to, you are probably mis-designing your system.)

If you kill -9 the atomspace while it's writing to RocksDB, well ... Rocks does have write-ahead logs and all kinds of fancy anti-corruption/self-repair stuff in it. You'd have to read about Rocks. I'm not sure what would happen if the AtomSpace tries to work with a partially-written Atom in rocks. It won't crash, but there are some strange corner cases where it might behave oddly in some subtle ways. Maybe. No one has explored this; there are no unit tests that intentionally try to write corrupt data, and then try to recover from that.

For me, the atomspace never crashes: I run multi-month-long processing jobs. What I do get are thunderstorms that knock out power, and the solution for that is UPS power supplies. (I mean, sure, you can write code that crashes, while it has the atomspace open. I think its unlikely to corrupt your data, but its kind of on you if you are working regularly in that scenario. The AtomSpace was not designed for banking applications.)