At its heart, CER upholds certain key principles. Knowing a little about these principles may help you to understand CER's approach:
The work done to answer a question is only done when that question is asked.
The answer to a question is a value which cannot be accidentally changed by something outside CER. If the answer to a question is recalculated, then a fresh answer value will be created.
A rule set does not execute once through; rather a rule set allows as many questions to be asked as is needed.
You specify the rules for answering a question, and leave CER to efficiently answer those questions at runtime.
Identical inputs processed by identical rules always produces the same output.
There no counters or running totals. An count or total is a question in its own right - you provide the rules for answering it, and CER worries about the order of execution when answering it.
You only have to provide names for business concepts and questions. You do not have to think up descriptive names for interim results (unless you want to).
CER provides strong support for managing the testing of your rules.
The CER runtime intentionally contains no business concepts. You define the business concepts you need, leaving the CER runtime to be a general-purpose environment.
The implementation of your rule requirements is as complex as those requirements - but no more so. CER rule sets "make sense" when viewed by the business analysts who gathered the original requirements.
CER does not reinvent the wheel - functionality provided by existing Java technology is easily reused in CER rule sets.
CER integrates with the Dependency Manager to manages calculation dependencies so that you don't have to. When an input data item changes, the Dependency Manager and CER know what to recalculate. You do not have to write any special processing which guesses at which calculated outputs might be affected.