Decision inputs
Facts that change the policy answer
Within software engineering, this request uses a code diff, issue context and repository conventions to produce review comments and possible defects. Both belong in the submission before any policy route is trusted.
- 1Task and owner
- Software engineer wants to review a pull request. The request needs an accountable owner for review comments and possible defects, even when the tool prepares most of the first draft.
- 2Information involved
- A code diff, issue context and repository conventions. Account for every route by which the tool receives the material, including plug-ins and linked storage.
- 3Tool and account
- An approved company account. A personal login can handle information differently from the company-managed version of the same tool.
- 4Intended result
- The expected result is review comments and possible defects. The policy needs to know what happens after generation, including publication, communication and automated use.
- 5Consequence if it is wrong
- The review may expose private code and can create false confidence if treated as approval. A familiar task still needs escalation when this consequence becomes plausible.
- 6Human review
- human code reviewer should inspect, change, reject or stop the result. A final glance after an automatic action would not give that owner meaningful control.
Possible policy routes
The task name alone cannot decide it.
A published workplace policy can return different answers for the same task. These are the practical branches worth encoding.
A routine policy route may be possible
A routine route is easier to justify when the exact account is approved, only the minimum proprietary source code is used, review comments and possible defects remains within the stated purpose, and human code reviewer reviews it before use.
Approval may be required
Send the request for approval if the account or data handling is uncertain, the review may expose private code and can create false confidence if treated as approval, or review comments and possible defects reaches people or systems beyond the requester’s authority.
The request may need to stop or change
Do not continue unchanged when restricted information would enter an unapproved service, the output would act before human code reviewer can intervene, or keep branch protections and require a person to inspect the diff and tests cannot be maintained. Consider less information, a controlled account or a non-AI process.
Request checklist
Questions to ask before using the tool
- 01
Will review a pull request run inside the approved company environment from start to finish?
- 02
What is the most sensitive element in a code diff, issue context and repository conventions, and does the tool need it?
- 03
Does review comments and possible defects create an external statement, a decision or an automated action?
- 04
Can human code reviewer inspect the complete result and its source before reliance?
- 05
Would another region, audience or frequency activate a different company rule?
Worked request
What the employee should submit
This example supplies decision facts without pasting the underlying material into the approval record.
- requester
- software engineer
- task
- Use AI to review a pull request.
- information
- a code diff, issue context and repository conventions
- tool
- An approved company account
- frequency
- Recurring work
- region
- Where the work and affected people are located
- purpose
- Analyse
- impact
- Production software
- review
- Complete human review
- owner
- human code reviewer
Useful safeguards
Controls that fit this request
- ✓
Keep branch protections and require a person to inspect the diff and tests
- ✓
Separate source material from the request record and expose only what the tool needs for review comments and possible defects.
- ✓
Write the boundary around review comments and possible defects clearly so later users do not expand the approval by assumption.
- ✓
Keep the submitted facts, human code reviewer’s decision and the exact published policy version.
Questions people ask
About this AI use
Is using AI to review a pull request automatically allowed?
The company policy supplies the answer after it receives the real tool, data, purpose, impact and review plan. This page only prepares those facts.
What belongs in the employee’s request?
Describe review comments and possible defects, identify a code diff, issue context and repository conventions, name the exact tool and account, explain who will receive or rely on the output, and state how human code reviewer will review it.
Which evidence makes the answer reproducible?
Keep the submitted facts, human code reviewer’s decision and the exact published policy version. A classification and controlled reference may be enough when copying a code diff, issue context and repository conventions would create unnecessary risk.