Task relax

This task depends on domain knowledge too. If the task is successful and some constraint has been relaxed, information on this fact is inserted into the database. This information can be used by the test following this task. If there is no proper rule to relax some violated constraint, the task retains the information about this in the database:
(defrule relax1
(declare (salience -10))
(job relaxation)
(not (result success))
=>
(assert (result failure))
)
Since the fact of failure can occur in the database only if the task is not successful, the priority of the rule relax1 should be lower than the priority of other rules of the task. Relaxation of some constraint can cause the inactivation of a constraint. If this inactivated constraint is violated, its slots viol-param and cons-violation should be set properly (because now they have no sense)
(defrule non-active-constraint
(declare (salience 10))
?a <- (object (is-a constraint) (active no) (cons-violation yes))
=>
(send ?a put-cons-violation no)
(send ?a put-viol-param (create$ ))
)
Priority of the rule ensures that these two slots can be changed before the activity is transferred to the next task.

The form of rules dedicated to the relaxation of constraints can vary a lot. Basic pattern of these rules is:

(defrule relax-<constraint>-<order number>
(job relaxation)
?a <- (constraint-to-relax <constraint>)
...
=>
...
(retract ?a)
(assert (result success))
)
The rule expects information on which constraint is to be relaxed in the database. This information has been asserted to the database by the previous task.

The activities contained in the action part of these rules can vary. They can contain a simple inactivation of the relaxed constraint (which can depend on the current state of the solution), the activation and/or inactivation of other constraints, or the modification of parameter values. Several rules can be associated with the relaxation of one constraint (they can be ordered by their priority).