PRODUCT REQUIREMENTS DOCUMENT — FILTERED EXPORT
ORIGINAL FICTIONAL EXAMPLE. No actual customer research or shipped feature is
claimed. All IDs, evidence references, and decisions below are teaching material.
Prepared 2026-10-27. Status: example for review, not an operational commitment.

1. PURPOSE AND USER
Agency operators prepare recurring reports for individual clients.
The fictional current workflow exports every client's rows and requires manual
deletion of unrelated rows before sharing. The proposed change lets an authorized
operator select one client and export only matching rows.

2. FICTIONAL EVIDENCE
EX-C01: invented conversation about manual deletion of unrelated client rows.
EX-C02: invented conversation about checking a file before sending it.
EX-S01: invented support note asking whether an export can include one client.
A real PRD must replace these with permitted evidence, dates, and context.
These examples do not establish population prevalence or business impact.

3. GOAL AND OUTCOME
Goal: an authorized operator can obtain a single-client export without editing
the downloaded file.
Desired outcome to investigate: fewer manual corrections in the reporting task.
Acceptance of the feature does not prove the outcome occurred.

4. SCOPE
Include one selected client within a report the requester can access.
Use the existing supported export file format and columns.
Check current report access on the server when processing the request.
Show clear empty-result and generation-failure behavior.
Exclude multiple-client bundles, scheduled delivery, new formats, a general
report-builder redesign, and a new account-role system.

5. USER STORY AND SEQUENCE
As an agency operator preparing a client's report, I want an export containing
only that client's rows so I can share it without deleting unrelated data.
Open accessible report -> choose a client available within that report ->
request export -> validate access and selection -> generate existing-format file
with matching rows -> communicate result.
Do not trust a hidden button or a client-side flag as authorization.

6. SYNTHETIC ACCEPTANCE FIXTURE
Report R-DEMO has three rows:
ROW-1, Client A, amount 10
ROW-2, Client B, amount 20
ROW-3, Client A, amount 30
The fixture is invented and contains no customer records.

7. ACCEPTANCE CRITERIA
AC1: An authorized Client A selection returns ROW-1 and ROW-3 only, using the
existing supported columns and format.
AC2: A requester lacking report access receives no report data.
AC3: A valid selected client with no matching rows receives a clear empty-result
message; no empty file download is created.
AC4: Generation failure shows a useful retry message. Diagnostics exclude report
payloads and access tokens.
AC5: Retrying a completed request returns a valid result without creating an
extra billable action. Implementation must define its safe retry mechanism.
Review both expected and forbidden cases in the intended environment.

8. CONSTRAINTS AND OPEN QUESTIONS
Data ownership: validate report and client relationship within the current
account; never accept an arbitrary client ID without checking that relationship.
Open Q1: download availability duration. Owner: Engineering. Resolve before
promising retention behavior.
Open Q2: maximum supported report size and asynchronous job need. Owner:
Engineering with Product. Resolve before pilot approval.
Open Q3: accessibility of selection and result feedback. Owner: Product.
Review keyboard and assistive-technology behavior before pilot.

9. RELEASE AND RECOVERY
Engineering owns implementation and failure response.
Product approves pilot audience after acceptance evidence is reviewed.
Use a temporary release flag for exposure; keep permission checks independent.
Exercise enabled, disabled, unavailable-configuration, failure, and retry paths.
Stop the pilot for a permission regression or incorrect client rows.
A switch affects future exposure; review already-generated files and queued jobs
through a separate recovery process.

10. MEASUREMENT AND REVIEW
Observe successful filtered exports, defined failures, reported manual
corrections, and permission incidents with minimum necessary identifiers.
Do not log report contents.
Review workflow evidence with relevant users before claiming improvement.
Decision log fields: date, decision, reason, affected criteria, owner.
Reviewer signoff fields: Product / Engineering / QA / Support / date / evidence.
In a small team one person may hold several roles; record how checks were made.