Mock Data Policy

Principle

Mock data must never reach production users. It exists only to support development and testing workflows.

Where Mock Data Is Allowed

Test fixtures (tests/ directories)

Always acceptable. Test fixtures in tests/, fixtures/, conftest.py, etc. are properly scoped and pose no production risk.

Local development

Acceptable only if the mock module is excluded from production builds. Use build-time gating (e.g. Vite conditional imports, import.meta.env.DEV guards, separate dev-only entry points) so mock code is tree-shaken from production bundles.

Preview/prototype deployments

Acceptable when the ticket is labelled prototype. Prototype tickets have a modified DoD (see below).

Where Mock Data Is NOT Allowed

Production builds

Never. Mock data must not appear in production JS bundles, API responses, or database state.

Staging

Never. Staging must mirror the production data pipeline to catch integration issues.

Numbered migrations

Seed data should be a separate, non-default operation (e.g. a seed task or script), not a numbered migration that runs automatically in all environments.

Definition of Done — Mock Data Checklist

Standard tickets

• No mock data in production bundle — verify with build output analysis or code search
• No unconditional imports of mock modules in production-path code
• API clients must fail visibly (error state) when the backend is unavailable, not fall back to mock data

Prototype tickets (labelled prototype)

• Deployed to a preview environment for board signoff
• Follow-up ticket created to replace mock data with real data before staging promotion
• The follow-up ticket is linked as a blocker for staging deployment

Enforcement

• Code reviewers must check for mock imports in production-path files
• CI can optionally enforce via a build-size or import-graph check
• Any mock data found in production-path code during review is a blocking finding