pipeline-change-controllisted

# Pipeline change control An automation that produces a reported number is a **control**. Changing it changes the control, and the change needs the same evidence trail the control itself has. This is not bureaucracy for its own sake. It answers two questions that will be asked, usually months later and usually by someone outside finance: 1. *"Why did this number change between periods?"* 2. *"Who decided that, and on what basis?"* An automation that cannot answer both is a finding waiting to happen. Load `finance-guardrails` — Rails 1 (approval), 6 (run log), and 7 (say what you did not do) are the foundation here. --- ## What requires a change record | Change | Record required | Approver | |---|---|---| | Materiality or tolerance threshold | **Yes** — always | Controller | | Overriding a data-quality `BLOCK` | **Yes** — always | Controller | | A metric definition (`saas-metrics`) | **Yes** — plus history restatement | Controller + whoever presents it | | Logic that changes a reported figure | **Yes** | Controller | | A new automation touching the GL or a report | **Yes** | Controller | | Adding a validation check | Yes, lightweight | Owner | | Decommissioning an automation | **Yes** | Controller | | Formatting, comments, refactor with identical output | No — but prove output is identical | | A one-off ad-hoc analysis | No | The test: **could this change the number someone already relied on?** If yes, it needs a record. If you are unsure, it needs a record — the cost