Atomicity has a number of technical definitions mostly relating to making the actions on groups of data items behave as single events.  That is part of the meaning here, but it is actually a pretty recent addition to the code base that adds support for grouping events at the data level.  More generally it means that all data units are equivalent, that they each have certain properties and that they behave consistently individually and in groups by the interaction of those properties.  Although we emphasize flexibility, the architect is unlikely to need to change the basics of these properties and how they interact.  The axis of flexibiilty needs to already be there, adding a new axis is possible but not often the right solution.

The current card model has three things, and a couple more optional things.  We'll start our exploration with these and branch out.  First is the name, a card has to have a name to secure an identity and persistence in a collection, and we will look at the structure of names in the next chapter.  Cards connect to other cards, and every card connects to a type, which is also a card.  Any card with a multipart name connects to two more cards based on the name structure, a left and right, or trunk and tag.  The last of the three things is content, which can contain references to other cards, and we will cover content and references right after names.

As you might expect, references to data are references to data atoms, cards.  Other logic might dig into the internal representation of a card's content and parse it or split it according to the abstractions internal to the type, but for the platform, it is a single unit of data.  It can have multiple references to other cards in the content, but model specific logic will be needed to parse those out.