Compliance Rules API

The rules scripts are checked against. Base path /api/db-devops/compliance-rules, needs an active license, signed-in callers. Reading is open to any role; creating, changing, deleting and trying a rule need a Release Manager or admin (403 otherwise). Errors answer { "error", "code" }.

Rule shape

{ "id": "uuid",
  "name": "No DROP TABLE",
  "description": "Tables are renamed, never dropped",
  "severity": "info" | "warning" | "error",
  "isActive": true,
  "kind": "regex" | "llm" | "hybrid",
  "pattern": "\\\\bDROP\\\\s+TABLE\\\\b",
  "patternNegate": false,
  "patternFlags": "i",
  "category": "destructive",
  "appliesToDialects": ["postgresql"] | null,
  "appliesToEnvironments": ["Production"] | null,
  "remediation": "Rename the table instead of dropping it",
  "createdBy": "email",
  "createdAt": "ISO", "updatedAt": "ISO" }

• kind: regex is decided by the pattern alone; llm by the AI model; hybrid by the pattern, with the model confirming a failure. Omitted, it is llm.
• pattern: a JavaScript regular expression, required for regex and hybrid and stored as null for llm. It must compile with its flags. Inline flags such as (?i) do not compile; use patternFlags.
• patternFlags: any of i, m, s, u, each at most once, stored in that order. Omitted, it is i; "" means none.
• patternNegate: false fails the rule when the pattern is found; true fails it when the pattern is missing.
• severity: omitted, it is warning. Only failing error rules fail a check or block approval.
• appliesToDialects: engines with a connection adapter (see GET /engines), stored in lower case; sqlserver is accepted and stored as mssql, the one name for SQL Server. appliesToEnvironments: existing environment names, matched without regard to case and stored as the environment is spelled. Empty or null means every engine or environment.
• Limits: name 128 characters, category 64, description, remediation and pattern 2000 each. name and description are required; names are unique regardless of case. isActive and patternNegate must be true or false.

Endpoints

Creating, changing and deleting a rule is written to the audit log (CREATE_COMPLIANCE_RULE, UPDATE_COMPLIANCE_RULE, DELETE_COMPLIANCE_RULE). Each entry of checks is { ruleId, ruleName, pass, severity, category, evaluator, evidence?, reason, remediation }; each entry of skipped is { ruleId, ruleName, reason }.

The approval gate

While an active regex rule of severity error fails, these answer 409 with code COMPLIANCE_FAILED and a message naming the failing rules (and, for a release, the scripts):

• POST /api/db-devops/approvals for a script or a release; the environment of the request, or else each script's own, decides which rules apply;
• POST /api/db-devops/approvals/:id/sign, checked again when signing;
• POST /api/db-devops/scripts/:id/approve.

Errors