Approvals, audit, and bounded automation

Automation needs a stopping rule

A bounded action has a defined input, destination, permission set and completion condition. It also says what happens when a step fails. This is useful even without AI: retries and partial results can cause duplicate branches, repeated changes or misleading success messages.

Begin with deterministic automation

The capstone's first supported action produces a PR for a local MicroBank configuration change. It has a defined set of inputs, affected files, permissions, and completion checks. Once that path works, you can consider automating a later step. A request to automate the SDLC does not require an agent with unrestricted shell or cloud access.

Separate proposing a change, authorizing it, applying it, and verifying it. A retry should not create duplicate infrastructure or hide a partial failure. Request IDs, recorded state transitions, concurrency controls, and timeouts make those behaviors inspectable.

Define a bounded action set

If AI assistance is explored later, let it propose explanations or changes within these same controls. Retrieved documents, logs, and PR text are data, not instructions granting extra authority. Keep the production authorization boundary in deterministic systems.

Rehearse the state transitions

For the first portal request, draw these states on paper: received → validated → rendered → PR created → reviewed → selected for sync → verified. Attach an observation to each arrow. Do not skip from “form accepted” to “deployed.”

Now exercise four failures:

If AI later proposes a repair, it can draft an explanation or patch inside this process. It should not gain extra authority because a log or issue contains instructions. The systems enforcing review and permission remain responsible for the actual decision.

In the capstone, demonstrate one permitted request and one understood failure. Expanding to artifact releases is a separate implementation step with a trusted release inventory. Expanding to destructive data operations needs its own recovery and authorization design.

Try it

Write a state table for requested, validated, PR-created, checks-failed, approved, synced, verified, and failed. For every transition, identify its actor and evidence. Include duplicate submission, timeout, cancelled approval, and portal outage.

Rehearse a denied input and a failed downstream check. Confirm neither triggers an uncontrolled retry or reports successful deployment. Retain request, actor, time, configuration identity, decision, and result in the audit record.

Checkpoint and revision

Demonstrate one complete permitted journey and one recovered failure before extending the action set. Define and test the system’s authority and stopping behavior before giving it another action to perform.

Compare your reasoning

A retry is not always harmless. The system must know whether the previous step changed external state before starting again. Keep the workflow small enough that a learner can explain every state and recover it using the underlying tools.

Sources

Backstage scaffolder authorization↗, GitHub deployments and environments↗, Port self-service↗.