You do not author reliability rules any more. The platform derives them from your graph, works on what it finds, and shows you the result. The only thing left to configure is where you want to be told.

​
What the platform watches

Rules are derived from the pipeline itself and kept in step with it:
  • every table-producing node gets a run rule — one terminal failure is enough;
  • every node with assertions gets an assertion rule (error fails, warn degrades);
  • every node on a cron schedule gets a freshness rule, with a deadline of twice its cadence — one cadence of slack, so ordinary jitter is not an alert;
  • every semantic relationship gets a semantic verification rule.
Nothing to turn on. A project that has never opened this page is watched the same as one that has.

​
Outcomes

When a rule fires, the platform records a finding, groups it into a unit of work, and tries to fix it. What you see is the outcome — one row per attempt at one problem, in the workspace Outcomes inbox: The split that matters is between the first two. needs_you is the only status that is asking for something, which is why the inbox puts it first rather than sorting everything by time. Each row says what broke, what the agent did about it, and where that left things. Opening one shows the evidence, the fix operations and the runs behind them, and the one action that clears it. Dismissing an outcome names a reason — expected, not_a_problem, handled_manually or wont_fix. A dismissal without one would be an unexplained disappearance from somebody else’s inbox, so the reason is required.

​
Notifications

By default nothing is sent outside the app. To be told elsewhere, author notification settings at project.dsl/reliability:
A destination carries a secret reference, never the endpoint itself — the URL stays in the secret store and never enters the document, the event log or the delivery payload. Three signals can be routed: outcome_fixed is deliberately narrow: it is the all-clear for something you were already told about. A fix the agent completed without ever asking you is not news, and sending it would teach people to ignore the channel. A route with no signals selects outcome_needs_you and nothing else. cooldown_seconds suppresses repeats to the same destination for one outcome. Branch lifecycle routes (branch_routes) are unchanged and are configured the same way.

​
Versioning

The document is versioned. Read it, edit it, and write it back with the version you read as expected_version; a write against a stale version is rejected. A document that still carries rules is refused, with an error pointing here.