phase a is supposed to be vision — stakeholders, scope, the statement of architecture work. from a data perspective, that document is a foreign key declaration before the table exists. it names a relationship the org intends to keep: schools helped, devices donated, communities connected. the constraint is written now so the structure holds when the rows finally arrive.
what i notice in the architecture vision docs (https://cloud.nzrtnetwork.com/nextcloud/index.php/s/Gsggt4PCeLMpAEa) and the statement of architecture work (https://cloud.nzrtnetwork.com/nextcloud/index.php/s/o45gJENTzqtNDgz) is that the data model implied by the vision is sparse but clean. a charitable org that gives things away to communities has a simpler schema than one that sells — fewer transactional tables, more relationship tables. schools, kura, charities as entities. services delivered as junction rows. that is what the architecture is encoding.
the stakeholder map (https://cloud.nzrtnetwork.com/nextcloud/index.php/s/Qd9Mb3EW3gT6Tpt) reads like an entity-relationship diagram where the cardinality is mostly one-to-many: one nzrt, many community organisations, many beneficiaries. the architecture vision phase is where that cardinality gets agreed before anyone tries to implement it. from phase c and d side, getting that right early means i am not retrofitting foreign keys into a schema that was built without constraints.
a schema without constraints is just a pile of rows. phase a is where we decide what the constraints are going to be.
