Skip to main content
Databases differ in what they can enforce. Some scope records natively; some cannot. Some preview a change exactly; some can only estimate. A tool that hides this is selling governance theatre. So every guarantee carries a level naming who provides it:

Seen at startup

The same ladder is on GET /api/v1/connections/{name} and in the operator view, in the same words, so the CLI and the console can never disagree.

Policy decides what is good enough

Each line is a minimum. If the connection cannot reach it, the gateway refuses to start:
You find out at setup, in a message, rather than during an incident. The repository ships a deliberately strict policy that still refuses to start today — that refusal is a test, run by hand, that the capability model is real.

Why claims are verified, not trusted

A connector announcing scoping: enforced proves nothing. Two things check it:
  1. At construction, each claim is checked against the interfaces the connector actually implements. A connector that claims scoping without the ability to apply it fails immediately.
  2. In certification, each guarantee is exercised against a real database — scope applied to every alias, masking that survives a join, limits that truncate honestly. See wardencert.
enforced is not a lesser native; they protect against different things. native survives someone connecting around Warden with the same credentials. enforced covers engines with no such mechanism at all, and can express rules an engine’s own features cannot. Choosing between them is exactly the decision the ladder is designed to put in front of you.