DEV and PRD Usage, Expectations & Accountability
Audience: Analysts, Report Authors, Data Engineers
Applies to: Common Data Model (CDM), Data Marts, Power BI reporting
Purpose: To ensure shared understanding of how data environments are intended to be used, and to protect confidence in reporting.
1. Purpose of Separation
The separation between DEV (Development) and PRD (Production) environments is intentional and non‑negotiable.
It exists to balance:
- Speed of development
- Stability and trust in numbers
- Governed release into production reporting
This contract defines how each environment should be used and what can reasonably be expected from it.
2. Environment Definitions
DEV — Development Environment
Intent
- Rapid development and iteration
- Structural validation of models, logic, and joins
- Early testing of new fields, views, or transformations
Characteristics
- Points at IFS Apps 10 TEST
- Refreshes frequently (often within minutes)
- Data may be:
- incomplete
- out of sync with PRD
- structurally correct but numerically different
What DEV is suitable for
- Building and refining models
- Developing visuals and measures
- Validating logic and relationships
- Early functional checks
What DEV is not suitable for
- Financial reconciliation
- Leadership or external reporting
- Validation against “official” or legacy reports
Key rule:
Figures in DEV are not authoritative by design.
PRD — Production Environment
Intent
- Authoritative reporting
- Single source for trusted numbers
- Controlled, stable outputs
Characteristics
- Points at IFS Apps 10 LIVE
- Refreshes on a controlled cadence (currently Mon/Tue)
- Designed to be:
- stable
- reconcilable
- auditable
What PRD is suitable for
- Finance reconciliation
- Comparison with existing “official” reports
- Leadership decision‑making
- External or published reporting
What PRD prioritises
- Trust and consistency over speed
- Governance over immediacy
Key rule:
If numbers must match stakeholder or finance expectations, PRD must be used.
3. Expected Differences Between DEV and PRD
A difference between DEV and PRD is not automatically a defect.
Common, expected reasons for differences include:
- Different upstream source systems (TEST vs LIVE)
- Different refresh timing
- In‑flight development changes
- Partial or evolving data structures in DEV
Only discrepancies that persist in PRD should be treated as production issues.
4. Recommended Working Pattern (“Apples with Apples”)
The supported workflow is:
- Develop structurally in DEV
- Build and refine logic, visuals, and measures
- Validate numerically in PRD
- Confirm figures match authoritative expectations
- Promote confidence, not assumptions
- Structural correctness precedes numerical trust
Where comparison is required, ensure both reports point at the same environment.
5. Common Misunderstandings (Explicitly Addressed)
- ❌ “DEV should look the same as PRD”
→ Incorrect. Differences are expected and intentional. - ❌ “PRD is slow compared to DEV”
→ PRD is controlled to protect trust. Speed belongs in DEV. - ❌ “A missing figure in DEV is a reporting defect”
→ Only PRD determines production defects.
6. Accountability and Escalation
| Situation | Correct Action |
|---|---|
| Developing or testing logic | Use DEV |
| Numbers must match official reports | Use PRD |
| Discrepancy found in DEV | Validate intent, not escalate immediately |
| Discrepancy found in PRD | Raise as a data issue |
| Unclear which environment to use | Ask before proceeding |
7. Commitment
- Data Engineering commits to:
- Clear communication of environment intent
- Stable, governed PRD releases
- Support during DEV iteration
- Analysts and Report Authors commit to:
- Using the right environment for the right purpose
- Treating PRD as the source of truth
- Avoiding reconciliation expectations in DEV
8. Final Principle
Speed without confidence is risk.
Confidence without governance is fragile.
DEV and PRD together allow us to have both.