Stop bad changes before they reach production

Why it matters

A contract change that drops a column, loosens a rule or removes a privacy tag can break every report downstream. Reviewers miss these changes because the diff looks small, and most teams find out after the change is live. LakeLogic checks every change against your standards on its pull request, before it merges, and records the result.

What you can do

• Decide which standards a contract change must meet.
• Choose, per standard, whether a failure blocks the change or only warns.
• Turn blocking off for the whole organisation for a while, without editing each standard.
• See every check result, per change and per evaluation run.

How to do it in LakeLogic

Standards are LakeLogic's quality gates. A gate is one requirement a contract must meet.

1. Go to Govern → Standards → Contract Standards. This lists every gate and its severity.

2. Set each gate's severity:

   Severity	What a failure does
   Blocking	The check fails on the pull request. It stops the merge only if your repository requires that check to pass (see below).
   Warning	The failure is reported. Nothing is stopped.
   Advisory	Shown for information.

3. To set the organisation-wide ceiling, open the page's header menu and choose Gate Settings. You need permission to change organisation settings. Pick an Enforcement Mode:

   Mode	Effect
   Blocking	Each gate's own severity applies. This is the default.
   Warning	Nothing blocks. Failing gates warn.
   Audit Only	Results are recorded. Nothing warns or blocks.

   The mode is a ceiling. It never makes a gate stricter: a Warning gate still only warns under Blocking.

4. Open a pull request that changes a contract file in a connected GitHub repository. The LakeLogic GitHub App checks it against your active gates.

5. Review the result under Govern → Contracts → Change Checks.

Where the checks run

The same enforcement mode is applied to the pull request check and to the publish evaluation.

What you get

• Change Checks: each proposed change with its downstream impact, the gates that failed, advisory issues and breaking changes found in the diff.
• Findings: what is failing now, grouped by standard.
• Assessment History: every evaluation run, what was evaluated and what was decided.

What actually stops a merge

LakeLogic reports; your Git provider enforces.

• On GitHub, the LakeLogic GitHub App posts a check named LakeLogic — Contract Governance Review on the pull request. A Blocking failure makes that check fail.
• The merge is stopped only if your repository requires that check. In the repository's branch protection (or ruleset) for your main branch, turn on required status checks and add the LakeLogic check. Without that, a failing check is shown on the PR but the merge button still works.
• Who can bypass follows your Git provider's rules (for example, repository administrators when branch protection allows it). LakeLogic does not override them.
• After a merge, LakeLogic evaluates the gates again when the contract is published and records the result as evidence. That evaluation cannot undo a merge that has already happened.

Other Git providers: see Connect your tools for which ones post checks on pull requests.

Good to know

• If Change Checks is empty, no pull request touching a contract was scanned in the selected window. Open one, or push a new commit to an existing PR.
• Under Warning or Audit Only, a gate marked Blocking does not block. The gate's detail says so.
• To see how a change moves from draft to published, read Approve every contract change with evidence.
• Contracts are written in Contract Studio. See Write a data contract. Repositories are connected through Integrations.