Accepting a Violation

To accept a violation on a configuration element, name its constraint in the element’s built-in _acceptConstraintViolation annotation, optionally with a reason:

{
    name: "Watchdog",
    _acceptConstraintViolation: {
        constraints: [
            "PriorityLimit",
        ],
        reason: "The watchdog has to preempt every other task.",
    },
    priority: 20,
},

An accepted warning or info is no longer reported. An accepted error is reported as a warning, its message starting with Accepted error:. The annotation applies to the element it is written on, not to the elements below it. A violation of a definition root constraint is accepted at the top level of the configuration file, beside $definition.

A short form lists the names alone: _acceptConstraintViolation: ["PriorityLimit", "RuntimeWithinPeriod"].
A merged element accepts the names of every file writing it, so two files listing different names do not conflict.
An annotation in a mixin body accepts the violation on every element the body applies to.
An evaluation error, a division by zero for example, is not accepted.
A name no constraint of the element’s type carries warns, and so does a name listed twice.
A name whose constraint holds on the element warns as well, once the constraint ran: a constraint skipped for errors of the configuration has nothing to compare against.

In an editor the quick fix Accept constraint violation adds the name to the element, and completion offers the annotation only on an element with a violation it does not accept yet.