What still breaks
The snapshot that was eleven days old
A map tells you what touches what. It cannot tell you whether what you are reading is current. My own scoring taught me that.
I thought the scoring was working.
Every run came back with numbers. The numbers looked reasonable. Nothing errored. So I trusted them.
Then I looked at what the scoring was actually reading. It was a snapshot of my captured work, and that snapshot was 11 days old. The skill that refreshes it existed. It just had no trigger: it was not part of the regular run, so the refresh never ran. The stale snapshot had fed 7 scoring runs before anyone noticed, and every one of them scored an old picture as if it were today.
In the same system, a check flagged a missing tag. Then flagged it again. And again. 9 consecutive runs, the same finding, correctly reported every time... and no path from the report to anyone fixing it. The system could see the problem perfectly. It could not do anything about it, and it did not make me do anything about it either.
And in the same system, more than 100 tasks were created. Zero were closed.
None of that is in the earlier chapters, because none of it is a feature. But if I only showed you the parts that work, you would have no reason to believe the parts that work. So this page is the other half.
The idea
A system you can trust is one that tells you where it breaks.
Every hire gets a review. This is the hire's, and parts of it the hire wrote itself. Every chapter so far ended with an honest limit. This chapter collects them in one place, adds the ones I have not mentioned yet, and shows what the system wrote down when it caught its own drift.
How it works
Here is where the brain is weakest, roughly in order of how much it matters.
Measurement is the weakest layer. The brain can tell me an entry got longer. It cannot tell me the entry got better. When a learning is rewritten, or a profile is sharpened, nothing scores it against a set of known-good answers. Promotion on the ladder counts evidence, which is honest, but counting sources is not the same as checking quality. This is the gap I would fix first if I were starting again.
Scheduling and triggers are the frontier. Most skills run when I ask. That is fine for exploratory work and fragile for anything recurring, because it depends on me remembering during a busy week. The stale snapshot above was exactly this: a capability with no clock. Capture of calls is manual on purpose, because a human has to complete the sign-in, and I would rather press a button than hand a robot my accounts. But the rest is a scheduling gap, and scheduling is the cheapest gap there is to close. I just have not closed it yet.
Plain files have a retrieval ceiling. Plain files give me a lot: every change versioned and diffable, no lock-in, a full history of where each claim came from. What they do not give me is an index. Today the brain is navigated by folders, search and the map from Chapter 10. That holds for now. It will not hold forever, and there is no search index underneath it yet.
The business patterns are waiting on time, not code. In my consulting brain, nine of the ten business pattern files count a different completed engagement as a source. I do not have enough completed engagements yet, so they cannot promote anything. The digest of operating rules that skills are meant to read is still empty. The machinery is built and correct. It is just early. My business learnings file holds 58 learnings, and 47 of them are still at the lowest tier, watch. That is the ladder doing its job: refusing to believe things on thin evidence.
LAYER STATE WHAT IT WOULD TAKE ───────────────── ─────────────── ──────────────────────────────── capture manual, by design a human completes the sign-in memory (files) solid nothing yet; this layer holds retrieval ceiling ahead a search index over the files ladder working, early more completed engagements critic working keep fixing it when it misses triggers mostly manual a schedule on the recurring jobs measurement WEAKEST a scored set of known-good answers
What I learned the hard way
These are not my summaries. They are lessons the system wrote down about itself when it caught its own drift.
"An unenforced rule is not a rule." A rule written down and checked by nobody is a wish. The missing tag reported 9 times is the proof: the rule existed, the report existed, the enforcement did not.
"A document describing a control drifts from the control, silently and in both directions." The description of how a thing works and the thing itself drift apart unless something forces them back together.
"Validate the detector before you act on what it flagged." A check that is confidently wrong is worse than no check, because you stop looking. The 7 scoring runs on an 11-day-old snapshot were exactly that: confident output from an input nobody had checked.
And one I am oddly proud of: the time the system refused its own growth, and was right. That story lives in Chapter 8.
Try it
No repo for this chapter. The limits apply to all five. If you build your own, copy the habit, not the code: keep a file where the system records its own defects, and read it before you trust anything else.
No repository linked yet.
The honest limit
This page is the honest limit. What it does not cover: I have not yet run any of this on a team where several people write to the brain at once, so the failure modes of a busy multi-writer brain are still ahead of me.
Read this next
That is the review. Most of what it found traces back to one mistake: I built the right parts in the wrong order, and measured last.
Next... Build yours, the order I would build it in if I started today. Or go back to The ladder, to see why "still at watch" is the system working.
Building one of these? You don't have to do it alone.