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 ../planetscale-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.”