A key part of the design is writing the Federation Object Model (FOM), which defines the objects and updates that are published by the RTI. While it might at first glance seem a good idea to use the FOM to share the internal property tree across multiple federates, this is probably the wrong way to use HLA as the granularity is too low <ref>https://sourceforge.net/p/flightgear/mailman/message/34795859/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/34803436/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/34794675/</ref> and it's likely to lead to synchonization issues. Instead, we'll need to make explicit decisions about the data models to communicate.
One possibility suggested by Stuart on the devel list, would be providing certain subsystems with their own ''private'' property tree <ref>https://sourceforge.net/p/flightgear/ mailman/ message/ 34632142/ </ ref>.
For instance, certain subsystems are already well-behaved/encapsulated in that they're having their own dedicated branches in the property tree (e.g. think <code>/ai</code>, <code>/models</code>, <code>/canvas</code>), i.e. could be moved to a separate thread accordingly, which would be in line with similar ideas discussed in the past (see [[Property threading]]).
The FOM is a set of XML files in [https://sourceforge. net/p/flightgear/fgdata/ci/next/ tree /HLA / fgdata/HLA/]
==Current Status ==