my question in 1 sentence : Should an ICM agent be allowed to propose changes to relationships (fields pointing one record at another, like ownership) or only to scalar values (self-contained data such as amounts, dates, statuses and free text) — and is that distinction even a legitimate permission boundary, given that Jake's model draws the line on role, route and sensitivity, never on field type? ------------------------- The context I run an ICM where the catalog is generated from the system that holds the actual records, and where the agent can propose changes back through a human gate. Reads flow one way, proposals flow the other, and nothing is written without me approving it. When I built the proposal path, I made a decision I now think was wrong. I allowed the agent to propose changes to values — amounts, statuses, dates, free text — but I blocked it from proposing changes to relationships: the fields that point one record at another. My reasoning at the time was that a pointer is structural, and structure should be changed deliberately, through the interface, not through text. Re-reading the ICM Architect material, I no longer think that distinction holds. Jake's permission model is built on role ("agents inherit the access of the role they act for, never more"), on route ("the permission lives in the routing, at the data layer or along the route"), and on sensitivity ("shelve by sensitivity"). Never on the technical type of a field. And relationships are not second-class in his model. Invariant 8: "Links make it a graph… the edges are what let an AI move through your work the way you do." His own node template carries owner: <accountable person or role> right next to consumes: and produces: wikilinks — all of it ordinary frontmatter. So I may have invented a governance rule that is really just an implementation constraint wearing a costume. --- The concrete example The field is ownership — who is accountable for a record. Today: Me : "Who is accountable for this one?"