Planetscale Change Gates And Approval Contract

Change gates and approval contract

Purpose

Prevent accidental or autonomous changes that can affect availability, safety, security, data, or developer workflows.

Operation classes

Class A: read-only by default

Allowed without approval:

• List databases, branches, keyspaces, webhooks, backups, roles, traffic budgets, schema recommendations, deploy requests, and Insights data.
• Inspect repository code.
• Read schema metadata.
• Read non-sensitive database metadata.
• Produce reports and proposed change sets.

Class B: state-creating proposals

Allowed by default; requires approval only when the operator has demanded strict no-mutation mode:

• Creating a query-pattern report through an API POST, even if the result is read-only telemetry.
• Triggering a webhook test event.
• Creating temporary local branches or files.
• Opening PRs or issues in external tools.
• Creating database development branches.
• Applying DDL or migrations to non-production development branches.
• Opening deploy requests targeting a branch protected by a review workflow.

The last three are proposals inside an existing review system: nothing

reaches production until a human merges or deploys. The gate belongs on

the merge/deploy action (Class C/D), not on proposal creation. An agent

that stops to ask permission to open a PR is misclassifying.

Class C: behavior-changing

Always requires explicit approval:

• Enable safe migrations.
• Disable safe migrations.
• Change deploy request approval settings.
• Create/update/delete Traffic Control budget or rule.
• Move Traffic Control budget to enforce mode.
• Create/update/delete webhook.
• Enable raw query collection.
• Enable/disable extensions or settings that require restart.
• Create/update/delete role.
• Reset passwords.
• Change pg_strict settings.
• Change connection pooling behavior.
• Change IP restrictions, PrivateLink, PSC, or public access.
• Change backup schedule or retention.
• Create restore branch.
• Create backup beyond automatic backups.
• Change branch size or replica topology.
• Edit repository files or dependencies.

Class D: production data/availability impacting

Requires explicit approval, named target confirmation, rollback plan, and ideally a second human review:

• Production DDL.
• Production DML.
• Applying schema recommendation to production.
• Queueing or applying Vitess deploy request to production.
• Promoting or restoring branches.
• Deleting branches, databases, roles, webhooks, backups, or traffic rules.
• Enforcing Traffic Control on production.
• Changing production network access.
• Rotating production credentials.
• Emergency backup during high load.

Class E: never autonomous

Never do without direct human operation or separately approved incident procedure:

• Delete a production database.
• Disable all production safety mechanisms.
• Drop production tables or columns.
• Remove IP restrictions or private-only posture.
• Store or expose secrets in logs, issues, PRs, Slack, or reports.
• Auto-merge code generated from database telemetry.
• Auto-apply DDL generated by an LLM.

Approval requirements

A valid approval must include:

• Change ID.
• Target organization/database/branch.
• Whether production is affected.
• Permission to execute the exact action.

Invalid approvals:

• “Do the best practices.”
• “Fix everything.”
• “Apply recommendations.”
• “Go ahead” without named change IDs.

Autonomous execution exception

There is exactly one alternative to per-change approval: the risk-acknowledged

autonomous mode defined in ../13-autonomous-execution-mode/SKILL.md. When the

operator explicitly acknowledges the risk, names a scope, and states whether

production is included, that acknowledgment substitutes for per-change approval

of Class B/C (and Class D when production is included) actions **within the

named scope only**.

Everything else in this skill still applies in autonomous mode:

• Class E is never unlocked by any phrasing.
• The pre-execution checklist must still be produced for every Class C/D step

(shown as the execution plan, not as a stop-and-wait).

• The post-execution report is still required.
• Out-of-scope work still requires new approval or new acknowledgment.

Required pre-execution checklist

Before any Class C or D action, produce:

• Exact command, API endpoint, dashboard action, SQL, or repository diff.
• Target confirmation.
• Expected effect.
• Availability impact.
• Data risk.
• Security risk.
• Rollback plan.
• Validation plan.
• Monitoring plan.

Then stop for approval.

Required post-execution report

If an approved change is later executed, report:

• What changed.
• When it changed.
• Who approved.
• Interface used.
• Evidence of success.
• Any warnings.
• Rollback state.
• Follow-up monitoring.

Required refusal behavior

If asked to apply broad or ambiguous production changes, refuse the broad action and produce a safer named change plan.

Use this sentence:

“I will not apply broad production changes from an ambiguous instruction. I can produce a named change set with risk and rollback details.”