Add approval without leaving an older bypass open

Inventory the paths that can write

List the user interface, API endpoints, background jobs, administrative tools and retry handlers that perform the operation. Include older application versions still in use. The approval requirement needs to be enforced where the effect occurs, not only in the newest screen.

Identify legitimate exceptions, such as a separate administrative process with its own authority controls. Keep them explicit and narrowly scoped. An undocumented exception often becomes the route through which an assistant bypasses the new review.

Define how existing queued work will be treated. Some requests may already have valid authority under the old process, while others should be paused for review. That decision belongs in the migration plan.

Introduce proposal records before enforcement

Deploy the storage and state model needed to represent proposals, decisions and executions. Make readers tolerant of the new states before requiring them on every write. This reduces the risk of an older client misinterpreting a pending proposal as a completed action.

Where appropriate, observe the new proposal flow without executing it, comparing the recorded payload with the existing request. Do not describe this as enforced approval until the executor actually requires a valid decision.

Backfill only information that can be established reliably. Assigning historical approvals to old operations without evidence creates a misleading audit trail.

Enforce at the executor boundary

Require a valid approved proposal for the covered operation, then remove or restrict direct mutation routes. The executor should load the approved payload and verify current eligibility. A client-supplied boolean is not enough.

Test with an old client request and a direct API call. Both should receive the intended rejection or migration response. Also exercise retry workers that were started before the deployment.

Keep the interface clear during transition. Users need to distinguish a saved proposal, a decision awaiting review and a completed mutation.

Plan rollback without reopening authority

If the new interface fails, consider disabling the affected operation or using the supported manual process rather than automatically restoring an unreviewed write path. The correct fallback depends on the business requirement that prompted approval.

Verify queued proposals and in-flight operations before retiring compatibility code. Record which version introduced enforcement and how exceptions are controlled. The migration is complete when every covered route reaches the same authority rule and old clients cannot silently avoid it.