The Engine output is a single, complex entity named Assemblage. Deconstructing the Assemblage is the first step for Analysis/Post processing and a necessary one to access the AssemblyObjects in the Assemblage. The Deconstruct Assemblage Component takes care of this step.

Once an Assemblage is input, the outputs are:

• AO - AssemblyObjects (as tree) - a data tree of the AssemblyObjects in the Assemblage, branch index is the AO index in the Assemblage, including preexisting objects
• AOr - Data Tree of the Rules used in the Assemblage (string): branch index corresponds to the branch index of the AO placed by the rule. The number of rules (and therefore of branches) is $n_{AO} - n_{pAO}$ (the total count of AO - the number of preexisting AO in the Assemblage)
• rOi - Data Tree of receiver Objects indexes in the Assemblage - each branch contains the branch index of the receiver AO. If branch {5} of this output contains the value 3, it means that the AO in the AO Data Tree at branch {3} is the receiver of the AO in the AO Data Tree at branch {5}. Tree branch index follows the same principle as AOr. Branch number is, again, $n_{AO} - n_{pAO}$
• avO - available Objects - List of indexes for AssemblyObjects with available Handles
• unO - unreachable Objects - List of indexes for unreachable AssemblyObjects; unreachable objects have free handles but cannot receive other objects; this might be due to their geometric situation (i.e. occluding objects, closeness to environmental geometry) or to Heuristics restrictions (no rules exist in the Heuristics Set that apply to one or more Handles)

While the usage of AO in an Assemblage is kind of obvious (even just to assign the actual geometries), use cases for the other outputs might not be so. Here are some possible ones:

• debug and inspection: check the status of a specific AO in the assemblage verifying its receiver and the rule used to place it
• access available/unreachable AOs to perform tailored actions on them