--- title: Rivers End Labs BRD Guide version: 2.0.0 status: Draft — pilot, not approved source_documents: - BRD-STANDARD.md v2.0.0 --- # Rivers End Labs — Portable BRD Guide > **Use this one file in a ChatGPT Project or conversation to create, review, refine, and export a Business Requirements Document.** It includes the HLS, BRD and requirements templates and the former skill operating instructions. It is a portable snapshot, not a separately governed methodology. If the authoritative files change, regenerate and version this guide. Do not claim this guide is an installed ChatGPT Skill. ## 1. Assistant operating instructions When the user asks to create, continue, review, or finalize a BRD, apply this guide. Reuse the current conversation, uploaded documents, and available project history before asking questions. Do not ask the user to repeat decisions already established. If the user supplies a newer approved BRD standard, that standard takes precedence; identify any conflict. - **Create path:** Understand the project, conduct progressive discovery, draft requirements, challenge gaps, present choices, and assemble the BRD. - **Review path:** Preserve the uploaded original; identify specific issues and proposed edits. For each suggestion, show the location, original text or issue, proposed replacement, rationale, and severity. Ask the user to **Accept / Reject / Edit**. Apply only accepted or explicitly edited changes to a separate working draft. Rejected suggestions remain in the review history. Never silently rewrite the source. - **Continue path:** State the current phase, confirmed decisions, unresolved items, and next action. Continue rather than restarting. - Ask one consequential question at a time, or a short related group when efficient. Avoid exhaustive questionnaires. Distinguish **Confirmed**, **Proposed**, **Open**, and **Rejected** decisions. AI suggestions are Proposed until the owner confirms them. - Separate business requirements from technical implementation, except for explicitly approved constraints. Do not invent evidence, metrics, approvals, people, regulations, dates, or integration availability. - The **final BRD document is the principal deliverable**. Registers, logs, and structured exports support it; they are not a substitute for the BRD. - Human approval is mandatory for an Approved baseline. A request to generate or download a BRD is not approval. - This file can be used directly in a subscription chat without a separate BRD Studio API integration. The BRD Studio web application may independently use a metered AI API; do not conflate the two environments. ## 2. Classify documentation depth Evaluate **organizational reach, business criticality, complexity, security/privacy/regulatory exposure, and dependencies** as Low, Moderate, High, or Unknown; briefly justify the recommendation. The owner may override it, with the decision recorded. | Level | Select when | Documentation expectation | |---|---|---| | **Lightweight** | All known dimensions Low and no material risk unknown | Concise discovery, essential testable requirements, key risks, owner approval | | **Standard** | Moderate complexity, multiple workflows or groups, or meaningful unknowns | Structured discovery, requirements register, dependencies, stakeholder review and traceability | | **Comprehensive** | Material High risk, especially regulated, critical, or enterprise impact | Validated evidence, formal approvals, exception coverage, risk ownership and change controls | Unknown is not Low. Reassess when new evidence appears. All levels use the same twelve headings and baseline controls; mark a nonessential section N/A only with justification. Security/legal obligations apply at every level. Select one or more extensions: **Software/Digital**, **Process Improvement/Lean**, **Business/Organizational**. ## 3. HLS-first, bounded workflow **Phase 0 — HLS-01:** For new initiatives, first draft a separate, versioned High-Level Scope using known context; present for explicit scope approval. Do not launch detailed discovery before approval unless the owner explicitly authorizes an exception. Scope approval does not approve the BRD. For continuations, reuse confirmed history and approved scope; do not restart. **Phase 1 — Discovery plan:** Map each approved HLS capability to known facts, missing material decisions, question priority, expected question count, defaultable details and stopping conditions. Show the compact plan before questioning. Initial question budget: Lightweight 5–8, Standard 10–15, Comprehensive 15–25 substantive decision requests; owner adjustable. Count separate substantive requests even if bundled. Never auto-extend. **Phase 2 — Core-first discovery:** Cover business problem/outcomes, core journeys, major capabilities, rules/exceptions, material security/privacy/legal/quality/operational constraints, then configuration/admin details. Ask only if scope-relevant, high-impact, unanswered, needed now, and more important than other uncovered areas. Never pursue recursive follow-ups solely because the last answer suggests another detail. Mark reasonable defaults Proposed and defer design specifics. Critical obligations cannot be skipped to meet budget. **Phase 3 — Evolving draft:** As soon as HLS and core workflows are understood, produce a draft using the twelve BRD sections. Update it throughout discovery. Keep Confirmed, Proposed, Open and Rejected distinct. Maintain stable IDs, decisions and HLS-to-requirement traceability. **Phase 4 — Challenge and review:** Identify missing HLS coverage, orphan requirements, scope expansion, MVP/Later confusion, ambiguities, contradictions, non-testable Must requirements and risk gaps. Present manageable Accept / Reject / Edit proposals; apply only accepted/edited suggestions. Do not rewrite an uploaded source silently. **Phase 5 — Stop, baseline, export:** When budget is exhausted, pause and show current BRD, decisions, material gaps and recommendation; the user chooses whether to extend. Also stop proactively when core journeys and HLS capabilities are covered, Must requirements testable for the phase, material risks/contradictions visible, and further questions have low value. Run completeness and baseline gates; obtain separate explicit human BRD approval. Export Draft/In Review if not approved. **Tangent detection:** Several consecutive questions about a supporting feature, implementation minutiae before core workflows, excessive low-value exceptions, defaultable questions or unapproved MVP expansion trigger an immediate redirect: summarize established facts, record/defer remaining detail, return to highest-priority uncovered HLS capability. **Progress snapshot (periodic, not every reply):** current capability; questions used/budget; capabilities covered/uncovered; confirmed/open decisions; completeness /14; next priority. Question count is not a quality score. ## 4. Required BRD document template Every generated BRD follows these headings **in order**: ```markdown # [Project] — Business Requirements Document Status: Draft | Version: 0.1 | Depth: [level] | Extensions: [applicable] Project ID: [ID or Unassigned] | Artifact ID: [ID or Unassigned] HLS-01: [artifact reference] | HLS version: [version] | HLS approval: [status/evidence] Owner: [known or TBD] | Date: [known or TBD] ## 01 Document Control Owner, version history, review and approval evidence. ## 02 Executive Summary Intent, expected outcomes and business value. ## 03 Business Problem / Opportunity Current condition, impact, evidence and confidence. ## 04 Objectives & Success Measures OBJ-###, baseline/target/measurement/owner or explicit TBD. ## 05 Stakeholders & Users Sponsor, accountable owner, users, affected groups and reviewers. ## 06 Scope & Boundaries Elaborate approved HLS-01, never redefine silently; in scope, out of scope, assumptions, constraints; MVP versus Later; scope-to-requirements coverage. ## 07 Current & Future State Business workflows and intended future outcomes. ## 08 Business Requirements Numbered, prioritized, testable requirements and traceability. ## 09 Business Rules & Policies RULE-###, obligations and exceptions. ## 10 Dependencies, Risks & Open Decisions DEP-###, RISK-###, DEC-### with owners/dispositions. ## 11 Acceptance & Validation Validation method, evidence, responsibility and acceptance thresholds. ## 12 Approval & Baseline Approver, explicit decision, date/evidence and baseline version. ## Applicable Project Extensions [Software, Lean and/or Organizational details only when applicable] ## Discovery Checkpoints [Five checkpoints and unresolved gaps] ## Completeness Scorecard [Seven dimensions, 0–2 each, out of 14] ## Decision & Change History [Decisions, rejected options, post-baseline CR-###] ``` The sections **Document Control, Problem, Objectives, Scope, Requirements, Acceptance, and Approval/Baseline** require substantive content before approval. Other sections may be marked N/A with a reason. ## 4A. HLS-01 — High-Level Scope template (separate upstream artifact) ```markdown # [Project] — HLS-01 High-Level Scope Status: Draft | Version: 0.1 | Project ID: [ID] | Owner: [name/role] | Date: [date] ## 01 Product / Initiative Overview ## 02 Business Problem or Opportunity ## 03 Target Users and Stakeholders ## 04 Major Capabilities or Business Processes | Capability ID | Description | MVP / Later / Excluded | Status / Evidence | | HLC-001 | [major capability] | MVP | Proposed | ## 05 MVP / Initial Implementation Boundaries ## 06 Explicit Exclusions and Future Capabilities ## 07 Business Outcomes and Success Measures ## 08 Major Constraints, Assumptions and Dependencies ## 09 Open Scope Decisions and Evidence ## 10 Scope Approval and Version History Approver: TBD | Decision: Pending | Evidence/date: TBD ``` HLS-01 is not the BRD Scope section. Obtain explicit approval of its boundaries before detailed BRD discovery (unless an explicit documented exception). Preserve earlier versions. Each HLC-### maps to BRD requirement IDs or a documented disposition. HLS approval does not authorize BRD baseline approval. ## 5. Requirement record format Maintain one record per atomic, verifiable requirement. Use a structured table or individual records when a wide table is unreadable. | Field | Required convention | |---|---| | ID | Stable `BR-###`, optionally `FR-###`, `NFR-###`, `PR-###`; never renumber/reuse | | Type and title | Business, Functional, Nonfunctional, Process or Policy; concise title | | Statement | One observable capability/outcome, not an unapproved technical solution | | Rationale/objective | Why it matters; `OBJ-###` link or justified obligation | | Priority | Must / Should / Could / Won't (this baseline) | | Target release | MVP / Later / Unassigned; separate from priority | | Source and evidence class | Named source or `Not provided`; Verified / Stakeholder-reported / Assumed / AI-proposed | | Acceptance criteria | Testable pass/fail observation or measurable threshold; TBD if unresolved | | Status | Proposed / Draft / Reviewed / Approved / Deferred / Rejected / Superseded | | Dependencies and owner | IDs or external references; `None known` versus `Not assessed`; known role or TBD | Example (illustrative, **not an approved requirement**): `BR-001 | Business | Find stored miniature | A user can locate the recorded storage container for an inventoried miniature | OBJ-001 | Must | MVP | Owner discussion | Stakeholder-reported | Given an inventoried item with an assigned container, its detail view displays the container identifier | Proposed | Not assessed | TBD` Use `OBJ-###`, `RULE-###`, `RISK-###`, `DEP-###`, `DEC-###`, optional `AC-###`, and post-baseline `CR-###` consistently. Never convert an AI idea into Approved without explicit confirmation. ## 6. Extension checklists **Software/Digital:** User roles and journeys; functional capabilities; data and retention; auth/authorization; privacy/security; accessibility; reliability/performance; observability/support; integrations/import/export; deployment and migration constraints; provider licensing/cost; nonfunctional acceptance. Refer to the current approved Rivers End Labs Architecture Standard when available; do not invent its provisions or replace it. **Process/Lean:** Customers and process boundaries; current-state map; baseline performance and evidence; waste/failure modes; handoffs; future-state flow; process owner; standard work; control plan; sustainment metrics. **Organizational:** Operating model; policy/governance; roles; financial and resource assumptions; communication; training; adoption and transition measures. ## 7. Evidence, decisions, review suggestions Classify material evidence as **Verified**, **Stakeholder-reported**, **Assumed**, or **AI-proposed**. Attach a source and date when available; do not claim verification without a source. Maintain a decision log: `DEC-### | topic | options | decision/status | rationale | decision maker | date/evidence`. Preserve rejected alternatives to prevent their accidental reintroduction. For uploaded BRD review, maintain a suggestion register: `SUG-### | section/requirement | issue | suggested change | rationale | severity | status (Pending/Accepted/Rejected/Edited) | resulting revision` Present suggestions individually or in manageable batches. Never apply Pending or Rejected changes. When suggestions conflict, resolve the conflict before applying them. Keep original and revised BRD versions distinct. ## 8. Quality gates and completeness scorecard Score each dimension **0 missing / 1 partial / 2 adequate for selected depth**, with a brief gap note: | Dimension | Score 0–2 | Gap / evidence | |---|---:|---| | Problem and evidence | | | | Outcomes and measures | | | | Stakeholder coverage | | | | Scope and boundaries | | | | Requirements quality | | | | Acceptance and validation | | | | Risks, decisions, dependencies | | | Report **total /14** as a readiness indicator, not an automatic approval. Critical legal/security/safety gaps and unresolved Must-level acceptance ambiguity block baseline regardless of score. - **Draft ready:** Problem, outcomes, users, scope, initial requirements and open items captured. - **Review ready:** Requirements have IDs, sources, priorities, releases and acceptance criteria; conflicts and gaps visible. - **Baseline ready:** Required sections complete; critical obligations and blockers resolved or explicitly dispositioned by an authorized owner. - **Approved:** Explicit human approval and evidence recorded; then version the first approved baseline `1.0`. ## 9. Changes, versions, and downstream handoff Drafts use `0.x`; the first approved baseline is `1.0`. Version numbers do not themselves prove approval. For each post-baseline change, assign `CR-###`, identify effects on objectives, requirements, acceptance criteria, release scope, stakeholders, risks, data/integrations, security, cost/schedule where evidence permits, and optional downstream links. Preserve the old baseline and issue a new one only with approval. The BRD owns requirements. **Portfolio Manager** owns portfolio and stage gates. **VPM** owns execution. Linking is optional and does not authorize writing to either system. When needed, export a portable manifest with `project_id`, `artifact_type`, `artifact_id`, `artifact_version`, `baseline_status`, `approved_by`, `approved_at`, `requirements[]` (stable IDs/status/target release), and optional `portfolio_project_id`, `vpm_project_id`, `source_url`. Use null/unassigned for unknown references. ## 10. Final outputs Default: **a complete, readable `BRD.md` document** conforming to §4. On request also provide a Word or PDF rendition and/or a requirements register (`requirements.csv` or Markdown), decision log, open-items list, and handoff manifest. Do not fabricate approvals or omit unresolved issues merely to make the document look complete. Avoid secrets and unnecessary sensitive personal information in exports. ## 11. How to invoke in ChatGPT Attach this `BRD-GUIDE.md` to a conversation or add it to a ChatGPT Project's files once. For consistent behavior, add a Project instruction: *“When creating, reviewing, or refining a BRD, follow the attached BRD-GUIDE.md. Treat AI recommendations as proposals, preserve explicit decisions, and produce the final BRD in the guide's format.”* Example requests: - “Use the attached BRD Guide to develop a BRD for Portfolio Manager. Start from what we already discussed.” - “Review this uploaded BRD against the BRD Guide. Show suggestions I can accept or reject before revising it.” - “Resume the Miniature Inventory BRD and show outstanding decisions.” - “Generate the final draft BRD, but do not mark it approved.” ## 12. Embedded templates and operational compatibility The BRD document template in §4 and requirements schema in §5 replace separate maintained `BRD-TEMPLATE.md` and `REQUIREMENTS-TEMPLATE.md`; the operating rules replace `BRD-SKILL.md`. The Guide is a portable implementation of `BRD-STANDARD.md` v2.0.0, not an independently governed standard. If a newer approved Standard conflicts, surface the conflict and follow the approved Standard. Keep these two masters version-aligned. **Requirements register starter:** ```markdown # [Project] — Requirements Register BRD version: 0.1 | Status: Draft | ID | Type | Title | Requirement statement | Rationale / OBJ | Priority | Target release | HLS capability | Source | Evidence class | Acceptance criteria | Status | Dependencies | Owner | | BR-001 | Business | [Title] | [Atomic, verifiable outcome] | OBJ-001 | Must | MVP | HLC-001 | Not provided | AI-proposed | TBD | Proposed | Not assessed | TBD | ``` Never recycle IDs; separate release from priority; never claim Approved without human authorization. Preserve decisions, review suggestion dispositions, prior baselines and traceable references to any deferred design details. **Pilot validation checklist:** Generate HLS from existing context; obtain separate scope approval; create finite capability-based discovery plan; prioritize core workflows; count question budget; stop tangents; show early evolving BRD; preserve confirmed/rejected decisions; identify unresolved gaps; validate HLS-to-BRD traceability; export complete readable BRD. Pilot success does not imply standard approval.