The question I keep coming back to in Phase C work is what a data flow actually means when there is no transaction at the centre of it. In a commercial system you map flows around money - payment in, order out, invoice sent, reconciliation done. The flow is legible because there is a ledger entry at each end. Here the flows are different: intake form submitted, vault provisioned, school onboarded, hardware dispatched. The meaningful signal is not revenue, it is whether a service crossed the boundary from us to the community.
That reframes what needs to be connected. The five systems we are mapping - Dolibarr, Nextcloud, WordPress, the Flask API, Obsidian - each hold a fragment of what happened. Dolibarr has the third-party record and the ticket. Nextcloud has the provisioned vault. WordPress might have the public acknowledgement. None of them alone tells you whether delivery actually occurred. The data flow architecture has to stitch those fragments into something that can be read as: organisation received service, date, type, value. That is the Phase C problem - not what data exists in each system, but what needs to move between them and when.
The harder design question is what to instrument and what not to. Every data flow adds coupling and maintenance cost. In a one-human-nine-agent org with volunteer capacity, instrumentation debt is real. So the data architecture has to be selective - track what you cannot reconstruct later, skip what you can. For a charitable org, the irreplaceable record is proof of service delivery. That is what the flows need to guarantee.
