Scope Generation

Scope generation turns a PRD into a structured scope document. Instead of estimating from scratch in a spreadsheet, you point Scopingly at a requirement and it produces deliverables, effort, assumptions, and a plan — with a provenance link back to the exact PRD version it came from.

What gets generated

The output is a scope.v1 document: a structured, versioned artifact rather than free prose. It captures, among other sections:

• Context — the problem, goals, non-goals, and constraints
• Scope — what's in, what's out, and a list of deliverables
• Solution — components changed, interfaces, data changes
• Plan — milestones, dependencies, and resourcing (including an effort estimate)
• Safety — risks and mitigations, security/privacy, rollback plan
• Success — metrics and acceptance criteria

Effort is document-level

A scope.v1 carries its effort estimate at the document level (for example, estimated weeks in the resourcing plan) — not per deliverable. When a schedule projection needs per-item effort, the total is split evenly across deliverables that don't carry their own. See schedule & compression.

Provenance

Every generated scope records where it came from. Generation stamps the scope's first version with the source PRD version it was generated from (source_prd_version_id), plus the PRD's status at the time. This is the link that makes the rest of the system work:

• If the source PRD is later revised and re-approved, scopes generated from the old version are flagged as drifted — see scope drift.
• Calibration measures actual effort against the committed baseline, not a moving target.

Provenance also runs at the line level: scope lines are mapped back to the source PRD blocks they were derived from, so you can trace a deliverable to the requirement text behind it.

Running a generation

Generate a scope from the PRD view. Editors and above on the PRD can trigger it; viewers cannot. There are two ways it runs:

• Inline — the request generates the scope and returns the new document.
• Async job — the request enqueues a durable job and returns a job id you poll for status. This is the path for larger PRDs and version-scoped generation, and it survives transient model or network hiccups.

Either way, the model output is validated against the scope.v1 schema before anything is persisted, so a malformed generation fails cleanly rather than writing a broken document.

Generation consumes your AI quota

Scope generation is a token-consuming operation and counts against your organization's monthly AI generation quota. Over the cap, generation is refused before any model runs — no partial charge. Deterministic work (like gap detection) does not count.

Regenerating without losing your edits

When a PRD changes, you may want a fresh scope — but you've likely edited the existing one. Rather than overwrite your work, Scopingly offers a regeneration-as-diff preview: it generates a new scope, diffs it against your current one, and shows what regenerating would clobber versus the edits you've made. The preview is non-destructive — nothing is written until you decide.

After generation

A generated scope is a draft you can edit, then commit:

1. Review and edit the deliverables, assumptions, and estimate.
2. Commit a version. Approving a scope makes it an immutable baseline — see scope versioning.
3. Project it onto a target date with the compression meter.
4. Break it into epics for delivery — see epics.

Availability

Scope generation is available on all plans, subject to your monthly AI generation quota. See the feature matrix for per-plan quotas.