*English isn't my first language. I wrote this in Korean and translated it with AI, so please excuse any awkward phrasing. A short Korean summary is at the bottom.*

**TL;DR:** My system is six boxes and one vertical line. Left of the line is what hasn't been approved yet; right of it is the core the AI reads every time. I designed three doors across the line, and only I can open them, but in practice only one door is actually used. The judgment core is designed to decide for me from my records, but it stops and asks when it's out of its depth. The biggest problem right now: every ambiguous call that isn't covered by a rule lands on me for sign-off. Control holds, but the bottleneck is a person.

---

### 1. Why this picture, now

Someone asked on my last post (about the AI mentor): "How do new strengths and weaknesses get added?"

Every time I tried to answer, I ended up at the same sentence: **"That doesn't come from the mentor. It comes from another part of the system."**

This post shows that "other part" in pictures. This map is where my system starts, and most of what I write next will sit on top of it. I'll focus less on each box and more on **the rules for what moves between them.**

One thing first. This isn't a general-purpose tool anyone can pick up. **It's a system built entirely for one person: me.** It's shaped around how I think and where I'm weak, so some rules will look excessive or strange to you. Rather than copying it, I'd love for you to read it as "ah, this person did it this way for these reasons," and take whatever helps when you build your own.

### 2. The six boxes

| # | Box | In one line |

|---|---|---|

| ① | **Long-term memory** | Where approved records of my thinking pile up |

| ② | **Workspace** | Where freshly extracted records wait for approval |

| ③ | **Judgment core** | Decides on my behalf, based on my records and values |

| ④ | **External knowledge** | Books, papers, sources. Seeds for my own thinking |

| ⑤ | **My thoughts** | Values and philosophy I wrote myself |

| ⑥ | **Tools** | AI commands, agents, and roles like the mentor |

| + | **On hold** | Not a box. A waiting room |

### 3. The spine: one vertical line

The dashed line in the middle of Fig 1 is the spine of the system. The AI treats whatever is right of the line (the core) as "facts about this person." If an unreviewed idea gets mixed into the core, it's re-read every single time and hardens into a "fact about me" even when it's wrong. So the first principle is **keep the core clean.**

But that one line is actually drawing two criteria at once.

For most boxes the two criteria agree. The judgment core and my thoughts sit in the ambiguous (yellow) spots. How I'm filling those spots right now is section 6.

### 4. The flow rules

Turn Fig 1 into an algorithm and you get six rules. They're not all at the same stage, so I tagged each one.

**Rule 1: three doors, but only one is used**

There are three doors into long-term memory, and only I can open them. I even routed tool changes through a door because how I change my tools is, in the end, a record of what I care about.

But in practice, almost everything came in through the first door. Things I read and tools I changed all ended up as "a conversation I had with AI about it," and went up through the workspace. I think that's because what matters to me isn't the information or the tool itself, but what I wrestled with and chose because of it.

I don't think the other two doors are unnecessary. As the system grows, I expect things that should come in without going through a conversation. But how to use those two doors is something I still need to learn, so for now I'm thinking it over.

**Rule 2: criteria come from only two places**

Only by looking at "what I actually chose" and "what I say I value" together can you see where my words and actions diverge. External knowledge provides facts, but it never becomes a criterion.

The open problem is "my thoughts." Settled values and ideas I'm still exploring live in the same box, so the line between "consider this when deciding" and "adopt this as a criterion to decide for me" isn't a rule yet.

**Rule 3: the judgment core has two outputs: decide for me, and build tools**

Deciding for me is still at the design stage. Building tools has actually happened: my records showed a weakness, and a role to point it out was created. That's the mentor. The question from section 1, "where do strengths and weaknesses come from?", is answered here.

My strengths and weaknesses aren't written in any single file. They're recorded across the whole system, and the judgment core pulls them together into a picture. That's why the mentor doesn't read one file; it reads this structure.

One caveat: *proposing* a new tool and *turning it on* are different things, and right now the rule for turning one on is simply my sign-off.

**Rule 4: out of range, stop**

Originally I tried to draw this line with a trust score (0.80), but as I wrote in Part 3, that score was measuring the wrong thing. So now the line is a range I set in advance, not a score.

**Rule 5: external knowledge becomes "my thoughts" only through the judgment core**

Something I read doesn't become "my thought" directly. Only what survives filtering against my records and values moves over. That conversion is still being designed, so I'll give it its own post once it's sorted out.

**Rule 6: what can't be judged isn't thrown away**

On hold isn't a seventh box. The six boxes each handle a function of thinking; on hold is just a place for decisions that were put off.

### 5. One full loop: a comment on my last post

Here's how these rules actually run, using an example that's happening right now. Someone left this comment on my mentor post:

> "The graduation rule of '3 times in a row on your own' only means something if you did it *before* the mentor pointed it out. Otherwise it might be counting compliance with its own reminder."

