I compressed 285 rows of written rules into a 12-page rulebook. Then I put 5 documents above it.
Those 5 documents are not rules. They are approved client work, with the comments still on them. And the standing instruction in my skill now reads: where the examples and the rulebook disagree, the examples win.
If you are a coach or consultant trying to build a second brain for your content, an AI reference library that actually holds your standard, this is the most useful thing I can tell you. The rules are not the standard. The work you already approved is.
TLDR
- A rulebook records what you said. A reference library records what you shipped. They drift apart, and only one of them is real.
- My rules registry grew from 108 to 285 rows because every ruling got added and nothing got reconciled.
- The conflict that settled it was small: the rulebook said 2 sentences, the approved work said 3.
- Putting 37 approved documents in 1 table showed me a repetition I had approved 17 times without noticing.
- I still don't know how many examples is enough, or what to do when 2 approved pieces disagree.
285 Rows, 12 Pages, Then 5 Documents
The registry started at 108 rows. That was already a lot. It was append-only by design, because I'd decided early that every client ruling was worth keeping. Which is true. It is also how you get to 285 rows where 40 of them quietly contradict each other.
So I rebuilt it as 12 pages. Grouped, reconciled, deduplicated. It felt like a big improvement and it was.
Then I did the thing that actually mattered. I picked 5 approved builds, real website copy that had shipped and come back with a "this is fantastic" or close to it, and I put them above the rulebook in the skill's reading order. The model reads the examples first. It reads the rules second. And when they disagree, the examples are the live standard.
I've described the internals of that structure in what is actually inside a skill file. This post is about why the examples had to go on top.
The Conflict That Settled It: 2 Sentences or 3
Here's the specific case, because it's small enough to be convincing.
The rulebook capped a website tile at 2 sentences. Clear rule, written by me, for a reason I still think was sound. The approved builds I keep as reference ran 3 sentences with a stock closer. Both records were real. Only one set of them had shipped and come back approved.
Think about what that means. The rule was my opinion about what good looked like. The example was evidence of what the client actually accepted. My opinion had been overruled in production, repeatedly, and the rulebook had never been told.
That is the whole problem with rules as your standard. They get written once. Reality keeps voting after that, and nothing updates the file. A reference library made of approved work updates itself every time something ships.
For me, a named example settles an argument faster than a written row does. I think that's true for the model too.
What 37 Approved Documents in 1 Table Showed
Once the examples were on top, I got curious and put every approved brand document from April through August into one table. 37 documents. 111 unique hook phrases. 44 category hooks.
17 of the 37 ended on the same 2 words.
Every one of those 37 was approved before it shipped. The repetition was invisible one document at a time and unmissable in one table. I had never shown the model the other 36, so it had nothing to compare against. And I had never shown myself the other 36 either, which is the part I keep turning over.
3 hooks were exact duplicates. Same 2 halves, 2 different brands, both approved. One thing held everywhere: all 37 put the same 3 sections in the same order. No approved example broke it, so that one became a rule, and it's a rule I trust because it came from evidence rather than preference.
What I changed was a sort, not a rule. Before the skill proposes a hook now, it sorts the bank by the second half and, if the half it was about to use already appears 5 times, it picks another. That check only exists because the examples were in a table. A rule would never have found it.
How to Build Your Own Approved-Work Library
You don't need 37 documents. You need the ones that already passed.
- Collect what shipped. The newsletter you were proud of. The sales email that got replies. The client doc that came back with "this is exactly it." 5 to 10 pieces across the 3 Sources is plenty to start.
- Keep the comments on. A clean final is half the value. The version with "love this line" and "cut this, too corporate" in the margin is the whole value. The comment is the instruction. The document is the context.
- Collect what got rejected too. 3 to 5 pieces that made you wince. Write 1 line next to each saying why. This is the anti-pattern half of the library and it holds the line when the model drifts.
- Put it above the rules. In whatever system you use, the examples get read first. When a rule and an example disagree, note it, then decide which one is actually true. Usually it's the example.
- Put it in a table once a quarter. Titles, hooks, opening lines, side by side. You will find a repetition you approved 5 times without noticing. Everybody does.
This is what the Encode step of the method is for. The Voice Print and the Reference Library come out of the same pass, and for most people it is the first time their standard has been written down anywhere. It is also the reason a well-built system stops sounding generic: it has your evidence, not your adjectives.
The Part I Don't Have an Answer For
Two things, and I'd rather say them than pretend the method is finished.
I don't know how many examples is enough. 5 settled arguments that 285 rows could not, on 1 deliverable type. I have not tested whether 5 holds on a newsletter, or a sales page, or a 6-email sequence. My guess is the number is small everywhere, but a guess is what it is.
And I don't know what to do when 2 approved builds disagree with each other. Right now I write both sides down with no winner and let the skill hold the fork. That works better than picking one, and it is not a rule. It's a shrug with a filing system.
Look, you already know your best work is sitting in a folder somewhere. The part you're stuck on is that nobody ever told you the folder was the asset. It is.
If you want to see what a system built on your approved work produces, send me 1 piece of it. Something you said, wrote, or sell. You get a finished asset back in your voice within 48 hours, and you'll see the difference between a rule and an example in the first paragraph.
FAQs about reference libraries
What is an AI reference library?
A curated set of your own real work that an AI system reads before producing anything. It holds approved pieces with the feedback still attached, rejected pieces with a note on why, and the structural patterns that held across everything that shipped. It is the part of a content system that carries your standard, and it outranks any written rule.
Why do examples work better than rules for AI?
A rule describes a property. An example demonstrates it. Models match patterns far more reliably than they follow abstract instructions, so "here is an approved paragraph" moves output more than "be concise and warm." Rules still matter for mechanical checks, but taste travels through examples.
How many examples do I need?
Fewer than you think. 5 approved documents settled conflicts that 285 written rules could not, on 1 type of deliverable. Start with 5 to 10 approved pieces and 3 to 5 rejected ones, and add to it every time a client reaction teaches you something.
What if my approved work is inconsistent?
Then you have found something real. Put the pieces in a table and look at what held everywhere versus what varied. What held becomes a rule with evidence behind it. What varied becomes a documented fork with both sides written down, so the system can hold the choice open instead of guessing.