Run an evidence-based review of the pilot boundary

A useful review starts with a specific claim: this selected request for one new GitHub branch follows the controlled path and produces evidence a person can reconcile. Keep the repository, exact existing commit, unique branch name, and pilot environment in scope. Broad claims about protecting all agent actions need evidence this narrow pilot cannot supply.

Assign a reviewer who can inspect the workflow and a repository owner who can explain provider access and automation. Agree where sensitive evidence will be stored. Public summaries should contain redacted observations, not customer repository content, credential values, or private approval records.

Inspect how the requested action is represented, which policy applies, and who may supply the required human passkey approval. Verify that the reviewed repository, branch, and SHA are the inputs associated with execution. Treat changed inputs as a new request rather than a minor variation of the approved one.

Keep policy, human authorization, explicit execution, and provider readback separate in the review notes. A favorable policy result does not itself create a branch. A human confirmation does not prove provider completion. The reviewer needs evidence for each transition that the team intends to rely on.

• What evidence connects the reviewed inputs to the execution record?
• Which credentials or tools could bypass the controlled route?
• What happens when the provider outcome is uncertain?
• Which repository workflows could follow branch creation?

Classify each observation as a live provider result, a safe-mode rehearsal, a documented behavior, or an unresolved question. Codex and Claude Code runtime safe-mode rehearsals do not establish live writes from those runtimes. A separate live GitHub proof should remain separately identified in the evidence record.

Likewise, the verified replay of an exact Gated request concerns that request path. It is not a general promise about provider idempotency. After a timeout, inspect request status and provider state before considering another write. Record mismatches and missing evidence even if the expected path appears to work.

For every finding, assign an owner, the evidence needed to resolve it, and a follow-up date. Decide whether it blocks this narrow evaluation or simply limits what can be concluded. Do not run destructive probes or broaden the repository scope as part of a worksheet exercise.

Gated is a controlled private preview for non-critical use. Merge, deletion, branch updates, force pushes, and deployments are outside the supported operation. This worksheet is a review aid, not a certification or proof of security effectiveness. It helps the team explain what it observed and what remains unverified.