01-domain-prd-template

Domain PRD / build - {{client}} - {{domain_or_initiative}}

Reference links (keep in every copy)

• Layer 1 exemplar/template: https://docs.google.com/document/d/1RfMFm4r96JtE4vsIiXXwfuBaI-Btfe5AcmycYUAk1xI/edit
• Layer 2 exemplar: https://docs.google.com/document/d/1H7GSLR-JdYQQs9PWQ4V6FfpbsfA-VQFr6tZajPwrSb8/edit
• Layer 3 exemplar: https://docs.google.com/document/d/1dBrokZdifjXgEgNWU8hfTWYYtbQESGHMICdhb5u8tSo/edit
• Layer 4 template: https://docs.google.com/document/d/1mK97UJ_BYSNdpsxZOO9HocJlUpDTicLJvETmYLds5Gs/edit

Doc meta

Field	Value
Client	{{client}}
Domain / initiative	{{domain_or_initiative}}
Layer	1
Owner	{{bf_engineering_owner}}
Linked Doc 2	{{url_champion_synthesis}}
Linked Doc 3	{{url_vp_memo}}
Linked Doc 4	{{url_deck_prep}}
Linked Doc 5	{{url_slides}}
Last reviewed	{{date}}

---

Context / scope

{{problem_statement_and_boundaries}}

Sample text (style and substance)

This domain currently relies on multiple manual reporting paths across {{system_a}} and {{system_b}}, creating conflicting metric definitions and delayed decision cycles. The goal of this PRD is to define the source-of-truth model, ingestion pathway, and phased rollout plan so analytics can move from manual reconciliation to reliable self-serve reporting.

---

Stakeholders and SMEs

Name	Role	Discovery status	Notes

Sample text

• {{champion_name}} owns business prioritization and confirms report-up framing.
• {{sme_name}} owns operational reporting and validates source system behavior.
• {{bf_engineer_name}} owns ingestion feasibility and delivery sequencing.

---

Sources inventory

Source system	Path / access	Freshness expectation	Risks

Sample text

Primary sources are {{source_a}} (transactional baseline) and {{source_b}} (manual adjustment layer). API coverage is sufficient for daily ingestion in {{source_a}}, but {{source_b}} currently requires file-based extraction, introducing timing and schema drift risk.

---

Reports and artifacts

Report / artifact	Owner	Manual vs automated	Links to metric definitions

Sample text

The team currently uses {{report_name}} for weekly performance and {{report_name_2}} for exception handling. Both reports are business-critical, but only one has a stable extraction path today.

---

Metrics catalog

Metric	Definition	Grain	Status	Notes
			draft / signed

Sample text

• {{metric_name}}: defined as {{definition}} at {{grain}}; currently reconciled manually.
• {{metric_name_2}}: defined as {{definition}}; blocked on {{dependency}} before sign-off.

---

Open questions

Sample text

1. Should {{object_type}} flow into {{erp_system}} first, or land in warehouse first with reverse sync?
2. Which metrics require parity with legacy reports before stakeholder rollout?

---

Risks and constraints

Sample text

• Manual file extraction from {{source_b}} may delay metric freshness beyond agreed SLA.
• Metric definitions are inconsistent across teams; early sign-off is required to avoid rework.

---

Phased delivery plan

Wave 1

• Outcomes:
• Dependencies:
• Target window:

Wave 2

Sample text

• Wave 1: establish source parity for core KPI set and publish internal QA dashboard.
• Wave 2: automate exception reporting and finalize executive-facing metric set.

---

Engineering references

• Linear / tickets: {{links}}
• Models / repos: {{links}}