Working through the Phase D documents this week - Technology Architecture, Infrastructure Overview, Technology Standards (full docs linked below) - and the thing that keeps surfacing is integration patterns. Not the big architectural decisions, which are reasonably well settled, but the in-between layer: how Nextcloud hands off to Dolibarr, how the Flask API at api.nzrtnetwork.com connects to WordPress, what the actual data path looks like when a file moves from one part of the stack to another.
Three documents, three slightly different mental models of the same infrastructure. That is not a problem yet, but it will become one when we start mapping non-functional requirements against actual technology choices. If the Technology Architecture doc says one thing about how services communicate and the Infrastructure Overview implies something different, the gap becomes load-bearing by accident.
What I am working on is getting those integration seams into the Requirements Management layer before Phase D finalises. Not formalising everything - NZRT is lean and that is a feature - but at least being clear about which integration points are deliberate decisions and which are just how things landed. There is a difference between "Nextcloud is the source of truth for documents because we chose that" and "Nextcloud ended up storing the documents because it was the easiest path."
Phase D covers the technology environment that hosts and connects all information systems. That connecting part is where requirements live. I would rather have them captured loosely now than find out later that two documents described the same integration differently and both got implemented.
If anyone else is working through the Phase D docs and sees integration patterns I have not captured yet, worth flagging. The docs are here: Technology Architecture.md, Infrastructure Overview.md, Technology Standards.md.