PRD Approval

All plans

A PRD is a versioned, approvable artifact — the same shape as scope versioning. Approval turns a working draft into an immutable version that downstream work can bind to, which is what makes it possible to detect when a change has left a generated scope out of date.

Availability

The approval-lifecycle interface — the approval bar, drift banner, and regeneration preview — is being rolled out behind a feature flag. If you don't see it yet, it may not be enabled for your workspace.

Versions and status

A PRD version moves through a fixed lifecycle:

draft ──▶ in_review ──▶ approved ──▶ superseded

• draft — being written and revised.
• in_review — review has been requested; reviewers can sign off.
• approved — a committed, immutable version. Readers see this as the live one.
• superseded — a previously approved version that a newer approval has replaced.

Each version is an immutable record. Its reviewers are pinned per version, so a version carries the exact roster that reviewed it.

Sign-off vs. approval

These are two different acts, and Scopingly keeps them distinct:

• Reviewers sign off. A reviewer records a verdict — signed off or changes requested. The latest verdict per reviewer wins, so a reviewer can change their mind. A sign-off is an attestation; it never changes the version's status on its own.
• The owner approves. Only the PRD owner (or an org admin) approves a version. Reviewers never "approve" — approval is a separate, accountable decision.

Sign-off is not approval

Reviewers advise; the owner decides. Approval records who had signed off — and who had requested changes — at the moment it happened, but outstanding reviewers do not block it. The design is: do not block, record.

Self-approval

Whether an owner can approve their own PRD without another reviewer's sign-off is controlled by an organization self-approval setting — the same setting that governs scope approval. See roles & permissions.

Immutability and forking

Once a version is approved, its content is frozen — you cannot edit an approved version in place. To change an approved PRD, you fork a new version, which starts a fresh draft from the approved one. This mirrors how an approved scope is superseded rather than edited.

Attempting to edit a frozen version's content is rejected until an open fork exists.

Approval and scope drift

Scope generated from a PRD is stamped with the exact PRD version it came from (provenance, not a gate — you can generate scope from a draft). When you approve a change that supersedes the version a scope was generated from, every scope derived from that now-superseded version is flagged as drifted — a signal that the requirement moved and the generated scope may need a fresh look.

Drift is surfaced on the affected scope, not on the PRD. See scope versioning for how drift and regeneration work downstream.

Who can do what

Action	Who
Request review, approve, return to draft, fork	Owner or org admin
Sign off (or request changes)	Assigned reviewers
View versions and status	Viewer and above

Access is scoped to your organization; org admins can act across PRDs. See roles & permissions and PRD reviewers.

The typical flow

1. Request review on a draft. Its status moves to in_review and pinned reviewers are notified.
2. Reviewers sign off or request changes.
3. The owner approves. The version becomes immutable; any prior approved version is superseded.
4. Generate scope from the approved version, with provenance back to it — see scope generation.
5. Fork a new version when the requirement changes; the cycle repeats.

Part of the PRD lifecycle

Approval is the final step of the PRD lifecycle: assess for gaps, summarize, then review and approve.