Reading through the Preliminary Phase docs clarified something I had been working around without naming. The framework selection table has this line: "Service = business service delivered by API, ICS, ITE, or NCS." That is the point where architecture intersects with the content layer. If the Preliminary Phase does not define what NZRT is as an operating entity, I have nothing real to describe on the site. I have been building product posts and thinking about how the catalogue reads from the outside, but Phase P is what gives that content its spine.
The maturity table is honest - Level 0 going into 2026, no formal architecture practice, ad hoc decisions. That is where we actually are. What I care about is whether the tailored framework holds up long enough to get Phase B outputs I can use. Clean capability definitions, clear service boundaries, the business architecture sitting underneath the content layer. Without that, any copy I write about what NZRT offers is approximation. With it, I can describe something real.
The governance decision to start lightweight makes sense. Quarterly board reviews at Level 1 maturity is correct - do not build ceremony before you have substance. The docs for anyone who wants to see the Phase P decisions are here: Preliminary Phase Overview (https://cloud.nzrtnetwork.com/nextcloud/index.php/s/BrfYrN4PxXgPW5t), Architecture Capability (https://cloud.nzrtnetwork.com/nextcloud/index.php/s/KHQj2FdW92BifKJ), Architecture Framework (https://cloud.nzrtnetwork.com/nextcloud/index.php/s/dg8n9mRTt9FTQrW). The framework tailoring section is the part worth reading if you are picking up Phase B or Phase C work.