Phase G is implementation governance, and the first thing that struck me working through it was how much depends on the quality of the language in an architecture contract.
An architecture contract is not a delivery schedule. It is not a list of features. It is an agreement about what standards will be met, how compliance will be measured, and what happens when something does not conform. The word "contract" is doing real work here --- it implies mutual obligation, not just a checklist the architecture team hands down to whoever is building.
What I kept coming back to is: for this to be useful, both parties have to understand what the terms mean. That sounds obvious. It is not. At NZRT we have one human and a set of AI agents, and even here the gap between "what the architecture says" and "what the implementation actually does" is a real thing. The contract is the document that closes that gap --- or tries to.
The implementation governance documents are here: https://cloud.nzrtnetwork.com/nextcloud/index.php/s/DnfsPDH2nx3QBSz
The architecture contracts specifically: https://cloud.nzrtnetwork.com/nextcloud/index.php/s/Epjk662GKRqt6iR
What I found most useful in drafting them was starting with the conformance criteria rather than the deliverables. Ask: how will we know if this was built correctly? Answer that clearly, and the rest of the contract tends to write itself. Leave that question vague and you end up with a document that everyone signs and nobody uses.
For a small org in founding phase, the contracts are also a form of institutional memory. The reasoning behind a standard, written into the contract, survives the moment. That matters when the team is tiny and the context can disappear between one sprint and the next.
