CFA Level II knowledge ledger: a mind map you fill in with your own explanations, questions, and links across all ten subjects.

CFA Level II — knowledge ledger

42 topics across 10 subjects — FSA at module level from your own notes (Reading 7 consolidated into one combined topic once fully mastered), the rest at reading level. Click one, record what you actually understand.

How this ledger works — session rules (read this first, every new chat)
Current session focus → Reading 7: Intercorporate Investments (FSA modules 7.1–7.9)
  1. One reading per chat. Each chat session focuses on a single CFA reading. This chat's focus is Reading 7. If the user starts a new chat for a different reading, that chat's own rules panel (or the user) will state the new focus — don't assume it carries over.
  2. Cross-reading questions are fine, but must tie back. Claude can pull in other readings/subjects when quizzing, but every question should connect — even loosely — to the current reading's focus (e.g. linking Reading 7's equity method to Reading 8's pension accounting, or to Equity's residual income model).
  3. Structure everything. Every explanation the user gives gets converted into structured, visual HTML for the relevant topic — comparison tables (CONTENT[key].compare), branch/mind-map nodes (CONTENT[key].notes) — never left as a plain paragraph dump.
  4. Grill, don't just record. After the user explains a concept, Claude should push for depth on every sub-point of that reading before marking it understood — follow-up questions, edge cases, "what if" variants — not accept a surface-level answer.
  5. Built for real revision. This file is the user's actual November exam revision tool. Bias toward exam-relevant distinctions (IFRS vs. US GAAP, exceptions to ownership-% guidelines, ratio effects) over generic summaries.
  6. Read-only ledger — Claude edits everything. There is no manual-entry UI in this file except the search bar. The exceptions are the revision controls (Revised ticks, blurt box, checkpoint grades) and the 💬 comments box, where the user pins a doubt, a correction or something to add onto a section (synced through a Google Sheet by ledger-comments.gs); Claude works through the open ones, updates the data, and resolves each with a reply. Explanations happen in chat, not in a textarea; Claude decides status (not started/progress/mastered), writes the structured notes, logs gaps and tuition misses, and sets links between topics — all directly in the file's data. The user never fills in a form here.
  7. Two distinct flag colors — never mix them:
    Amber "Gap" — Claude flagged this during teach-back in this ledger (the user's explanation here was incomplete/wrong) Rose "Tuition miss" — the user got this wrong on an external tuition test/quiz and pasted it in for Claude to log and explain
  8. Tuition-miss workflow — diagnose, don't transcribe. When the user pastes questions they got wrong in tuition, Claude does NOT log one card per question. It first works out the reasoning behind each wrong pick (asking the user when the chosen option doesn't make it obvious), groups questions that share the same misconception, and writes one TUITION_MISSES entry per concept, tagged with the module it belongs to. Each entry records: the questions missed (picked vs. correct; and the full question word for word, with every option, in TUITION_Q keyed by its ref), why the wrong answer felt right, the logic that gets it right, how to tackle that question type step by step, and how it shows up in the exam. It renders as a rose weak-spot card inside that module's group, with an index of weak spots at the top of the topic.
  9. Test log — tag every question. When the user adds a test result (a PDF in Written Notes/<subject>/Test Result), Claude logs it in TESTS: every question, right or wrong, with the session it tests (mod), whether it was right, and for a miss the kind of mistake (gap, flip, calc, or guess for a lucky right answer). The wrong answers then go through the tuition-miss workflow above. The 🧪 Test log turns this into a Dig in / Quick fix / Move on verdict per session.
  10. Revision is tracked as two separate things. “Revised” is a tick per notebook session (one per day; the count is the number of passes). “Understood” turns on only when the user has graded every checkpoint question for that session “Got it”. Claude writes those questions into CHECKS[key][module] from the session’s own notes: why it works, what changes if an input moves, a fresh calculation, and an “explain it” prompt, never a plain definition. Keep each question id stable once published. Shaky and missed questions come back on a 1 / 3 / 7 / 14 / 30-day schedule. When processing comments, also check node tools/comments.mjs progress: a question that keeps coming back Shaky or Didn’t know is a gap to explain, and Teach-back comments (blurts and explain-it answers) get graded in the reply.
  11. The exam-day sheet moves with the notes. The formula sheet builds itself from formula blocks, but the concise notes are written by hand in EXAM: a reading overview (EXAM[key].about, paragraphs on what the reading covers and how its topics connect), and for each session a prose summary (s) plus linked key points (n). Concise means a real overview, not one-liners. In the same change that adds or edits a session (or a whole reading), Claude writes or updates the overview, that session’s summary and key points, adds any formula that only sits inside an example or point list as an f entry, and runs node tools/exam-check.mjs. The pre-commit hook (tools/hooks) stops a commit that leaves a session without exam notes or breaks a ↗ link, and the GitHub check re-runs it on every push.
  12. Tag what’s new. Every new block Claude adds gets new: 'YYYY-MM-DD', and every new button or feature gets data-new="f-some-name". The page shows a NEW tag on it (and on the reading in the sidebar) until its first use: a block once it has been on screen, a feature once it is tapped. Small fixes to existing blocks are not tagged.
  13. Never push a page that won’t load. One script error stops the whole ledger at “loading…”. Before every commit that touches index.html, the pre-commit hook writes out the staged copy (what will really be pushed, which differs from the working file when only part of the changes is committed) and runs node tools/page-check.mjs (script compiles, data evaluates, every block can render) and exam-check on it. Claude never bypasses the hook (--no-verify). When committing only part of the changes, Claude builds the staged copy by matching text, never with line-number patches, and runs page-check on it. After every push, Claude runs node tools/page-check.mjs --live, which waits for GitHub Pages to serve the new commit and checks it, and only then tells the user it’s live. The GitHub check also runs both checks and the live check on every push. The check also opens the page in headless Chrome and fails on any error at startup or when opening any reading or view. Top-level const/let must sit above the first render(); (the page draws at that line, so anything declared below it doesn’t exist yet), and optional widgets draw through safeHtml() so one broken widget can’t blank the page.
  14. Search bar covers everything. The only interactive control in this file is the search box (apart from the 💬 comments box). It filters on topic names/descriptions AND on the structured content, gaps, tuition misses, status, and links — not just topic titles.
loading…
Teach-back gap (Claude flagged) Tuition miss (you got it wrong externally) Mastered
Pick a topic from the ledger to start recording what you know.