Decision inputs
Facts that change the policy answer
Within software engineering, this request uses an existing module and technical context to produce a plain-language explanation of the module. Both belong in the submission before any policy route is trusted.
- 1Task and owner
- Software engineer wants to explain legacy source code. Responsibility for a plain-language explanation of the module stays with a named person or team throughout the request.
- 2Information involved
- An existing module and technical context. The classification must cover what the tool can retrieve as well as what the requester types.
- 3Tool and account
- An approved company account. The request should identify the exact account because product-level approval leaves important controls unknown.
- 4Intended result
- The expected result is a plain-language explanation of the module. Its destination matters: private working material creates a different consequence from a sent, published or automated result.
- 5Consequence if it is wrong
- The code may contain secrets or the explanation may miss hidden behaviour. The policy route should reflect this possible harm instead of relying on how ordinary the task sounds.
- 6Human review
- engineer who knows the system should inspect, change, reject or stop the result. Their role should include checking source facts, correcting errors and refusing the proposed use.
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
The request may fit ordinary policy handling once the exact account is approved, only the minimum proprietary source code is used, a plain-language explanation of the module remains within the stated purpose, and engineer who knows the system reviews it before use.
Approval may be required
Pause the ordinary route whenever the account or data handling is uncertain, the code may contain secrets or the explanation may miss hidden behaviour, or a plain-language explanation of the module reaches people or systems beyond the requester’s authority.
The request may need to stop or change
The policy may require another method where restricted information would enter an unapproved service, the output would act before engineer who knows the system can intervene, or remove credentials and validate the explanation against tests and runtime behaviour cannot be maintained. Consider less information, a controlled account or a non-AI process.
Request checklist
Questions to ask before using the tool
- 01
Which approved account will perform explain legacy source code, and what external connections can it reach?
- 02
Could an existing module and technical context be reduced to a short de-identified extract?
- 03
At what point does a plain-language explanation of the module move beyond the requester’s private draft?
- 04
What evidence will engineer who knows the system use to accept, correct or reject the result?
- 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 explain legacy source code.
- information
- an existing module and technical context
- tool
- An approved company account
- frequency
- Recurring work
- region
- Where the work and affected people are located
- purpose
- Analyse
- impact
- Internal work
- review
- Complete human review
- owner
- engineer who knows the system
Useful safeguards
Controls that fit this request
- ✓
Remove credentials and validate the explanation against tests and runtime behaviour
- ✓
Reduce an existing module and technical context to the smallest useful extract and remove fields unrelated to a plain-language explanation of the module.
- ✓
Treat a new purpose, region, data source or recipient as a new request rather than silently extending this one.
- ✓
Record the request and reviewer without copying unnecessary parts of an existing module and technical context into the audit trail.
Questions people ask
About this AI use
Is using AI to explain legacy source code 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.
How specific should the workplace AI request be?
Describe a plain-language explanation of the module, identify an existing module and technical context, name the exact tool and account, explain who will receive or rely on the output, and state how engineer who knows the system will review it.
What belongs in the completed policy record?
Record the request and reviewer without copying unnecessary parts of an existing module and technical context into the audit trail. A classification and controlled reference may be enough when copying an existing module and technical context would create unnecessary risk.