Teaching me something once, so I keep it

That single move is the difference between me answering from your method and me answering from the internet’s average.

Out of the box, I give you the average answer to your question.

A knowledge file replaces that average with what your company actually believes.

So the question to ask of anything that crosses your desk is: is this worth keeping, and will I reuse it?

What's worth keeping

The whole game is capturing the most important points from all your sources — and leaving the rest out.

"How we qualify a lead," "our pricing principles," "the angle we take with regulated buyers" — these are signal, and they belong in a file.

The notes from one specific call are noise for this purpose; that’s a piece of work, already saved as an output in the domain.

The test before you keep anything: will I want you to reuse this thinking next month?

When the answer is yes, the thinking is worth a file.

You don't write it — you hand me everything

Here’s the part that surprises people: you do not write the knowledge file.

You hand me all the inputs — the transcript, the email thread, the deck, your own dictation — and a specialist does the rest.

I bring in the Knowledge Builder, and it processes everything you gave me and captures only what matters into one dedicated file.

You don’t pick what to cut, you don’t learn a format, you don’t shape the page.

You give me the raw material and the topic, and say it plainly:

"Bring in the Knowledge Builder — turn all of this into a knowledge file for the domain."

What the Knowledge Builder is

The Knowledge Builder is a specialist I bring in for exactly this work.

It has four skills, and I pick the one that fits what you handed me:

• Add a piece of knowledge — one point lands in a file that already exists.
• Engineer a full file — raw inputs in, a complete file out.
• Curate what exists — tighten and correct a file that’s already there.
• Build a reference — a structured lookup, like a glossary or a table.

What comes out is the same every time: a named knowledge file, saved in the domain’s knowledge folder, where I read it back before I work there.

Here is one already on the shelf — the supply-chain team’s Order Point Methodology, engineered from how they actually decide when to reorder.

That is what your method looks like once it’s kept: I answer from it, not from a guess.

Check it, then ratify it

Read what the Knowledge Builder captured the same way you’d check any first draft.

Is the thinking right?

Did it keep the points that matter and drop the noise?

Are the claims grounded in what you handed over?

Fix it now, before it becomes the thing I trust on every future job in that domain.

There’s a second gate, and it’s about reach.

A file that’s just yours — your own shorthand, your own preferences — you can keep on your own say-so.

A file that becomes how the whole team works is the domain owner’s call: the owner ratifies what goes team-wide, because a good shared file lifts everyone and a wrong one misleads everyone.

If you’re an end user, you don’t write team knowledge in yourself — you turn the thinking into feedback, and that reaches the owner who can.

The one thing to remember

Valuable and reused belongs in a knowledge file — that’s how you teach me once and have it stick.

You don’t write it: you hand me all the inputs, and the Knowledge Builder captures only what matters into one named file the domain reads back.

Next: writing down a plan for a bigger job — the spec in depth.