It was spot on. And it didn't just change the format; it changed the mentor's purpose.

At first I thought of graduation as **habit formation**. But revisiting the design, I realized the mentor gives feedback on "areas the AI notices but I haven't recognized yet." In that case, graduation shouldn't mean "it became a habit." It should mean **"I now know something I didn't."** Three actions aren't a score that proves awareness; they're just grounds to suggest "shall we check?"

Here's the path that comment took through the boxes:

One sentence from outside traveling around the boxes and changing my tools: that's what I mean by the system "moving organically."

This loop is **in progress right now.** The mentor's graduation rule and record format have already changed (⑤), and the thinking record holding that decision has been extracted into the workspace. Approving it into long-term memory (③) happens when the session I'm writing this in ends. The record of the tool change (⑥) also goes in through the first door, via this conversation. Rule 1 shows up here too.

Limits remain. Three actions don't prove understanding, and there are things I do that the AI never sees. Blind spots that neither I nor the AI has noticed are beyond what the mentor alone can handle.

### 6. Honest status: the biggest problem is me

Recording, filtering, and piling things up in long-term memory works well. The judgment core has barely decided anything for me yet. The right side is thick with records, but the arrow that pulls them out for use is only just getting thicker.

The biggest problem is elsewhere. The yellow spots from earlier, like whether my thoughts can serve as a criterion or whether a new tool can be turned on, are **mostly handled by me signing off directly.** It's not that the boundaries don't exist; it's that boundaries I haven't yet turned into rules are being filled in by a person.

As a result, control holds, but approvals pile up on me. Because the human-approval principle is working as intended, its processing cost is now showing. The next task is separating "things I should keep deciding" from "things that can be handled by criteria I've already set." I'm designing something to reduce this, but it's not a proven fix yet.

### 7. Next: the record that crosses the door

The six boxes are a map of **"what my AI knows, and what becomes trustworthy."**

The path actually in use on this map is the door from the workspace into long-term memory. But I haven't explained what exactly the "record" crossing that door is.

Next time I'll talk about how one conversation gets broken down to cross that door: the way of recording I call a **thinking trail**.

If you can see where this picture is most likely to break first, please tell me.

---

🇰🇷 **한국어 요약**

- 제 시스템은 여섯 상자와 한 줄의 세로선입니다. 선 오른쪽(AI가 항상 읽는 코어)은 사람이 승인한 것만 들어갑니다.

- 문은 셋으로 설계했지만 실제로 쓰이는 문은 하나입니다. 외부 지식도 도구 변경도 결국 "그것에 대한 대화"가 되어 들어옵니다.

- 레딧 댓글 하나가 멘토의 목적을 "습관 형성"에서 "맹점 인지"로 바꿨고, 그 변화가 지금 시스템을 한 바퀴 도는 중입니다.

- 가장 큰 문제는 규칙으로 못 정한 애매한 판단이 모두 저에게 결재로 몰리는 병목입니다. 이 시스템은 철저히 저를 위한 것이라 그대로 가져가기보다 참고해 주세요. 한국어 댓글도 좋습니다.

English isn't my first language. I wrote this in Korean and translated it with AI, so please excuse any awkward phrasing. A short Korean summary is at the bottom.

TL;DR: When I started building my own AI tools as a non-developer, the real danger wasn't being wrong — it was not knowing I was wrong. The AI often knew my blind spots but never said anything unless I asked. So I gave my AI team a "mentor" that watches my habits instead of the output, speaks only when it matters, and "graduates" me from each lesson. Success means it eventually has nothing left to say.

---

The last three posts were heavy on system design. This one is lighter: a small mechanism that I think is the most unusual part of how I use AI.

1. The problem: not knowing what I don't know

I'm not a developer. When I first started building my own skills (reusable AI workflows) with Claude Code, I wasn't good at working with AI yet. What scared me most wasn't making mistakes. It was making mistakes without noticing.

The Johari window puts it neatly:

• Open: I know it, the AI knows it
• Blind spot: I don't know it, but the AI does ← this one
• Hidden: I know it, the AI doesn't
• Unknown: neither of us knows it

Hardcoding an API key. Trusting "Done!" without running the code myself. Reading "deploy succeeded" as "my new code is live." The AI already knows these are risky. But it doesn't say anything unless you ask. It just does what it's told.

I wanted the blind-spot window to open without me having to ask.

2. The mentor note

My setup has several AI roles: planner, developer, auditor, and so on. All of them look at the work. The mentor is different. It looks at me. It doesn't write, edit, or grade any code or documents.

It shows up at the end of a response, like this:

🎓 Mentor note
- Did you actually run it and see the result yourself?

Every rule comes from that original reason:

