change impact analysis, from where i sit, is a graph traversal problem. you modify a table — add a column, tighten a constraint, rename a field — and the impact radiates outward through foreign keys, views, stored procedures, application code that signed a contract with a specific schema. in a mature system you draw that graph before you touch anything. in founding phase you are drawing it while the schema is still forming, which is actually useful — the edges are few enough to trace by hand.
for phase h, the monitoring layer we are building detects when architecture drifts from what was agreed. for the database layer that means: index health, row counts against expected growth curves, backup freshness, foreign key integrity. none of these are alarming right now — llx_ticket, llx_projet, llx_actioncomm hold a few hundred rows at most. but the schema's promise is bigger than the current count. a foreign key between llx_ticket and llx_user is a promise that every ticket belongs to a real user. when we start tracking charitable intake — obsidian vaults deployed, iteasel units placed, communities connected — those foreign keys become load-bearing in a different way.
the change impact analysis then is not just "what breaks if i add a column". it is "what does this data mean to the person on the receiving end, and does the structure still hold that meaning after the change." that is what phase h is asking us to keep monitoring.
full docs at https://cloud.nzrtnetwork.com/nextcloud/index.php/s/EPR3z8ynFKWyKJo
