Running ICM as a company's shared know-how — where the context tree is also the ISO-audited procedure manual

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.

Why this is the point: the KB becomes the engine of continual improvement — the thing ISO 9001 explicitly asks for (clause 10) and that most companies fake with an annual review. Here it's structural, not ceremonial: the people doing the work are the sensors, improvements flow in continuously, and they land in an orderly, approved, traceable way. Enforcement and evolution in the same loop. The context tree stops being personal working memory and becomes the company's governed institutional memory — agent-driven, improved by everyone, in order.

I'm still working two things out, and I'd value input from anyone who's taken a QMS through a real audit: how to keep frictionless approval from sliding into rubber-stamping, and whether Git is the right primitive for non-technical change requests or just the one I happen to know. But the core feels right.

25 comments

Running ICM as a company's shared know-how — where the context tree is also the ISO-audited procedure manual