Skip to content
Merulan

Constraints and alerts

Constraints test claims against evidence, while Alerts track breached intervals and the observed recovery that resolves them.

Constraints and alerts keep rules and breach history in Quality & Measurement. A Constraint states a claim to test. A Constraint Run records an attempt to answer it. An Alert tracks a breached interval when the Constraint's Alert policy is met.

Ownership

A Constraint belongs to a Workspace. It names a Metric, scope, assertion, owner, and allowed causes. The assertion can test a bound, range, value, freshness, or coverage. Each Constraint also owns its schedule and Alert policy. A Metric supplies evidence. The Constraint decides which claim that evidence must answer. Measurement explains how Metrics keep their meaning and units.

Constraint scheduling admits interval schedules only. Cron schedules are refused when the definition is planned. A Constraint can omit a schedule and use its other allowed causes.

Lifecycle

A Constraint changes through a reviewed plan and a saved revision. A plan shows the proposed revision without saving it. Apply commits the reviewed plan. Deactivation keeps earlier revisions readable. A Constraint Run pins its Constraint revision and the Metric revision resolved at admission. Earlier Runs keep their meaning when the rule changes.

An Alert opens after the configured breach pattern. Further breaches can recur within that open interval. The configured streak of conforming Runs resolves the Alert. Failed, canceled, or unevaluable Runs neither open a breach nor count as recovery.

Constraint Groups

A Constraint Group combines named Constraint revisions with all or any. The group owns composition only. It has no schedule, execution, enforcement, or Alert policy of its own. Assess a Constraint Group reads existing Runs at the pinned revisions. It does not start checks.

The group caller can state how old a Run may be. Without that requirement, the assessment reports the Runs it finds without an added age limit. A missing Run at the pinned revision cannot be replaced with a Run of a different claim.

Boundaries

A Constraint assesses evidence. Company Schema rules, Pipeline validation, Actions, and Functions keep their own checks when work executes. A Constraint does not replace those checks or grant access to data. A Constraint Run is assessment evidence, not an Audit Log.

An Alert also differs from its notification. Delivery records show whether a message was delivered, failed, or skipped. A failed notification does not erase a breach, and sending a message does not repair the Constraint's subject.

Failures

A Constraint Run can answer conforming, breaching, or unevaluable. Missing, stale, denied, partial, unsupported, or failed evidence cannot establish that a rule holds. Execution failure and cancellation are separate Run states. Check the reason before deciding whether to repair evidence, restore access, or fix the work being assessed.

A breach need not open an Alert immediately. The temporal policy may require more than one breaching Run. Absence of an Alert alone is not a passing result.

Recovery

A Constraint recovery begins with the retained Run and its exact revisions. Repair the evidence source or the work that breached, then request a check for the corrected work. Read the resulting evidence and Alert state. Respond to breaches follows that path without confusing a sent notification with observed recovery.

Configuration changes need a fresh plan against the current revision. A stale plan must be rebuilt before apply. Earlier evidence remains tied to the version it assessed.