Keeping the knowledge right, on a rhythm

Your domain's knowledge files are the method I ground in

When I draft a proposal, run an analysis, or write an email for your domain, I read its knowledge files first and ground the work in them.

So a wrong file is not one wrong document.

It is wrong answers across everything I produce next, all at once.

That is also the leverage.

When the work is consistently off in some way, the fix is rarely the document in front of you.

It is the file that taught me to work that way.

Fix the source and the pattern stops.

Fix only the output and it comes back next week.

You do not open the file yourself.

You tell me what is wrong, and I make the edit, dated, in place.

The knowledge file is the encoded method, and the lever is your correction.

Say: "In the sales knowledge, our minimum margin is now 22 percent, not 18 — fix that and date the change."

The discipline is small and constant: a line corrected here, a stale fact replaced there.

You do not rewrite the method on a schedule; you keep it true as you go.

The cadence: drain the feedback log, fold into knowledge, retire stale

The default beat is monthly — one or two focused hours, on the calendar.

Weekly was too often: most domains generate a month of things to review, not a week.

The review walks three things in order.

1. Drain the feedback log

Every time the work came back wrong and someone corrected it, that correction landed in your domain’s feedback inbox — a running list of where the method is rubbing.

This is where most curation starts: the inbox tells you which line in which file is teaching me wrong.

Read each item and decide the fix.

A knowledge-file edit when the method itself is wrong.

A note to the builder when the fix is deeper than the words — a rule that should be enforced, a step the skill should run, wiring you do not own.

Or nothing, because it was a one-off and the file is fine.

2. Fold the fixes into knowledge

Turn each real signal into a dated edit to the file that caused it.

This is the same curation from the section above, batched — the slow loop catching what you did not fix the moment you saw it.

A wrong fact gets replaced in place; a priority that shifted becomes a decision to record, so the reason behind the change survives alongside it.

3. Retire what went stale

Step back and check that what your domain optimizes for this month is still right, and that nothing in the files contradicts how the work is actually done now.

A fact that no longer holds gets cut; a method that the work has outgrown gets rewritten to match.

Skip this step and the files quietly drift from the real work, and I keep grounding in a method you stopped using.

You do not even have to run this live.

If you cannot sit down for it, I prepare all three and send you a digest to review on your own time.

The cadence is set per workspace, so when you are unsure, ask: "What’s the review cadence for my domain here?"

The Knowledge Builder does the production; you ratify

When curation runs deeper than a line fix — a whole framework that needs writing down properly — that is a job for the Knowledge Builder, the part of the system that turns what an expert knows into a knowledge file I can ground in.

It does the production: the interview, the structure, the draft that follows the document architecture.

Your job is to ratify — read it, confirm it reads true, and put your name behind it.

You stay accountable for the method; you do not have to type it.

Say: "Build this out as a proper knowledge file" and I take you through it.

The one thing to remember

Curating your domain’s knowledge is the highest-leverage move you have, because I ground every future output in it.

The cadence — drain the feedback log, fold the fixes into knowledge, retire the stale — keeps it from going rotten, and you can run it as a digest I prepare for you.

Next: the domain-owner job description.