Document Review
When a draft exists, the initiative page becomes the PRD Review surface. Most work uses a structured PRD. Strict low-risk bug or patch initiatives sized xs or s may use a lightweight implementation brief instead when required source context is present and eligibility checks pass.
Use it to:
- Read generated PRD sections by cluster: problem, goals, user stories, scope, constraints, open questions, and success criteria.
- Inspect source provenance for each section.
- See section quality: sourced, inferred, gap, or not applicable.
- Review lightweight brief fields, source metadata, gaps, and approval blockers when inrelay uses the low-risk brief path.
- Confirm or edit inferred assumptions.
- Fill gap sections or mark them not applicable with a required reason.
- Review unresolved conflicts.
- Review coverage by dimension.
- Export Markdown or DOCX.
- Approve or reject the document.
Approve when the product document or lightweight brief is good enough to drive Technical Discovery & Refinement.
Unresolved gap sections block PRD approval in both the UI and backend. Missing required lightweight brief fields block approval for lightweight briefs. Inferred sections remain visible, auditable, confirmable, editable, and available downstream; they do not block approval by default.
Reject when the document needs more source material or correction. Rejection requires a reason. inrelay classifies the rejection, turns required corrections into targeted readiness questions, and can regenerate the PRD after the source context changes.
PRD or lightweight brief approval does not mean the work is ready for engineers or agents. Technical Discovery & Refinement, Delivery Plan readiness, Handoff Pack scope review, and any required blueprint gates still protect the final handoff.
Approval permissions depend on the team setting:
- Member approval allows any team member to approve or reject.
- Admin approval requires a workspace owner or admin.