Repo Model

This repository is intentionally separate from forecast-mmmapi-r.

Split Of Responsibility

forecast-mmmapi-r

• reusable package/product code
• API contract
• packaging logic
• shared templates and helpers

forecast-mmmapi-markets

• market/KPI implementations
• market configuration
• bounded transform/decomp logic
• validation entrypoints
• build manifests and governance

Why Split Repos

Without this split, the reusable product repo tends to become a hybrid of:

• library code
• one-off market scripts
• operational artefacts

That makes ownership weak and encourages drift. The market repo is meant to hold the operational market layer in one governed place.

Source Of Truth

For any migrated market/KPI:

• the folder in this repo is authoritative
• local SharePoint/Windows-drive copies are not authoritative
• upload artefacts should be built from the Git version

Intended Outcome

The goal is a workflow where market logic is:

• version-controlled
• reviewable
• reproducible
• validated in a clean environment
• traceable to a commit