The Atlas software architecture belongs to the blackboard family: data objects produced by knowledge sources (e.g. reconstruction modules) are posted to a common in-memory data base from where other modules can access them and produce new data objects. This model greatly reduces the coupling between knowledge modules containing the algorithmic code for analysis and reconstruction: a knowledge module does not need anymore to know which specific module can produce the information it needs nor which protocol it must use to obtain it (the "interface explosion" problem described in component software systems). Algorithmic code is known to be the least stable component of software systems and the blackboard approach has been very effective at reducing the impact of this instability, from the Zebra system of the Fortran days to the InfoBus architecture for Java components. The trade-off of the data/knowledge objects separation is the need for knowledge objects to identify data objects to be posted on or retrieved from the blackboard. It is crucial to develop a data model optimized for the required access patterns and yet flexible enough to accommodate the unexpected ones. The StoreGate has been designed, based on the Atlas requirements and the experience of other HENP systems such as Babar, CDF, CLEO, D0 and LHCB, to identify in a simple and efficient fashion (collections of) Data Objects based on their type and/or the modules which posted them to the Transient Data Store (the blackboard). The developer also has the freedom to use her preferred key class to uniquely identify a Data Object according to any other criterion. She can also define Selectors to iterate only over a subset of a collection of Data Objects retrieved from the Store. Besides this core functionality, the StoreGate provides the developers with a powerful interface to handle in a coherent fashion the preferred access control policy for the Data Objects in the Store. It also provides an Handle/Proxi mechanism to define and hide the cache fault mechanism: upon request, a missing Data Object can be transparently created and added to the Transient Store presumably retrieving it from a persistent data-base, or even reconstructing it on demand. The same mechanism provides an handle that is automatically kept updated with the most recent instance of a data object, hiding from those clients who may not care about it the time dynamics of the Store.