Building an automated document takes three important steps. First, you must define a series of questions and business rules that are relevant to the document at hand. Second, you must apply those rules to the text and content of the document, so that the system knows which clauses to include in response to which answers. And third, you must build a series of "interview" pages that will present end users with relevant questions in a clear and logical way.
The problem with many document assembly tools is that they force a human to complete all three steps. And it's the third step that creates all the trouble. You have to figure out which questions to ask, in what order, and with what dependencies. The more complex the document and its rules, the more time and effort it takes to manually build the interview pages (or "dialogs" as some people call them), and the more time and effort you waste testing, debugging and re-testing your solution. It's loads of fun.
To avoid this problem, Exari works differently. With complex documents, the machine is much better at figuring out which questions are relevant, and which questions can be skipped. So we make the machine do the third step for you. It simply looks inside the template to see which clauses are optional, or which variables are nested inside optional clauses, and automatically builds each interview page based on what it finds. Some people call this an "inferencing engine" (or some other fancy name like that). We just call it two-step automation.
You still have control over the layout and look of the interview, and you can still tweak the order in which each page appears. But you don't waste hours testing and debugging every new template, and you won't end up with a broken system every time you make a change.