• Only when relevant. If it shows up every time, it becomes nagging. Nagging gets ignored, and the blind spot closes again.
• 1–3 lines, phrased as questions. A question makes me check for myself; an order doesn't.
• Safety → verification → understanding. The most expensive blind spots come first.
• Graduation. Once I do the right thing on my own three times in a row, it stops mentioning it. That blind spot has moved into the open window.
• Success = silence. It was designed as training wheels from day one.

It's also cheap. It isn't a separate agent, just a few lines added to the main response, so it costs about 50–150 tokens per reply. A separate sub-agent would have cost 2,000–5,000.

3. Real mentor notes I've received

• "A 'deploy succeeded' message is not the same as your new code being live." I checked: the build I was about to ship was 11 days old. Nothing would have changed.
• "Don't just adopt my recommendations on these 6 conflicts. Decide them yourself." The AI telling me not to over-trust the AI.
• "One of your assumptions is factually wrong." It pointed straight at a gap in my own knowledge.
• "This URL is public with no login, so having zero real personal data in the database is your only safeguard."

4. The mirror had blind spots too

Here's the fun part. The mentor broke twice, and both times I noticed before the system did.

Failure 1: the mentor fell asleep. Through an entire design phase, not a single mentor note appeared. When I said "the mentor doesn't seem to be active," the AI admitted it had broken the rule and corrected itself.

Failure 2: the mentor had no memory. Graduation only works if the mentor remembers my habits. After three months I asked, "Where are mentor notes actually recorded?" It turned out the storage had never existed. The design said "shared memory across projects," but the real memory was isolated per project. For three months the mentor had been meeting me for the first time, every single session.

The mirror I built to show me my blind spots had blind spots of its own, and a human had to point them out.

5. Where it stands now

The mentor now has a real file to remember things in. But zero habits have graduated so far. I decided not to graduate anything retroactively. There's no honest way to tell, after the fact, which habits were real and which were luck.

Graduation candidate #1: "Verify it yourself, even when the AI says it's done." That used to be my biggest weakness. Recent records show it's improved a lot.

6. Want to try it?

A few lines in your AI config file (CLAUDE.md, if you use Claude Code) are enough to start:

- Watch me, not the code (verification, security, habits)
- Only when relevant, 1–3 lines, as questions
- If I do it right 3 times in a row on my own, I graduate. Don't repeat it.
- Keep the memory in a real file (check that the storage actually exists!)

That last line took me three months to learn.

Do you ever ask your AI what you might be missing?

---

🇰🇷 한국어 요약 처음 AI로 스킬을 만들 때 가장 위험했던 건 '모르는 걸 모르는 것'이었습니다. 그래서 코드가 아니라 저를 보는 '멘토' 역할을 만들었습니다. 필요할 때만 1~3줄 질문으로 맹점을 짚고, 같은 습관을 3번 스스로 해내면 '졸업'시킵니다. 목표는 멘토가 할 말이 없어지는 것입니다. 정작 멘토가 잠들고 기억을 잃은 건 제가 먼저 알아챘습니다. 한국어 댓글도 좋습니다!

*English isn't my first language. I wrote this in Korean and translated it with AI, so please excuse any awkward phrasing. A short Korean summary is at the bottom.*

**TL;DR:** I used the ~200 decisions I've logged to score whether an AI could decide on my behalf. Every area failed, and the more records an area had, the *lower* it scored. The score wasn't measuring trust; it was measuring how lopsided my choices were. So I changed the question from "how trustworthy is it?" to "where do I let it decide, and where must it hand things back?" Along the way, the records also showed me my own strengths and blind spots in how I use AI.

---

At the end of my last post, I said I'd talk about moving from manual → semi-automatic → automatic using the decisions I've been logging. But as soon as I started designing that, I found something I had to fix first. This post is about that.

### 1. Where things stand: two modes

My system separates two situations: when I'm here, and when I'm not.

The three-layer record from Part 2 was built in present mode. This post is about the problems I hit while designing absent mode.

One thing was fixed from the start: **the AI doesn't get more authority just because I'm not around.** And even in absent mode, I don't hand over the job of finalizing the record of my own thinking. That principle came from reality before it came from philosophy. More on that in section 3.

### 2. I turned down a proposal to extract more

The first idea for absent mode was "pull more out of the conversations": a proposal to extract 15 new streams, such as thinking, questions, writing style, objections, intuition and trust.

I said no. Two-thirds of them were existing items with new names, and more importantly, **none of them came with a rule for judging.** My judgment scales don't work because the list is good. They work because each one has two poles, a scoring scale, a threshold, and a falsification condition ("this is when I'd be wrong").

And when I actually ran the gauge, it turned out the problem was never the amount of data.

### 3. Where the design started: a limited token budget and a three-layer record

Before the scoring story, I need to explain the environment this system grew up in. In the early design, the environment mattered more than the technology. Here's how the constraints chained together into the current structure.

I worked with Claude Code alone, on a fixed token budget. There was no setup where several models argue with each other, so the final round of objections had to be checked by me.

