Index: doc/proposals/enum.tex
===================================================================
--- doc/proposals/enum.tex	(revision 21ce2c70fd9046a9729e56a718e82628931c9b2c)
+++ doc/proposals/enum.tex	(revision dc80280a30ad172511ba6bf3a2cd16da277abe17)
@@ -205,7 +205,7 @@
 \end{lstlisting}
 
-\section{Enumeration Characteristic}
-
-\subsection{Enumerator Storage}
+\section{Enumeration Storage}
+
+\subsection{Enumeration Variable}
 
 Although \CFA enumeration captures three different attributes, an enumeration instance does not store all this information.
@@ -231,4 +231,21 @@
 These generated functions are $Companion Functions$, they take an $companion$ object and the position as parameters.
 
+\subsection{Enumeration Data}
+It is a work in progress, outlined the idea but will update with more information later...
+A \CFA enumeration is backed by data structures to store necessary data. Specifically, an enumeration has arrays to store its labels and values.
+\begin{lstlisting}[label=lst:enumeration_back_data]
+enum(T) E;
+// backing data
+T* E_values;
+char** E_labels;
+\end{lstlisting}
+Depending on the use cases, the value and label array might not be necessary to the program.
+
+\subsection{Weak Reference}
+If the value and label need to be determined at the runtime, the data arrays are necessary. However, allocating the attribute arrays in every compilation unit can take up a lot of memory and it is not ideal. \CFA Optimized it by using GCC weak reference ( @__attribute(weak)__@ ).
+
+\subsection{Aggressive Inline}
+If the label and value can be determined during the compilation, \CFA can inline the attributes and no allocation is needed.
+
 \section{Unification}