Course wiki workflow
How to Build a Course Wiki from Lecture Notes and PDFs
Turn one course's readable lecture slides, notes, and PDFs into a maintained wiki with exact sources, prerequisite links, revisions, and review state.
About this guide
Workflows
Students, independent learners, and educators organizing one course's readable lecture slides, notes, and PDFs
8 min read
01
Start with one course and an approved folder of readable lecture materials.
02
Create one concept page at a time with exact sources, prerequisite links, and open questions.
03
Track source revisions and review state so revised slides do not leave polished but stale notes behind.
Worked example
Build a course wiki from lecture notes
A fictional three-note exercise: trace a seat reservation from database write to cache invalidation, then test the 10-versus-9 stale-cache counterexample.
Try this task
Using only the lecture notes, answer how a seat reservation should order the database write and cache invalidation. Include the stale-cache counterexample and list every value the notes leave unknown. Cite each claim with [[filename]].
Expected reasoning
The database is authoritative; write it first, then invalidate the cache. If invalidation fails, the next seat read must use the database. The cache showing 10 while the database has 9 makes a cache-only reservation decision unsafe, and lease duration plus retry count stay unknown.
Why keep this connected
A few notes can be reviewed by hand. A source-linked course wiki helps when revised lecture material, counterexamples, and unresolved implementation choices must remain connected for later study.
Review boundary
Check 10 versus 9, the write-before-invalidate order, and the path after failed invalidation; keep lease duration and retry count unknown.
Inspect the example in Wenlan
Wenlan v0.18.3 interface displaying data read back from an isolated test run. The sources are fictional and the reference answer was written for this exercise. No automatic AI generation or approval is shown.
After the cited source changed, Wenlan marked the page as out of date and kept its original text. The ‘updating…’ label indicates a pending rebuild here; it does not show a completed correction. Review the changed source before rebuilding and accepting a new answer.
Source files
Open a file to read its complete authored Markdown.
The source files are the same authored English dataset in all three locale views.
01lecture-01-consistency.mdLecture 01 — Database is the source of truth
# Lecture 01 — Database is the source of truth In this course example, the course_seats table in the database is authoritative for available seats. A cache may accelerate reads and carries an expires_at value, but a cached value is not a booking decision. After a successful database reservation commit, the cache may still hold the old value until it is invalidated.
02lecture-02-cache-invalidation.mdLecture 02 — Invalidation follows a write
# Lecture 02 — Invalidation follows a write For a seat reservation, commit the database transaction first. Then invalidate the concrete key course-seats:course-42. If invalidation fails, mark the key stale and force the next seat read from the database; retry invalidation. Never write the cache first and assume that the database commit will succeed.
03lecture-03-counterexample.mdLecture 03 — Counterexample and unknowns
# Lecture 03 — Counterexample and unknowns At 09:00, the database says 10 seats and the cache says 10. At 09:01, a reservation commits in the database, leaving 9 seats. The invalidation worker is down, so the cache remains at 10. A cache-only availability check now overstates the seats and is unsafe for a reservation decision. These notes do not specify a cache lease duration or an automatic invalidation retry count. Leave both values unknown.
Reference answer
Reference answer: write to the database first, distrust stale cache state
The database is authoritative. Commit it before invalidating the cache; after a failed invalidation, the next seat read must use the database. The 10-versus-9 counterexample proves that a cache-only reservation decision is unsafe, while lease duration and retry count remain unspecified.
Course-seat consistency — reference
Answer
The database is the source of truth for available seats. A cache can accelerate a read, but its value cannot by itself authorize a reservation. lecture-01-consistency.md
The safe order is to commit the reservation in the database first and invalidate the course-seats cache key afterward. The workflow must never write the cache first and assume that the database commit will succeed. lecture-02-cache-invalidation.md
If invalidation fails, mark the key stale, make the next seat read come from the database, and retry invalidation. lecture-02-cache-invalidation.md
Counterexample
The notes give a concrete stale-read case: the database moves from 10 to 9 seats after a reservation while the cache remains at 10 because its worker is down. A cache-only availability check therefore overstates availability and is unsafe for a reservation decision. lecture-03-counterexample.md
The lease duration and automatic invalidation retry count are not defined by these notes. Keep both as unknowns instead of inventing settings. lecture-03-counterexample.md
Changed source: lecture-02-cache-invalidation.md
Expected update after this change
The initial reference's phrase next seat read from the database becomes too narrow. After the revised lecture, every seat decision must bypass the cache until a successful invalidation clears the stale state. Database-first ordering, the 10-versus-9 counterexample, and the unknown lease duration remain unchanged; no retry count may be invented.
# Lecture 02 — Invalidation follows a write, revision 2 For a seat reservation, commit the database transaction first. Then invalidate the concrete key course-seats:course-42. If invalidation fails, mark the key stale and route every seat decision to the database until a successful invalidation clears the stale state. Never write the cache first and assume that the database commit will succeed. The notes still do not specify an automatic retry count.
01
Quick answer
Create one source boundary for one course, register its readable lecture slides, notes, and text-extractable PDFs, then maintain one page per durable concept. Each concept page should name its prerequisite concepts, cite the exact lecture or page, record the source revision, and show whether the explanation is current, stale, contradicted, or awaiting review.
Wenlan can sync supported course documents, distill source-backed Pages, preserve citations and wikilinks, surface stale dependencies, and keep revisions reviewable. It is not equivalent to NotebookLM and does not generate flashcards, create quizzes, transcribe audio, run OCR, grade work, tutor students, solve homework, plan exams, or make academic judgments.
02
When this problem appears
Lecture materials accumulate by week, but the durable ideas do not follow the same structure. A definition may live in week two, its prerequisite in week one, a correction in a later slide deck, and an exception in a reading note. A one-time summary hides those relationships and can stay fluent after the instructor revises the source. A useful course wiki keeps the explanation small, linked, and traceable to the current material.
03
Build one course-material to concept-page loop
Use materials you are allowed to store and inspect. Begin with one course, one term or version, and a small source set so that every concept page can still be checked against its lecture material.
- Name the course, term, source owner, included folders, excluded material, and the learner or educator responsible for review.
- Register readable Markdown, text, or text-extractable PDFs. Keep scanned PDFs outside the workflow until an external OCR step produces text you can verify.
- Create one page per durable concept instead of one giant course summary. Give every page a question it answers and a short current explanation.
- Link prerequisite concepts explicitly and record unresolved terms, conflicting explanations, and examples that belong to another page.
- Attach important statements to the exact lecture, page, section, or source ID and record the source revision or course-material date.
- When slides or notes change, resync the source, mark dependent pages stale or unresolved, and review the cited passage before accepting the new explanation.
Wenlan workflow and a neutral course concept record
wenlan status
wenlan sources add ~/Courses/distributed-systems/materials
# In a Wenlan plugin client:
/distill <course concept>
/pages <course concept>
/lint
/curate
concept: leader election
question: Why can two nodes not both remain leader in the same term?
prerequisites: terms; quorum intersection
answer: <short explanation supported by the course material>
sources: <lecture, slide or page, and source ID>
source_revision: <term, file revision, or material date>
review_state: <current | stale | contradicted | unresolved>
reviewer: <student or educator>
next_review: <source-change trigger or date>04
What to check next
This is a source-backed study organization workflow, not an AI tutor or assessment system. Wenlan does not generate flashcards, does not create quizzes, does not transcribe audio, does not run OCR, does not grade work, does not tutor students, does not solve homework, does not plan exams, and is not equivalent to NotebookLM. The learner or educator remains responsible for source rights, interpretation, academic integrity, and review.
Build one inspectable course concept
Add a small approved source set, maintain one concept page with prerequisites and exact sources, then revise it only after checking the changed material.
FAQ