Decision inputs
Facts that change the policy answer
Within product and design, this request uses a verified user need and product context to produce a user story with acceptance criteria. Both belong in the submission before any policy route is trusted.
- 1Task and owner
- Product manager wants to draft a user story. Responsibility for a user story with acceptance criteria stays with a named person or team throughout the request.
- 2Information involved
- A verified user need and product context. Look beyond pasted text: files, integrations and retrieval connections can expose the same material.
- 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 a user story with acceptance criteria. State whether another person will see it, rely on it or receive an action produced from it.
- 5Consequence if it is wrong
- Generated detail can be mistaken for actual customer evidence. This is the fact most likely to move the request from routine handling into review.
- 6Human review
- product owner 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 internal product information is used, a user story with acceptance criteria remains within the stated purpose, and product owner reviews it before use.
Approval may be required
Pause the ordinary route whenever the account or data handling is uncertain, generated detail can be mistaken for actual customer evidence, or a user story with acceptance criteria reaches people or systems beyond the requester’s authority.
The request may need to stop or change
The company may need a safer design when restricted information would enter an unapproved service, the output would act before product owner can intervene, or trace the story to observed evidence and let engineering refine acceptance criteria cannot be maintained. Consider less information, a controlled account or a non-AI process.
Request checklist
Questions to ask before using the tool
- 01
Has the company approved this account configuration for draft a user story, rather than only approving the product?
- 02
Can any personal, sensitive, confidential or secret part of a verified user need and product context be removed?
- 03
Could someone treat a user story with acceptance criteria as final even though it was generated as assistance?
- 04
Can product owner inspect the complete result and its source before reliance?
- 05
Does the intended use extend beyond the region and audience covered by the current policy?
Worked request
What the employee should submit
This example supplies decision facts without pasting the underlying material into the approval record.
- requester
- product manager
- task
- Use AI to draft a user story.
- information
- a verified user need and product context
- 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
- product owner
Useful safeguards
Controls that fit this request
- ✓
Trace the story to observed evidence and let engineering refine acceptance criteria
- ✓
Start with a de-identified sample of a verified user need and product context before considering broader access.
- ✓
Keep the use within draft or analyse and run another check if the audience, tool or intended effect changes.
- ✓
Record the request and reviewer without copying unnecessary parts of a verified user need and product context into the audit trail.
Questions people ask
About this AI use
Is using AI to draft a user story automatically allowed?
Treat this as a request pattern. The authoritative answer comes from the current company policy and the employee’s completed submission.
Which facts should be submitted before work begins?
Describe a user story with acceptance criteria, identify a verified user need and product context, name the exact tool and account, explain who will receive or rely on the output, and state how product owner will review it.
What belongs in the completed policy record?
Record the request and reviewer without copying unnecessary parts of a verified user need and product context into the audit trail. A classification and controlled reference may be enough when copying a verified user need and product context would create unnecessary risk.