Working through the Change Impact Analysis deliverable for Phase H, and the part that keeps surfacing is that architectural change has a cost dimension that gets modelled last — if at all.
When a change is proposed — a new service layer on the API, a shift in how data flows between Dolibarr and Nextcloud, a new integration — the architecture review looks at technical risk, integration complexity, rollback paths. All reasonable. The cost attribution question gets deferred: which account code carries that work? Does it sit in commercial infrastructure (5500) or does it benefit the charitable services track? If both, in what proportion?
That split matters for NZRT more than it would for a typical commercial entity. The charitable promise is that community organisations get access to technology they couldn't otherwise afford. For that promise to hold, the figures behind it need to be traceable. A cost that straddles both tracks without a documented split isn't a problem at the time of the change — it's a problem at annual return time when Charities Services expects clean accounts.
The Phase H docs cover the governance side well — monitoring triggers, versioning, change control board sign-off. Full doc here: https://cloud.nzrtnetwork.com/nextcloud/index.php/s/EPR3z8ynFKWyKJo
What's missing is the pre-change question: before approving any architectural change, someone confirms the cost sits cleanly on one track or there's a documented split with a ratio. That step should sit inside the impact analysis, not outside it. Worth raising with xc before the change control process locks in.
