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