Human approval boundary

The core boundary

Guard can collect evidence, prioritize work, create a durable issue, and prepare a bounded review request. A qualified person remains responsible for product decisions, provider authorization, reviewing code, approving deployment-sensitive changes, and performing the final merge.

This boundary is part of the improvement engine, not a fallback. The goal is a maintained green-zone codebase without turning generated artifacts into unreviewed production changes.

Read-only workflows

Repository audits and recon read evidence and save reports inside Guard but do not change the audited repository. Code review reads the PR/MR and can post a scoped review reply to the original provider thread; it does not change files, create branches, approve, close, or merge the request.

Read-only does not mean no access. These workflows still need enough repository and provider visibility to support their conclusions.

Issue-only workflows

An issue-only improvement may create or reuse one provider issue containing current evidence, impact, proposed direction, verification plan, and limitations. It does not edit files or open a review request. Use this path when the change needs ownership, architecture, rollout, legal, security, or product judgment.

Someone must decide whether the issue should be implemented, rejected, narrowed, or closed.

Review-request workflows

When permitted, Guard can create a branch, commit a small change, push it, and open a pull or merge request linked to an issue. The runbook must still establish current scope, duplicate-free provider state, reversibility, and credible verification. Failed verification or high blast radius keeps the outcome issue-only or needs-human-review.

Guard never pushes directly to the default branch and never auto-merges. Repository-required checks, CODEOWNERS, branch protection, approvals, and provider policy continue to apply.

Decisions Guard does not own

Keep these decisions human-controlled: accepting active-testing risk; changing an authentication or authorization model; selecting a license; publishing results; making public API or data-model breaks; running migrations; changing production infrastructure or rollout policy; approving a major dependency upgrade; and interpreting legal, compliance, or business consequences.

After approval

Merge through the provider only after reviewing evidence, diff, checks, limitations, and current branch state. Then rerun the affected audit. A human-approved PR/MR shows that a proposal was accepted; the new audit shows whether project health actually improved.