• At the first step, each attendees sends costraints contuously, but extra meeting constraint is not sent yet. The attendees decide [MD1,7], [MD2,19], because those dates are the earliest. The decision reason will be provided by attendees.
• At the second step, the extra meeting constraint is added. As you can see, consistent sets do not include [MD1,7], [MD2,19] which is the previous decisions. It means current decisions are constraint violated. Constraint violation reason will be providec by Constraint Manager.
• At the third step, Carl tightens one of his date. Now, the 26th is not valid. The system is over-constrained. Attendees reject previous decisions.
• At the fourth step, Brigitt relaxes one of her date, the 18th. Attendees decide [MD1,18], [MD2,19].

• At the fifth step, Dirk decides he does not need the extra meeting with Carl. Now the extra meeting constraint is invalidated. At the second step, inconsistent reason for [MD1,7],[MD2,19] decisions was the extra meeting constraint. Now, it is invalid. Therefore [MD1,7],[MD2,19] decisions is now valid. Redux' will inform this contents to the attendees and they revise decisions. Although the constraint is changed, Constraint Manager did nothing. Revision is pretty simple.
• At the six step, Carl relaxes one of his date, the 8th. Based on the new chances, attendees decide [MD1,7],[MD2,8].
• At the seventh step, Axel just prefers the 19th as second meeting date. Because there is no constraint change, Constraint Manager does nothing. Simple revision. For the constraint based systems, this type of revision is not easy because the decision maker is the system itself.

For the previous constraint based systems, the system should be remodeled or try to solve the problem from scratch at each step. Even if we can run the system over again and again, the system will do needless jobs such as the 5th and the 7th steps. The system not only wastes computations but also ignores the history.