Production safety model

Zingle is built so that nothing reaches production without a human. This page describes what the product guarantees, and where safety is a shared responsibility with you.

What Zingle guarantees

• Pull-request only. Every change to your dbt project is committed to a dedicated branch and opened as a pull request. Zingle does not merge pull requests, and does not push directly to your default/main branch.
• No auto-deploy. Zingle does not deploy merged changes. Promotion to production stays in your existing CI/CD and orchestration.
• Review-first. Optimize and Refactor are review-first: candidates and tasks are surfaced for your approval, and nothing lands in your repository until you accept it - as a pull request.

Shared responsibility: warehouse access

Zingle runs SQL against your warehouse using credentials and a role that you provision. The safety of your warehouse therefore depends on how you scope that role.

What Zingle does in the warehouse

• Reads - introspects schemas via the information schema and runs queries to preview data, answer questions, and compute statistics.
• Validation writes - when validating large refactors, Zingle may create and drop disposable objects (short-lived validation databases and temporary tables) to compare results before and after a change safely. These expire after 24 hours and are swept automatically.
• Model materialization (dbt run) is not part of the active toolset.

Warehouse writes are governed by the role you grant

Zingle does not enforce read-only access at the application layer - it runs with the privileges of the role you provide. To prevent any possibility of touching production data, grant Zingle a least-privilege role:

• Read access to the schemas it needs to introspect and query.
• No privileges to modify your production tables (no INSERT / UPDATE / DELETE / DROP on production objects).
• If you use Refactor's validation features, a scratch space where it may create/drop disposable validation databases/tables - kept separate from production.

Shared responsibility: Git access

• Grant the Git App access to only the repositories Zingle should work with.
• Use branch protection and required reviews on your default branch so that Zingle's pull requests follow the same review gates as any other change.

Summary

Area	Guaranteed by Zingle	Your responsibility
dbt project changes	PR-only; no merge; no direct push to default	Review and merge PRs; branch protection
Production deploys	No auto-deploy	Your CI/CD promotes merged changes
Warehouse writes	No dbt run materialization in the active toolset	Provision a least-privilege role
Repository scope	Works only on connected repos	Grant access to only the intended repos