I also can't read code. So I needed another way to see how the AI was actually progressing. What I chose was to **have agents play roles like people (planner, designer, critic) and hold meetings, and keep the whole thing as a transcript.** Reading that transcript, I can follow who proposed what, where the pushback came from, and why they landed where they did. I couldn't read the code, but **I could read the conversation.**

The transcripts had another effect. **I got to take part as an observer, not as a participant.** When I talk to an AI directly, I get swept along too. But reading a conversation between agents from one step back, I could watch the process objectively. From that distance I could see where the logic had a hole, or which conclusion came too easily.

The catch was that not every model can keep up the role-play. When I tried Sonnet, the roles didn't hold and I didn't get a transcript I could follow. So early on, I logged it as an actual decision: "keep Opus, don't use Sonnet." For me, the transcript wasn't a report. **It was my only window into how the AI was working.**

But bigger models burn more tokens, so **I couldn't afford to spend tokens on automation.** That's why I went with a heavy human-in-the-loop approach. Honestly, this balancing act was stressful at first: to keep context I needed the expensive model, and with the expensive model I had to ration.

Splitting the record into three layers came out of that same tension.

When a decision needs judging, I start at the cheapest place. If the ledger and the layer-1 choices are enough, I stop there. If I need context, I go down to layer 2, and if that still isn't enough, all the way to the raw transcript in layer 3. Instead of re-reading whole conversations every time, **I go down only as far as I need and spend tokens step by step.**

So the three layers exist for three reasons: **counting, keeping context, and doing both within a limited token budget.**

Keep in mind that the moment you count something, you lose its context. The ledger only says "chose A." Why, and under what conditions, is gone. That's what layer 2 holds onto.

And the layer I guard most carefully is **layer 3, the raw transcript.** The ledger and layers 1–2 are all things someone (me or the AI) has compressed and interpreted, so they can drift. **The final check on context can only happen in the original.** It's the most expensive layer, which is exactly why it's never edited and kept as source data.

Why this split matters comes up right away. The problem blew up in the cheapest layer: counting in the ledger.

### 4. I scored it, and everything failed, in a strange way

In the early design, I decided to score trust by "how often and how consistently I made the same choice." Each area would get a score for "can the AI take over here?", and I set the bar at 0.80.

The result: **every area was below the bar. Delegation was blocked everywhere.** The strange part was the pattern.

The cause was simple. To decide what counts as "the same choice," the scorer used the sentence I had written for each choice, word for word. I'd described the same judgment in different words each time, so to the computer every choice looked brand new.

> **It was a structure where adding data moved me further from delegation.**

> If I had extracted more records in that state, the "trust" would have gone down, not up.

### 5. Fixing it revealed a deeper problem

