Human approval

What it means

Human approval is the line between what Enji Guard may prepare and what a person decides. Enji Guard may gather evidence, rank the work, open one durable issue, and prepare one bounded review request; a qualified person keeps product decisions, provider authorization, code review, deployment-sensitive approvals, and the final merge.

A reviewer can reject, narrow, or close a proposal, so it is no rubber stamp. Enji Guard has no approve button; approval and merge happen in GitHub or GitLab. The pull request toggle changes what Enji Guard prepares, never who merges.

The term is narrower than human oversight in AI regulation or human-in-the-loop in machine learning: it names who decides on a repository change.

Three write levels:

• Read-only. Audits and recon store reports inside Enji Guard; the repository is untouched.
• Issue-only. One provider issue with evidence, impact, direction, and limitations; no file edits.
• Review request. When permitted, a branch, a small commit, and one linked pull or merge request; failed verification keeps it issue-only or needs-human-review.

Where it appears in Enji Guard

The application has no human approval label; the boundary shows up where it takes effect:

• Open a pull request with the fix, the toggle on an improvement job. Its note says you still review and merge; Recurring fixes closes with “You decide whether to review and merge them.”
• The review request left open for the provider’s reviewers; the toggle permits an attempt, not code on every run.
• Code review, which posts one reply and never approves, closes, or merges the request.
• Active-testing consent, given by the site owner or someone with written permission before Auto-pentest tests one linked website; it does not cover code writes.

Why it matters for AI-written code

A generated change can compile, pass its tests, and still miss product intent. Whoever owns the codebase decides whether it belongs and carries the accountability.

Provider controls still apply: GitHub branch protection can require approving reviews, including from code owners; authors cannot approve their own pull requests; and SLSA’s source track asks two or more trusted persons to agree to each change on a protected branch.

How Enji Guard helps

Enji Guard hands the reviewer the evidence, the issue, a bounded diff when the write mode allows one, and the verification record. The reviewer merges through the provider once the branch is current.

Then the reviewer reruns the affected audit. A merged request only shows that a proposal was accepted; the fresh report shows whether the project moved toward green.

Enji Guard never merges or writes to the default branch. Active-testing risk, authentication or authorization models, licenses, publishing results, public API or data-model breaks, migrations, production infrastructure and rollout policy, major dependency upgrades, and legal, compliance, or business consequences stay with the team.