Decision inputs
Facts that change the policy answer
Here the tool receives options, constraints and technical evidence, while someone ultimately relies on an architecture decision draft. The policy must evaluate the whole path between them.
- 1Task and owner
- Software architect wants to draft an architecture decision record. Name who owns the finished an architecture decision draft; ownership should not disappear because AI helped produce it.
- 2Information involved
- Options, constraints and technical evidence. Check uploads, history and connected systems before describing the request as low sensitivity.
- 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 an architecture decision draft. State whether another person will see it, rely on it or receive an action produced from it.
- 5Consequence if it is wrong
- Generated confidence can hide assumptions or omit dissenting evidence. That risk sets the level of review and the person who should receive an exception.
- 6Human review
- architecture group should inspect, change, reject or stop the result. Review is meaningful only when that person has enough context and authority to change the result.
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 internal architecture information is used, an architecture decision draft remains within the stated purpose, and architecture group reviews it before use.
Approval may be required
A named reviewer should take over when the account or data handling is uncertain, generated confidence can hide assumptions or omit dissenting evidence, or an architecture decision draft 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 architecture group can intervene, or record sources, alternatives, trade-offs and the human decision owner 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 draft an architecture decision record run inside the approved company environment from start to finish?
- 02
Who is permitted to expose options, constraints and technical evidence to this tool and for this purpose?
- 03
Who receives an architecture decision draft, and what will they do with it?
- 04
Will architecture group review before the result is sent, published or acted upon?
- 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 architect
- task
- Use AI to draft an architecture decision record.
- information
- options, constraints and technical evidence
- tool
- An approved company account
- frequency
- Recurring work
- region
- Where the work and affected people are located
- purpose
- Draft or analyse
- impact
- Technical direction
- review
- Complete human review
- owner
- architecture group
Useful safeguards
Controls that fit this request
- ✓
Record sources, alternatives, trade-offs and the human decision owner
- ✓
Start with a de-identified sample of options, constraints and technical evidence before considering broader access.
- ✓
Reassess the request whenever its tool, information classification, frequency or consequence changes.
- ✓
Preserve who accepted an architecture decision draft, when they did so and which rule version they applied.
Questions people ask
About this AI use
Is using AI to draft an architecture decision record automatically allowed?
The task name cannot settle the answer. Apply the company’s published rules to options, constraints and technical evidence, the exact account, an architecture decision draft, its audience and the proposed review.
When is the request detailed enough to decide?
Describe an architecture decision draft, identify options, constraints and technical evidence, name the exact tool and account, explain who will receive or rely on the output, and state how architecture group will review it.
What belongs in the completed policy record?
Preserve who accepted an architecture decision draft, when they did so and which rule version they applied. A classification and controlled reference may be enough when copying options, constraints and technical evidence would create unnecessary risk.