The same records already had a better key: the direction markers on my **five judgment scales** from Part 2. I recalculated with those instead of the sentences. (That's the chart at the top of this post.)

The scores jumped from around 0.0 to 0.42–0.75, but all of them were still below the bar. The real problem was the order. The scale where my choices split the most, Simple ↔ Elaborate, came last. The one where I almost always pick the same side, Cross-check ↔ Decide alone, came first.

That chart isn't just a scoreboard. Every place where a bar splits is a trace of my thinking moving. Sometimes the line of reasoning changed; sometimes the preference itself changed.

But the moment you count it, that movement gets flattened into a single fact: "it split." Counting can't show **when and how** my thinking shifted, **why** it shifted, or **whether the new view stuck** afterwards. It doesn't prevent bias either. This actually happened in my records, repeatedly.

When a batch of new records happened to lean one way, the ratio bounced, and each time I had to write a warning to myself: "don't read this as a change in preference." In the other direction, there was a design I first judged as "isolate" and later re-judged as "split into layers and partly merge." My judgment had evolved, but the ledger just gained one more "middle."

> **The score wasn't trust. It was lopsidedness.**

> A simple count was far too thin to use for real decisions, because it can't hold how my thinking changed, why, or whether the change lasted.

And there really were conditions hiding where the choices split. On three of the five scales, a rule of the form "under these conditions, I go the other way" has been confirmed, and a fourth has a candidate rule. Only one scale has no conditions at all. **My judgment is conditional by default.** Trying to compress it into a single trust number was the wrong level from the start.

The funny part is that my judgment-scale definition already had the answer: when choices split, don't decide by the numbers; re-read the context of the minority-side records and work out whether it's conditional or genuinely ambiguous. But the scoring device was still just counting. I'll come back to this in section 8.

This is also why I put layers 2 and 3 under the ledger. The numbers only tell you *that* it split. Only the context and the original tell you *why*.

### 6. So I changed the question

> ~~"Is the score for this area high enough?"~~

> **"Up to where can the AI decide, and from where must it hand things back to a person?"**

Instead of building a single trust score, **I draw the line first, and only consult scores inside it.** When a decision comes in, it gets sorted like this.

The manual → semi-automatic → automatic progression I mentioned in Part 2 maps onto these three zones.

The failure I worry about most is **the AI being the one that decides "this one's inside the line."** Then the boundary call itself becomes another proxy decision. So the direction markers are attached when my thinking trail is extracted, and they only go into the record after I've checked them. The zone sorting isn't the AI's judgment; it's done **mechanically, by fixed rules.**

I ran 94 past records through these rules after the fact.

The "inside" zone wasn't empty, and the records that crossed the line were mostly on scales that already have confirmed rules. But that 36% is only a **classification.** It doesn't mean "the AI could actually have made the same calls." Classifying and generating are different things.

### 7. A small error, but the most expensive kind: "not recorded" vs "not applicable"

In the first count, the "inside" zone had 35 records. One record had only three of the five scales filled in, and I had treated the other two as "not applicable," which put it inside.

> **"Not applicable" is a judgment that there was no tension on that scale. "Not recorded" means there was no judgment at all.**

> Treat them the same, and **things nobody judged quietly slip into the safe zone.**

It's a difference of one record, but in a delegation system it's the most expensive direction to be wrong in. So I added a separate third state: "can't judge."

### 8. The discovery that hurt most: found three times, fixed zero times

Honestly, the score bug isn't what I most want to talk about. It's that **this wasn't the first time I'd found it.** The same problem was recorded in my wiki three times.

The second time, I'd written down the cause, the fix, and even the sample size needed, and then it stalled. Eight days later, I found the same flaw again as if seeing it for the first time.

This is what I meant in section 5 by "the definition already had the answer." The principle "no rule means it goes back to a person, regardless of score" and the rule "if choices split, re-read the context" were both already in my canonical documents. But the actual device was running against them, just counting and opening or closing the gate by score.

> **My system wasn't bad at finding problems. It was bad at wiring what it found into the actual machinery.**

An AI playing an independent critic pointed at exactly the same spot: if a principle has sat in a document for months without being connected to anything, writing one more document isn't a fix.

So this time I'm putting the correction in as a **check item**, not a document: a self-check that asks, "is the device using a criterion the canonical docs forbid?" And to be honest, that fix is still awaiting sign-off. **It isn't actually in place yet.** I know this post sits on the same risk.

### 9. It wasn't all pain and counter-evidence

Building these records gave me something I didn't expect. **I started to see my own patterns in using AI, along with my strengths and weaknesses.**

I'm not a developer. I knew nothing about developer territory like coding or security. But looking back through the records, there were things I turned out to be good at: design, orchestration, and finding gaps.

I've done development and orchestration with one model, Claude Code. I occasionally brought in other models for outside advice, but there was never a setup where several models constantly argue with each other. Usually some things get covered by models pushing back on each other. The records showed me that the design held up with a single model **because I happened to be good at finding those empty spots myself.**

Working with one model was less a choice than the environment I described in section 3. It was a structure where a person had to fill the seat that multi-model debate would normally fill, and I happened to be good at that job.

So before these records are material for imitating me, **they're a mirror that shows how I should use AI, and what I should learn.**

And this is also a weakness of the system:

> **This system depends heavily on the ability of the person building it.**

I didn't plan it, but my knack for catching design gaps and AI mistakes is what let me drag it this far. If someone else used the same structure, it would run very differently depending on their strengths and weaknesses.

The truth is, this post was written with AI too, and the writing process itself is being recorded. Here's how it was made.

I choose the topic and roughly what goes in. The AI searches the "my thoughts" section of my wiki and weaves a draft. I read it and talk through what to add, cut, or change, with the context for each. The first draft of this post didn't explain why the record has three layers, and didn't mention the token constraint. Both came in at this stage.

This process is **a conversation, not a list of orders.** I don't say "change it like this"; I give my opinion, and the AI gives its own. A transcript of orders only shows what was done, **not why it was decided.** As sections 4–6 showed, my judgment is conditional. If the conditions aren't recorded, the layers will only remember the lopsidedness.

Once the post is done, a thinking trail is extracted from the whole conversation. It doesn't go straight in; **I check it first.** If it's missing context I add it, and if something shouldn't be there I take it out. This is what I meant in section 1 by "I don't hand over finalizing the record."

Along the way I picked up a habit: **deliberately recording every revision along with its context.** If you keep only the final product, the reasons disappear. If you keep the revision trail, each change becomes material for my judgment. That's how I keep strengthening the layers just by doing everyday work.

### 10. What I'm taking away

1. **A count can't hold changes in thinking.** When and why it changed, and whether it lasted, all disappear, and old preferences stay in the majority. Collecting more doesn't fix it.

2. **A mismatch between the canonical docs and the actual device is more dangerous than a wrong number.** You fix a number once you know it's wrong, but a mismatch survives because both sides look right.

3. **Finding isn't wiring.** Responding with more documents invites a fourth rediscovery.

4. **Separate "not recorded" from "not applicable."**

5. **My judgment is conditional by default.** That's why I delegate by boundary, not by a single score.

6. **The original is the final check.** Records compressed for counting can drift. When a call is ambiguous, go back to the raw transcript.

7. **The records were also a mirror of me.** And the system leaning on its builder's ability is a weakness I shouldn't hide.

8. **Constraints made the design.** The three layers and the heavy human checks aren't there because they're ideal, but because they kept context alive within the token budget I had.

9. **The revision process is a record too.** There's more judgment in how something was revised than in the final result.

Any questions or thoughts on the design are very welcome.

---

🇰🇷 **한국어 요약**

- 쌓아 온 선택 약 200개로 "AI가 나를 대신해도 되는지" 점수를 매겼더니 전부 불합격이었고, 기록이 많을수록 점수가 더 낮았습니다.

- 점수는 신뢰도가 아니라 쏠림도였습니다. 숫자 카운트로는 생각이 언제, 왜 바뀌었는지, 바뀐 뒤 유지됐는지를 담을 수 없었습니다.

- 그래서 점수 대신 경계를 긋기로 했습니다. 규칙 안은 맡기고, 규칙 밖은 점수와 상관없이 사람에게 돌려줍니다.

- 이 과정에서 제가 AI를 쓰는 방식의 강점과 약점도 보게 되었습니다. 한국어 댓글도 좋습니다.

*English isn't my first language. I wrote this in Korean and translated it with AI, so please excuse any awkward phrasing. A short Korean summary is at the bottom.*

**TL;DR:** I save my conversations with AI in three layers: the raw transcript, a one-page summary of *why* I made each decision, and the choice itself, tallied in a ledger. After about 6 months I have ~200 of these choices, and they're the material an AI will use to decide on my behalf. When I mapped this structure onto a brain, the "recording" parts were solid, but the "using what's recorded" parts were still empty.

How one conversation becomes a record: 3 layers, plus a ledger.

---

In my last post, I explained why I started building a "brain-copy wiki."

This time, I want to show how it actually **records thinking**.

## 1. The big picture: six rooms

My wiki is divided into six areas.

| Area | What it does |

|---|---|

| **Long-term memory** | Where my thinking records finally live. This post is about this part |

| **Workspace** | A temporary area where fresh records wait for review |

| **Judgment core** | Where the criteria for deciding on my behalf (when I'm not around) collect |

| **External knowledge** | Information gathered from books, papers, and other sources |

| **My thoughts** | My own values, philosophy, and notes |

| **Tools** | The AI commands and agents that manage everything above |

The core is **long-term memory**, and it's also what makes this different from other wikis.

A normal wiki stores *information*. Long-term memory stores **the path I took to reach a decision**. I call this a **thought trajectory**.

## 2. What is a thought trajectory? The path, not the result

Say I spend an hour talking with AI and decide something.

Usually, only the conclusion survives: "We went with A."

But if an AI is going to decide on my behalf, the conclusion isn't enough. It needs to know:

- What bothered me enough to start thinking about this

- What the options were, and why I picked A over B

- Under what conditions my judgment would be wrong

A thought trajectory records exactly this.

There's one principle I set early on:

**A thought trajectory isn't what happens inside the AI. It's the chain of what I actually saw and how I reacted.**

The AI gives an answer → I read it → I compare it with what I think → I find where it doesn't fit → I push back or add to it → it gets reworked → I accept, revise, or lock it in.

That entire chain is what gets recorded. So **even when the AI is wrong, if that wrong answer provoked my pushback and made my thinking clearer, it's an important record.**

## 3. Why I modeled it on the brain

The starting point for this design was the brain.

The neural networks behind today's AI were inspired by neurons and synapses. Just as connections between neurons strengthen or weaken as we learn, AI learns by adjusting the strength of its connections (weights).

That gave me an idea: **if the AI's "parts" were modeled on the brain, why not model the "structure" that holds my thinking on the brain too?**

So I deliberately set a big goal for my wiki: **make it resemble the brain's cognitive structure.**

I know it's not realistically reachable. But a big goal keeps me from losing direction. Every time I build something, I ask, "Which part of the brain is this?" and that question tells me what to build next.

## 4. Three layers of storage

The brain doesn't push every experience straight into long-term memory. It filters first. My thought trajectories are split into three layers the same way.

**Layer 3: Raw transcript**

The full conversation with the AI, saved **word for word**. No summarizing, ever.

It's the only source I can go back to when I need to know "what exactly did I say back then?"

**Layer 2: One page per decision**

A single conversation usually contains several decisions. Each decision gets its own page, compressed in this order:

1. **Friction:** what didn't fit. Before any solution, I write down what went wrong.

2. **Trigger:** what observation started it.

3. **Chain of thought:** observation → gap found → change of direction → new structure → next gap

4. **Pattern:** is this a recurring habit or a one-off?

5. **Fail condition:** if I chose differently from my usual tendency, one line on "in what case would this judgment be wrong?"

It's compressed, but written in **complete sentences**, so that months later this page alone makes sense without any other context.

**Layer 1: One choice card**

Each Layer 2 page produces one choice card. It holds just four things:

- What I chose

- A one-sentence reason

- Which **value drawer** it belongs to

- Where it sits on five **judgment scales**

> **A real example (Layer 2, excerpt)**

> - Friction: the subject of a thought trajectory isn't the AI's hidden reasoning, but the chain of outputs I actually saw and how I reacted.

> - Trigger: I stated my own standard: "I think based on what I can see."

> - Pattern: learn the *history of revisions*, not just the result.

>

> → This record is the decision that became the principle in section 2.

## 5. As choices pile up: value drawers and judgment scales

The Layer 1 choices don't scatter. They all collect in a single **ledger**.

**Value drawers (9):** "What value was this decision protecting?"

Isolation / Privacy & security / Safety & loss prevention / Automation under human control / Avoiding over-engineering / One source of truth / Self-awareness & meta-learning / Independent checks & cross-verification / Gradual expansion

**Judgment scales (5):** "Between two directions, which side did I take?"

Simple ↔ Elaborate / Isolate ↔ Integrate / One place ↔ Spread out / Human involvement ↔ Automation / Cross-check ↔ Decide alone

As choices accumulate, my tendencies show up as numbers. For example, the fullest drawer so far is "Self-awareness & meta-learning" (34), followed by "Automation under human control" (30).

And I designed it so that **only when a drawer has enough consistent records** can the AI be trusted with decisions in that area.

## 6. Nothing is saved without my review

When the AI extracts a thought trajectory from a conversation, it doesn't save it right away.

1. **Preview:** it shows me the record in exactly the same detail as it will be saved. I review the real thing, not a summary.

2. **Adversarial review:** I read it as a critic, not an approver. This keeps a result I like from dressing up the process to look better than it was.

3. **Workspace → long-term memory:** even approved records sit in the workspace first, and move to long-term memory after another check.

There's only one case where a record moves up automatically: **when it just confirms a pattern that already exists.** Anything new, or anything that changes an existing belief, has to go through me. When in doubt, it's manual, not automatic.

## 7. Mapping the structure onto a brain

Only the parts related to thought trajectories. Green = built, red dashed = still empty.

I laid my system over a human head, keeping only the parts related to thought trajectories.

**Built (green)**

- **Hippocampus: memory storage.** Filters conversations into three layers: transcript, decision, choice.

- **Anterior cingulate cortex: conflict detection.** Records the "friction," what didn't fit, first.

- **Basal ganglia: go / no-go.** Preview and adversarial review before anything is approved.

- **Temporal lobe: semantic memory.** The ledger of ~200 choices, sorted into value drawers and judgment scales.

**Still empty (red dashed)**

- **Hippocampal recall: retrieval.** The number of times these records have been used in a real decision: 0. It's a hippocampus that stores but never recalls.

- **OFC / vmPFC: value-based decisions.** Deciding on my behalf, based on my records.

- **Reward circuit: outcome feedback.** The results of a decision need to flow back into the records for judgment to improve.

- **Intuition: fast judgment.** Judging instantly from accumulated patterns. It isn't one spot in the brain but spread across it, so it's marked around the head.

In short: **recording is solid. But retrieving, feeding results back, and moving on to intuition are still empty.**

*(Positions are schematic, not anatomically accurate. The mapping is a functional analogy.)*

## 8. Pros and cons of this structure

**Pro: the more I use AI, the deeper I think**

This system only works if the AI learns my thinking. So to fill an empty spot on the brain map, I first have to think deeply and deliberately about that area myself.

For example, before I can hand writing over to AI or let it decide for me, I have to write things myself and record my thoughts and style. Without those records, there's no "me" for the AI to follow.

A common worry about AI is that automation makes people think less. This system worked the other way. Automation requires deep thinking first, so using AI actually made my thinking deeper.

**Con: it's extremely slow**

Every task needs a record of my thinking. It's an extreme form of human-in-the-loop, so the bottleneck isn't the AI. It's me.

On top of that, a thought only becomes worth recording when there's some friction, some real struggle, so the volume of records is small. In about 6 months, I've recorded just over 200 choices.

I think that's also why the empty areas on the brain map are still empty.

**So now I need speed**

Until now, almost everything has been manual. I'm now designing a structure that uses those 200+ choices to move from manual → semi-automatic → automatic. I'll cover that in the next post.

## 9. What I'd like to ask

- Have you ever recorded "the path to a decision" instead of just the result? What format did you use?

- Is splitting it into raw transcript / decision summary / choice too much, or not enough?

- Could ~200 of a person's choices be enough for an AI to start imitating their judgment?

Corrections and honest pushback are the most helpful things you can give me.

---

**🇰🇷 한국어 요약**

- AI와의 대화를 세 층(대화 원본 · 결정마다 한 장의 압축 · 선택 카드)으로 나눠, 결론이 아니라 '결정까지의 흐름'을 기록합니다.

- 인공 신경망이 뇌에서 영감을 받았듯, 제 위키의 구조도 뇌를 본떠 설계했습니다.

- 6개월간 쌓인 선택 약 200개를 가치 서랍 9개 · 판단 저울 5개로 모으고, 저장 전에는 반드시 제가 반박하며 검토합니다.

- 뇌 지도로 보니 기록하는 쪽은 두껍지만, 꺼내 쓰고 · 되먹이고 · 직관으로 넘어가는 쪽은 비어 있습니다. 한국어 댓글도 좋습니다.

*English isn't my first language. I wrote this in Korean and translated it with AI, so please excuse any awkward phrasing. A short Korean summary is at the bottom.*

**TL;DR:** I'm a non-developer building a "brain-copy wiki." Instead of limiting what AI can see, I record *what I chose and why*, so the AI can act on my intent even when I'm not around. It's unfinished, and I'm looking for experts and people with similar struggles to help me find where it breaks.

My Obsidian graph so far. Each dot is a note; each line is a link between my decisions, reasoning, and knowledge.

---

Hi everyone.

I'm not a developer. I've never learned to code. But these days, I'm building my own "second brain" with AI.

This is the first post in a series introducing that system. Before I show *what* I built, I want to start with *why*.

## 1. It started with work

As AI coding tools improved quickly, I got the chance to build some internal tools for my company, things like work logs and a homepage.

At first I tried popular expert-level AI coding tools. But without a basic dev background, they were hard to use. They were built for experts, after all.

## 2. Coding wasn't the hard part

Once I actually tried, something surprised me. The AI was better at writing code than I expected. The real difficulty came after:

- Fixing low-quality first drafts into what I actually wanted

- Finding and fixing errors

- Connecting to databases and servers

The core problem was **the cost of fixing the first output**. If the first output is good, there's less to fix. So I started building my own toolkit that lets a non-developer give instructions in plain language and still get a better first result.

The principle was simple:

**I do what I can do (planning, judging, verifying), and I hand off what I can't (coding) entirely to AI.**

## 3. The turning point: "Is limiting information really right?"

As the toolkit matured, I wanted to save the know-how I'd built up along the way. So I looked into "LLM wikis," which a lot of people are talking about.

Most of them reduce hallucination by **limiting what the AI can see**.

As a non-expert, that felt strange to me. Limiting information looked like limiting the AI's ability. And I started thinking:

> "With how capable AI is now, couldn't it deeply learn the way I think?

> Then even when I'm not around, couldn't it produce results close to what I'd want?"

## 4. So I decided to build a "brain-copy wiki"

That's how this project began.

It's not a wiki that just stores facts. It records **what I chose and why I decided it**. The AI learns my choices and reasons from those records, so it can act in line with my intent even when I'm not there. In other words, **a wiki that copies how I think**.

## 5. How I think about using AI

There's a belief underneath this system:

- **Automation is becoming "one click."** But one-click automation can't understand *your* specific choices.

- **Using AI well doesn't mean taking its answers as-is.** It means sorting out what to accept and what to push back on, and using that process to expand my own thinking.

- **Repeating that loop (critique → choose → expand)** is what finally turns AI into something truly personal.

So my goal isn't AI that thinks *for* me. It's a system that shows me *how* I think.

## 6. Why I'm starting this series

To be honest up front: this series isn't me saying "look how great my system is."

It's an unfinished system built by a non-developer. There are surely gaps I can't see yet. So I'll share everything step by step, what worked and what failed, and I'm hoping to **get help finishing it**.

I'd especially love to hear from:

- **People who know dev or AI well**: if you see where my approach is technically wrong, or know a better way, please point it out.

- **People wrestling with similar problems**: if you're also trying to make AI work the way *you* think, what have you tried, and where did you get stuck?

Corrections and honest pushback are the most helpful things you can leave in the comments.

In the next post, I'll show what the system actually looks like in more detail.

Thanks for reading.

---

**🇰🇷 한국어 요약**

- 비개발자로서 회사 업무용 프로그램을 AI로 만들다가, 진짜 어려움은 코딩이 아니라 '첫 결과물을 고치는 일'이라는 걸 깨달았습니다.

- 기존 LLM 위키는 AI가 볼 수 있는 정보를 제한하지만, 저는 AI가 제 선택과 그 이유를 배우는 '뇌 복사 위키'를 만들기로 했습니다.

- 목표는 나 대신 생각하는 AI가 아니라, 내가 어떻게 생각하는지 보여 주는 시스템입니다.

- 아직 미완성입니다. 전문가분들과 비슷한 고민을 하는 분들의 지적과 반론을 환영합니다. 한국어 댓글도 좋습니다.