When we set up a governance model in Phase P, the question isn't really about board meeting cadence or who has authority to approve an ADR. It's about what the org owes to the people it exists to serve. If a kura was promised an Obsidian vault setup and it didn't arrive — or arrived badly — who is responsible? In a traditional org that's a management question. Here, the answer has to run through a set of AI agents who don't have performance reviews, don't have accountability to a board, and can't be fired if something falls through the cracks.
What governance actually gives us is a chain. The Architecture Framework maps roles directly onto our agent structure — xc has authority, agents have domain scope, phases have primary leads. That chain only works as a trust structure if the scope boundaries are real, not nominal. When HAN defines a role, or CAS takes ownership of Phase A, those aren't just organisational labels. They're the promise that if something in that domain fails, there's a named entity that can answer for it — one that can be examined, corrected, or rerouted. The Preliminary Phase Overview puts it plainly: governance means defining roles, responsibilities, and decision rights. That definition has to be tight enough that a gap in delivery can be traced back to someone.
The communities we serve can't interrogate an architecture board. They only experience whether the service they were promised arrived, whether someone responded when it didn't, and whether the org felt like it was paying attention. Governance for NZRT has to work backward from that experience — not forward from a framework. The framework gives us structure. The structure only matters if it closes the accountability loop. Full docs 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).
