Index: /reasoner/reasoner.tex
===================================================================
--- /reasoner/reasoner.tex	(revision 127)
+++ /reasoner/reasoner.tex	(revision 128)
@@ -181,22 +181,20 @@
 \end{multline*}
 %
-Akin to variable declarations, $annotations(v)$ returns the set of actual annotation variables for variable $v$. Please note that there is a significant difference between $annotations(d)$ for a variable declaration $d$ and $\allowbreak{}annotations(decision(cfg,d))$, as a declaration only holds the specifically declared attributes for $d$, while a variable is instantiated with all annotations potentially inherited from containing project or variables (in case of compounds or containers). 
-
-Variables can be \emph{local}, e.g., as specified in the IVML model used as parameters of a user-defined constraint function, within let-expression or as collection iterator. Such variables have the same properties as usual configuration variables and can be identified using $isLocal(v)$, which then returns $true$.
-
-Due to the specific semantics of default or frozen variables, IVML variables have an internal \emph{assignment state} to be accessed via $state(v)$. The state of individual variables is actually changed (indirectly) by the expression evaluator as side effect of constraint evaluation. The following states are defined:
+Akin to variable declarations, $annotations(v)$ returns the set of actual annotation variables for variable $v$. Please note that there is a significant difference between $annotations(d)$ for a variable declaration $d$ and\linebreak[4]$annotations(decision(cfg,d))$, as a declaration only holds the specifically declared attributes for $d$, while a variable is instantiated with all annotations potentially inherited from containing project or variables (in case of compounds or containers). 
+
+Due to the specific semantics of default or frozen variables, IVML variables have an \emph{assignment state} that be accessed via $state(v)$. The state of individual variables is changes (indirectly) when values are assigned, e.g., as as a side effect of constraint evaluation. The following states are defined:
 
 \begin{itemize}
-      \item \IVML{UNDEFINED}: No value has been assigned so far or the value was cleared intentionally through \IVML{null}.
-      \item \IVML{DEFAULT}: A type compatible default value has been assigned by evaluating the default value expression of the underlying variable declaration. Default values can be changed unless frozen. 
-      \item \IVML{ASSIGNED}: A type compatible value has been assigned (by some EASy component), but the value is still changeable.
-      \item \IVML{USER\_ASSIGNED}: A type compatible value has been assigned by the user and shall not be overridden by the implementation, e.g., the reasoner.
-      \item \IVML{DERIVED}: A type compatible value has been assigned as a consequence of reasoning and evaluating constraints.
-      \item \IVML{FROZEN}: The variable was frozen through the IVML \IVML{freeze} statement to avoid further changes of the actual value (including no value in state \IVML{UNDEFINED}). Further assignments are not allowed and cause an assignment error.
+      \item \IVML{UNDEFINED}: No value has been assigned so far or the value was cleared intentionally through assigning the IVML constant value \IVML{null}.
+      \item \IVML{DEFAULT}: A type compatible default value has been assigned by evaluating the default value expression of the underlying variable declaration. Default values can be changed unless frozen, but not more than once within the same project scope. 
+      \item \IVML{ASSIGNED}: A type compatible value has been assigned (by some EASy-Producer component). The value can still be changed, but not more than once within the same project scope.
+      \item \IVML{USER\_ASSIGNED}: A type compatible value has been assigned by the user and shall not be overridden, e.g., by the reasoner.
+      \item \IVML{DERIVED}: A type compatible value has been assigned as a side effect of reasoning and constraint evaluation.
+      \item \IVML{FROZEN}: The variable was frozen through the IVML \IVML{freeze} statement to avoid further changes of the actual value (including no value in state \IVML{UNDEFINED}). Further assignments are not allowed and cause an assignment error irrespective of the actual scope.
 \end{itemize}
 
-Please note, as already mentioned in Section \ref{sectApproach} that the value of a variable can be changed at maximum once within a project scope.
-
-For simplifying the descriptions of algorithms, we ignore here the fact that IVML variables can have the IVML value \IVML{null}, i.e., explicitly undefined (and different from a null pointer). While the underlying implementation must contain explicit checks, we just assume here that the functions lead to $\undef$, \setEmpty or \seq{\text{}}, respectively.
+Variables can be \emph{local}, e.g., as they are used in the IVML model as parameters of a user-defined constraint function, as variable in a let let-expression or as an iterator of a collection function. Such variables have the same properties as usual configuration variables, but they just hold a temporary value, may be re-assigned within a certain scope, e.g., iterator variables, typically have the state \IVML{ASSIGNED} and cannot be frozen. Local variables can be identified using $isLocal(v)$, which returns $true$ if $v$ is a local variable.
+
+%For simplifying the descriptions of algorithms, we ignore here the fact that IVML variables can have the IVML value \IVML{null}, i.e., explicitly undefined (and different from a null pointer). While the underlying implementation must contain explicit checks, we just assume here that the functions lead to $\undef$, \setEmpty or \seq{\text{}}, respectively.
 
 \subsubsection{Project}