Skip to main content
The review policy defines what PawSQL checks. The quality gate defines how those findings affect delivery. Feedback then returns the decision, summary, and secure report link to the developer’s current workflow.

​
Goal

Convert PawSQL review evidence into pass, warning, or block decisions and publish the result to the source platform.

​
Prerequisites

Prepare a review policy that defines what PawSQL checks, including blocking criteria and failure behavior.

​
Configuration workflow

1

Set the scope

Identify repositories, branches, paths, database types, and delivery stages.
2

Choose a validated policy

Use a published ruleset and retain the policy version with every run.
3

Define blocking criteria

Use severity, selected rules, parse errors, or approved count thresholds.
4

Define failure behavior

Choose fail-closed, fail-open, or manual approval for timeout, authentication failure, and service unavailability.
5

Control exceptions

Require a justification, approver, scope, and expiration.
6

Publish feedback

Select commit status, review comments, pipeline results, and report links.

​
Feedback fields

​
Status mapping

A new head revision must make the previous decision stale. Only the job for the current revision may satisfy a merge requirement. Repeated runs should update an existing check or bot-owned comment rather than create duplicate feedback.

​
Expected Result

Each PawSQL outcome maps to a repository or pipeline status, and feedback publishes the decision, finding counts, policy version, and report link.
Fail-open requires an alert and an audit record. Every manual exception should identify its approver, justification, scope, and expiration.