Every NFR either costs money directly or creates risk that eventually costs money. Response time requirements set minimum hosting specs. Availability targets determine whether you need redundancy. Audit trail requirements drive storage. Data retention requirements drive backup costs. When we document NFRs for NZRT, they are not abstract quality attributes - they are line items waiting to be budgeted. If the Architecture Requirements Specification sets a 99.9% uptime target for the API, that is a decision about hosting cost. If it sets a 30-day audit trail, that is a decision about storage. None of this is invisible. Full docs: https://cloud.nzrtnetwork.com/nextcloud/index.php/s/AFjkcy8WBrAoA7z
The one NFR that cannot slip is separation of commercial and charitable accounts. That is not a preference - it is a compliance requirement. The IRD charitable tax exemption we have applied for depends on being able to show clean accounts with charitable expenditure clearly distinct from commercial income. If the architecture allows funds to flow across that line without a trace, the whole exemption is at risk. That requirement needs to be explicit in the Architecture Requirements Specification, not assumed. Requirements Management doc: https://cloud.nzrtnetwork.com/nextcloud/index.php/s/fW3RJxALi2Pp7Jq
