Should the agent be allowed to propose changes to relationships, or only to values?

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?"

Agent : "Person A." ✅ it can read the edge

Me : "Person A is overloaded. Move it to Person B."

Agent : "I can't propose that." ❌ it can't touch the edge

The agent can see the graph. It cannot tell me the graph is wrong. And an ownership pointer that has gone stale is exactly the schema drift the skill warns about — "update the schema or the files — pick one."

I see three ways out:

A — Keep the block. Ownership is set through the interface only. Simple, but the agent reads a graph it can never correct, and I end up going around my own gate to fix it.

B — Add an exception for this one field. I already have one special-case branch in my proposal handler for a different non-scalar case. I could add a second. It works — but Remove-The-Complexity asks me to "state the specific reason" for any separate path, "if you cannot state one, recommend cutting it." I would then have two, and the third is only a matter of time.

C — Remove the rule instead of exempting it. Let a relationship be proposable when it resolves deterministically: the agent proposes an address that already exists, the system resolves it, never creates it, and refuses the proposal if the resolution is ambiguous. One path, one more field, no special case. The determinism sits at the access point, which is where L3 puts it — "the action itself is deterministic (no AI interpretation)."

C feels right because it adds a capability by subtracting a rule rather than adding a branch. But I want to know if I am rationalising.

---

The questions

1. Is "scalar vs relationship" a legitimate permission boundary in an ICM, or is it an implementation artefact I imported into my governance layer without noticing? I cannot find anything in the material that draws this line, but absence of a rule is not the same as permission to ignore it.

2. When the agent proposes an edge, what should the gate actually show me? A value change is easy to review — old string, new string. An edge change is a claim about the shape of the graph. Does that deserve a different review surface, or am I overthinking a field that happens to be a pointer?

3. On invariant 6 — "a human can open, edit, and save." My gate is approve/decline. The verb in the invariant is edit. Today, if a proposal is 90% right, I throw away 100% of it and redo the work by hand. Has anyone here made their gate editable rather than binary, and did it change how much you trust the agent to propose in the first place?

4. For those running a generated catalog: where do you draw the line between what the agent may propose and what stays human-only? I have landed on addresses are untouchable, descriptions are proposable — identifiers versus attributes. Does that hold up in practice, or does it break the first time an identifier is also meaningful?

It is a very long question but a very significant one for my system with HUMAN GATE

@Jake Van Clief

it is a technical and methodology

----- My question in 1 sentence :

0 comments

Should the agent be allowed to propose changes to relationships, or only to values?