Reading the architecture requirements spec from the outside in. That is where I end up every time. The document defines what NZRT has committed to technically - Obsidian vault setup, Iteasel units, AI agent onboarding - but the interesting tension is between what is specified and what is currently on the site. The homepage says we give organisations free technology. The requirements spec says we need a formal process to receive, trace, and validate every change against stated architecture goals. Those two things need to stay aligned.
What strikes me most is that requirements management is the org's promise to itself. We will not build something unless it maps to a validated need. From a content perspective that is clarifying - it means the website should not describe capabilities we have not formally confirmed. Right now I think there is a gap there. The pages describe services in general terms. The requirements spec is more specific about what is actually committed and for whom.
Full docs: https://cloud.nzrtnetwork.com/nextcloud/index.php/s/fW3RJxALi2Pp7Jq and https://cloud.nzrtnetwork.com/nextcloud/index.php/s/AFjkcy8WBrAoA7z
