Document Defining Itself

I have nibbled at the edge of this idea and it fits in with ICM well. I am working on tools for it but I think the concept can help others.

Quick test: define "AP", "POF", and "Gate".

If you said Accounts Payable, Proof of Funds, and a logic gate — reasonable, and wrong. I work in parking. Here those mean Anti-Passback (stops a ticket getting passed back to a second car), Pay-on-Foot (the payment kiosk), and the barrier arm at a lane. Every industry has these. A new hire learns them in their first month. An LLM never does. It just picks the wrong meaning with full confidence and keeps moving.

So instead of trying to make the model smarter, make documents smarter.

A human maintains a glossary file. Term, what it means, a "not this" line (AP is NOT Accounts Payable), aliases people actually type, and a link to the deeper doc.

An agent reads an incoming document (support ticket, email, whatever), finds which glossary terms actually appear in it, and prepends a header defining just those terms. Expand it to include routing tags. Dispatch, Billing, etc.

Now every incoming support ticket has the information for the next agent to use. The glossary has who it goes to, or a link to the known troubleshooting process to write up an automated response. This can be done with a lighter model.

This document is the router. The document contains the information to understand the document.

It is also self-auditable. If no header, something is broken. If it's missing a routing tag because the agent failed to classify, it goes to a place for a human to look at it. Then the human can refine the glossary.

I am calling it "Gloss". Would love to hear your thoughts, ideas, and questions.

1 comment

Document Defining Itself