Decision inputs
Facts that change the policy answer
Here the tool receives component behaviour, accessibility and usage conventions, while someone ultimately relies on component documentation. The policy must evaluate the whole path between them.
- 1Task and owner
- Design systems designer wants to document a design system component. The request needs an accountable owner for component documentation, even when the tool prepares most of the first draft.
- 2Information involved
- Component behaviour, accessibility and usage conventions. The classification must cover what the tool can retrieve as well as what the requester types.
- 3Tool and account
- An approved company account. Treat a new plug-in or connector as a change to the approved setup.
- 4Intended result
- The expected result is component documentation. Record the audience and the next system in the chain, rather than describing the output only as a draft.
- 5Consequence if it is wrong
- Generated examples can conflict with actual implementation or accessibility behaviour. This is the fact most likely to move the request from routine handling into review.
- 6Human review
- component owner should inspect, change, reject or stop the result. Make the review happen before reliance and give the reviewer a real way to stop the work.
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 and public product information is used, component documentation remains within the stated purpose, and component owner reviews it before use.
Approval may be required
Send the request for approval if the account or data handling is uncertain, generated examples can conflict with actual implementation or accessibility behaviour, or component documentation reaches people or systems beyond the requester’s authority.
The request may need to stop or change
The proposed use should pause if restricted information would enter an unapproved service, the output would act before component owner can intervene, or test examples in the released component and review interaction guidance 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 document a design system component, and what external connections can it reach?
- 02
What is the most sensitive element in component behaviour, accessibility and usage conventions, and does the tool need it?
- 03
Does component documentation create an external statement, a decision or an automated action?
- 04
Does component owner have enough authority and time to stop 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
- design systems designer
- task
- Use AI to document a design system component.
- information
- component behaviour, accessibility and usage conventions
- tool
- An approved company account
- frequency
- Recurring work
- region
- Where the work and affected people are located
- purpose
- Draft or analyse
- impact
- Internal work
- review
- Complete human review
- owner
- component owner
Useful safeguards
Controls that fit this request
- ✓
Test examples in the released component and review interaction guidance
- ✓
Separate source material from the request record and expose only what the tool needs for component documentation.
- ✓
Set an expiry or review point when recurring work turns into a permanent process.
- ✓
Keep the submitted facts, component owner’s decision and the exact published policy version.
Questions people ask
About this AI use
Is using AI to document a design system component automatically allowed?
Treat this as a request pattern. The authoritative answer comes from the current company policy and the employee’s completed submission.
What does the policy need to know about this use?
Describe component documentation, identify component behaviour, accessibility and usage conventions, name the exact tool and account, explain who will receive or rely on the output, and state how component owner will review it.
What should remain after the decision?
Keep the submitted facts, component owner’s decision and the exact published policy version. A classification and controlled reference may be enough when copying component behaviour, accessibility and usage conventions would create unnecessary risk.