Skip to content
Merulan

Respond to breaches

Trace a breach to its evidence, repair the cause, and read the Constraint's Alert to confirm observed recovery.

Use this guide when a breach in Quality & Measurement needs a response. As an operator, you trace the failed claim, repair its cause, and check the next result. An Alert resolves only after the required recovery is observed.

Before you start

To respond to breaches, you need the Constraint Run handle and access to its Workspace and evidence. Read Constraints and alerts for the rule and Alert policy. Keep the exact Constraint and Metric revisions with the case. Read the rule used by that Run, even if the rule has changed.

Inspect the breach

In the Console's Constraint Runs area, open the Run behind the breach. Read its trace, evidence, recent history, and the Constraint's current Alert. The Run detail contract also supports this read through the API or MCP. Check whether the Run opened or last changed the Alert. Do not assume that the Run caused the Alert shown beside it.

A breaching Run may precede an Alert. The Alert policy can require several breaches within a time range. An absent Alert does not change the Run's answer. An open Alert can remain beside a conforming Run while its required recovery streak is not yet met.

Repair the cause

Breaches carry a trace that names the evidence and rule that failed. Repair the work the Constraint checks. Restore the evidence read when the trace names missing or denied data. For Pipeline output, use Promote and troubleshoot to read the Run that wrote it before repeating a write. Access checks still apply when a Metric reads evidence.

If the rule itself is wrong, review a fresh plan before applying a change. Keep the earlier Run as evidence of the claim it checked. Changing a rule or sending a message does not repair the work it checked.

Check the repair

Request a Constraint Run for the repaired work through Run quality checks. Use an allowed cause and a new key for that check. Read the returned Run until its trace explains the result. Earlier breaches remain in history. A replay of the prior intent returns the prior attempt. That replay cannot prove the repair worked.

Checkpoints

Breaches must trace to the intended Constraint revision and measured evidence. The repair must address the cause named by that trace. The next Run must describe the corrected work. Read its result and the Constraint's Alert separately. Failed, canceled, and unevaluable Runs do not count as recovery. A Run without a quality answer breaks the consecutive conforming streak.

Success

Breaches have observed recovery when the repaired work conforms and any open Alert reads resolved under its recovery policy. Read the Alert's latest Run and recovery time with the recent history. A sent message proves delivery, not recovery. One conforming Run is enough only when the Alert policy requires no longer streak.

When it fails

Readback for breaches can fail before evidence is readable or a check is admitted. Read the returned code and repair its cause before you request different work.

QUALITY_CONSTRAINT_RUN_READ_FAILED

The Run detail could not be read. Resolve the service fault, then read the same handle again. A failed read supplies no quality answer.

QUALITY_CONSTRAINT_RUN_CAUSE_NOT_CONFIGURED

The Constraint does not allow the requested cause. Choose an allowed cause or have the author review a configuration change before requesting the check.

Recovery

An Alert that remains open needs its Run history checked for further breaches or a broken recovery streak. Repair unevaluable evidence before you expect a conforming answer. Repeat checks for repaired work as needed to observe the required streak. A failed notification does not erase a breach. Repair the delivery path apart from the measured work. A sent message alone cannot resolve the Alert.

Next steps