A - Atomic, if you set a full node, or nodes of nodes, if any value is in error then nothing will be set.
If you want sets to be independent of each other, you need to set each piece of the data individually.
C - Consistency, if you use any reserved symbols or similar, the operation will be rejected as it could lead to an invalid read and thus an invalid state.
I - Isolation, the conflict resolution algorithm guarantees idempotent transactions, across every peer, regardless of any partition,
including a peer acting by itself or one having been disconnected from the network.
D - Durability, if the acknowledgement receipt is received, then the state at which the final persistence hook was called on is guaranteed to have been written.
The live state at point of confirmation may or may not be different than when it was called.
If this causes any application-level concern, it can compare against the live data by immediately reading it, or accessing the logs if enabled.
If you have any specific further questions I am happy to answer. It has support for vector-clock/timestamp "state" transactions.
I don't think ACID terminology is vague at all, and it sounds like you're trying to fit a square peg into a round hole here, terminology-wise.
Atomicity (A) means that changes must be committed or not committed, "all or nothing". If you commit the change set (X, Y) then upon successful commit, both X and Y must be present; if either X or Y are missing, it's not atomic. Conversely, if the commit fails, no changes may have been made.
Consistency (C) means that data is always valid, according to whatever rules are imposed by the data model. For example, classical RDBMSes enforce referential integrity (aka foreign keys), "not null" constraints, unique primary keys, etc. Consistency is the guarantee that every update conforms to these rules; a transaction cannot be committed if it doesn't. Consistency has nothing to do with conflict resolution (although in a concurrency environment, you do need both).
Isolation (I) means that one transaction must create the illusion that it is isolated from all other transactions, as though all transactions were applied serially. Any concurrent commits during the transaction must not be visible to it. Most databases implement a less strict level of isolation by default that is often called "read committed"; the transaction can see any changes from parallel transactions that are committed during the transaction (which means that a query may return different results if run multiple times), but it will not see uncommitted changes from other transactions. Many databases do implement the "serialized" isolation level, and will fail if you try to do execute two conflicting transactions at the same time.
Durability (D) means that transactions must remain permanently stored after they are committed. This is pretty much the vaguest rule, since there are too many variables in real life: it doesn't say anything about redo/undo logs, RAID caches, etc.
It should be added that ACID makes the most sense in situations where you combine multiple updates in a single transaction. ACID is of course useful for single-key, or single-object, updates, but it really comes into play when you have longer-running aggregate updates that need to perform both reads and writes across a bunch of different sets of data.
The fastest summary is that it is an Open Source Firebase.
Flat up answer for ACID: honestly, not how you traditionally would think, as it favors AP of the CAP theorem.
However, ACID terminology is actually pretty vague (http://en.wikipedia.org/wiki/ACID). Here is my comments about ACID in the code:
If you have any specific further questions I am happy to answer. It has support for vector-clock/timestamp "state" transactions.