Foundation and Memory
These notes describe the fast data plane and authoritative memory structures beneath ADK. They cover how Brain and Pinky exchange bounded runtime facts, how logical identities remain stable, and how frequently used state stays efficient.
They also separate live decision state from slower persistence and control work. Storage may preserve and restore information, but it does not become the authority for moment-to-moment gameplay.
Component Storage Service
Warehouse stores local component data that Brain logic reads and changes. It tracks where components are kept in memory. Warehouse does not manage databases or plugins. It only handles local storage of components. It depends on contracts for memory rules and persistence boundaries. Pinky is not part of Warehouse. Warehouse does not interact with Pinky. This service does not make decisions about mutation order. It applies writes only when an approved authority selects the operation.
Example: Warehouse can hold a live component for Brain, but a separate service must decide whether a proposed change is allowed.
Memory Discipline for Fast Paths
Hot-path services must use bounded memory structures. They cannot use unbounded or dynamically sized data. The system avoids delays by preallocating memory. Work that stalls the host tick is not allowed. These rules only apply to hot-path services. This keeps performance strong and prevents slowdowns.
Spatial Hashing Service
Spatial Hashing is a local service that speeds up spatial queries. It groups objects into buckets by location. This helps answer questions like 'what is near this point?' without deciding where objects actually are. Other systems control real-world rules. The Brain owns the source data. The Warehouse provides authoritative state. The service does not make decisions about object placement or behavior. It only supports fast lookups. It cannot change the actual world. It never makes final game logic calls. Only approved Brain owners can update the index.
Data Storage Location Rules
The system decides where data lives while running. Some data stays in fast memory. Other data moves to slower storage. The system avoids locking into one long-term storage method. Plugins and downstream systems cannot choose storage placement directly. They must use approved framework contracts only. Brain-owned rules preserve hot-path stability. Architecture-owned rules handle validity and cold behavior. This keeps runtime performance stable and safe. The system does not pick the final database type. It only sets where data lives during runtime.