Curious how others are handling file links in ICM-style workspaces, especially if you’re also using Obsidian for visual navigation. I’ve been trying to keep links functional instead of decorative. My current pattern is: - Index = where this file primarily belongs - Links = closely related files worth navigating with it - Source Of Truth / Pointer / Route To = operational links, not just visual links - Avoid inter-linking every mentioned file, because the graph gets noisy fast - Only add links when they help with routing, ownership, review, or resume context So the goal is not “maximum backlinks.” We want a graph that shows how the workspace actually operates. As I see it: Obsidian rewards dense linking visually, but ICM rewards narrow context loading. Too many links can make the graph pretty but semantically weak. How are you all deciding what deserves a link vs what should stay plain text?

My mum works in corporate America and is stretched thin. Spreadsheet analysis she has to run manually, a constant pile of emails to draft, life admin on top. She also maps out her processes with mind maps and flowcharts already - the raw material for a second brain is there. The use cases are obvious. She just needs the cognitive load cut. The plan is to wrap her an ICM system she can actually use - one interface on her Claude Enterprise subscription, so she doesn't have to think about what's underneath. I'm 18, built this for myself, and I'm starting to look at consulting for local businesses. This is the first test of translating what I know into something that works for someone else. The scoping process I'll sit with Claude and design the approach. What I'm after is the specific stuff: what would you actually tell someone [me] doing this for the first time with a non-technical user who's already process-minded?

Most ICM setups I see here are single-operator: one person, one agent, one context tree that's basically externalized working memory. We're running it differently — as the shared know-how of a small engineering firm (~15 people: industrial automation, control-panel building, light EPC). That one shift, from personal to organizational, changes the whole problem. In a company, the context isn't just my memory — it's the procedures everyone has to follow, and procedures have to be governed, auditable, and improvable by people who will never open a terminal. Here's the core of what we've landed on. One markdown source, three readers. The ICM KB — plain markdown in GitHub — is at the same time: - the agent's operating context (what it reads to act: load costs into the ERP, build quotes, enforce the process); - the company's procedure manual, rendered into a navigable wiki — search, cross-links, the graph of how procedures interconnect — which is what employees actually read; - the ISO 9001 controlled-document system, because Git already is change control: versioned, attributed, diffed, immutable — stronger than the Word-on-a-shared-drive most small firms limp along with. No parallel copies, so nothing drifts. Git is the evidence vault; the wiki is the auditor's reading room. (Worth stating for this crowd: ISO 9001 mandates control — identification, approval, versioning, availability of the current version — it mandates no specific format. A git-backed static site clears that bar cleanly.) The agent is the abstraction layer — this is what makes it survive in a company of non-technical people. Nobody learns markdown, Git, or pull requests. They talk. The agent enforces the current procedure while they work; and when someone says "step 3 is wrong, we do Z now," it turns that into a proposed change to the controlled document. The quality lead gets a plain-language summary and approves or rejects. Proposing is frictionless and open to everyone; approving is a controlled human gate. The Git/PR machinery stays invisible underneath.