We built a knowledge base for ourselves and then wrote down how it works: The Stimpunks Knowledge System. It holds our research library, our notes, and our highlights. It indexes itself, audits itself, backs itself up, and mostly runs without us.
This page is about what it has to do with learning.
We say that the way we work is the curriculum. We mean it literally. We are not describing a product that schools should buy. We are describing a practice — one a fourteen-year-old can start this week with a folder of files — and two things we think are worth teaching to anyone who will spend their life working with knowledge.
Neither of them is “how to use AI.”
Table of Contents
- The system, briefly
- Why a knowledge base belongs in an education conversation
- Teaching point one: help students cultivate a knowledge garden
- Teaching point two: teach change management and revision control
- The layers are a communication stack
- Own the garden, don’t rent it
- What the AI did, and what it did not
- Honest limits, for classrooms
- Start absurdly small
- Related reading
The system, briefly
Four layers of plain files, and one rule that holds them together.
The library is 338 original source documents, kept exactly as they arrived. Never edited, never renamed, never tidied. The index is written over the top of it — grouped into topic sections, every entry linking to the original. The index is generated, so it can be thrown away and rebuilt at any time. Alongside those sit working notes and a highlights archive of 12,878 passages from books and articles.
The rule: raw source material goes in one place and is never altered; everything derived goes somewhere else and points back at it.
That’s the whole architecture. Everything else — the automation, the weekly audit, the thirteen small tools that maintain it — is convenience built on top of that one decision.
If you want the implementation, the Field Guide page has it, including a section on what it can’t do and a section of portable ideas to take without any of our tooling.
Why a knowledge base belongs in an education conversation
Because school produces knowledge work and then throws almost all of it away.
Think about what happens to a student’s output over thirteen years. An essay is written, submitted, graded, returned, and lost. A project is built, presented, photographed, and binned. A set of notes is kept for a semester and abandoned. Thousands of hours of genuine intellectual labor, and at the end almost none of it is still in the learner’s hands, searchable, connected, or theirs.
We do not do this to professionals. A researcher keeps a bibliography. A lawyer keeps a file. A developer keeps a repository. The accumulated, organized, retrievable record of what you have read and thought is the working capital of knowledge work — and we hand students thirteen years of practice at producing it and zero years of practice at keeping it.
That is a design failure, not a student failure. Broken systems, not broken people.
Our knowledge system is the correction we made for ourselves, late, as adults, after a couple of decades of losing things. The two teaching points below are what we wish someone had taught us at the start.
Teaching point one: help students cultivate a knowledge garden
A garden is not an assignment folder
Our whole site is a knowledge garden — “a growing landscape of ideas, patterns, tools, and environments” rather than a filing cabinet. Ideas in it spread sideways and connect across domains instead of nesting in a hierarchy, because, as that page puts it, neurodivergent life is relational and ecological rather than neatly categorical.
Digital gardening is the practice of tending such a thing in public, over years. It is the old commonplace book — the notebook where readers copied passages worth keeping — with hyperlinks and a search box.
The distinction that matters for teaching is ownership and duration:
- An assignment folder is organized around deadlines and belongs to the institution. It is complete when the term ends.
- A garden is organized around interests and belongs to the gardener. It is never complete. That’s the point.
A garden accumulates. That is its entire advantage, and it’s the one thing a semester cannot demonstrate. Which is exactly why it has to be started early and carried between classes rather than assigned inside one.
A garden is a constructionist project that never ships
Constructionism — Seymour Papert’s extension of constructivism — holds that people build knowledge most effectively while actively constructing something meaningful in the world. Makerspaces are the familiar example. A knowledge garden is a less obvious one, and a better one for learners whose making is verbal, textual, or archival rather than physical.
The artifact being constructed is the learner’s own map of what they know.
It has every property a good constructionist project needs. It is personal, so no two are alike. It is externalized, so thinking becomes visible and therefore discussable. It grows by bricolage — assembled from whatever is at hand, in whatever order interest supplies. And it produces something with real value outside the classroom, which is the test experiential learning sets: projects should produce actual end products, not contrived ones.
Experiential learning is usually described as project, problem, passion, and purpose based. A garden is unusual in being all four at once, indefinitely:
- Project — there is always a next thing to build, index, or connect.
- Problem — “I know I read something about this, where is it?” is a real problem, encountered weekly, solvable by design.
- Passion — the garden grows fastest exactly where interest is deepest, and it rewards that rather than penalizing it.
- Purpose — you are building the thing you will use for the rest of your working life.
Gardens reward the way monotropic learners actually learn
This is the part we care about most, and the part most information-literacy curricula miss.
Monotropism describes attention that pools deeply in a few interests rather than spreading thinly across many. It is a core feature of Autistic cognition, and school treats it as a defect: too narrow, too obsessive, won’t move on when the bell rings, needs to be more well-rounded.
A knowledge garden is one of the few structures that treats depth as an asset. Follow an interest as far as it goes and the garden gets richer — not lopsided, which is the word a deficit lens reaches for when someone goes deep in one place instead of staying a broad generalist. A special interest becomes a region of the garden with genuine expertise in it. And because the trail stays where you left it, an interest you drop for two years is still there — annotated, linked, ready — when you come back. Nothing about that requires finishing on schedule.
Compare that to the ordinary treatment: pursue a tangent, get marked down for scope, lose the work at the end of the unit.
Depth is not a detour from learning. For a lot of us it is the only road that works. A garden is infrastructure for that, and it is cognitive liberty made concrete — your attention, spent your way, with something to show for it.
What AI is good for here — and what it isn’t
Generative AI is genuinely, unglamorously good at garden maintenance:
- Indexing a pile of files and grouping them by topic.
- Retitling documents that arrived named
s41562-019-0793-1.pdf. - Summarizing a paper you have already decided matters.
- Proposing cross-links between things you wrote months apart.
- Finding the passage you half-remember from a corpus too large to skim.
Every item on that list is the tedious curation work that stops most people from keeping a garden at all. Removing it is a real accessibility gain — for Disabled knowledge workers especially, where the barrier was never interest but the executive-function cost of filing.
Here is what it is not good at: deciding what matters. Judging whether a source is trustworthy. Knowing which of two framings is truer to your experience. Noticing that the thing you read contradicts something you believe. Those are the acts of learning, and they are the parts a student must own.
So the pedagogy follows the division of labor. Teach the practice first, then let the tool multiply it. These tools gave us leverage because there was already a corpus and two decades of habits for them to act on. Handed to someone with no practice, the same tools produce a tidy index of nothing in particular.
The strongest argument against AI replacing thinking is a student who has enough practice to direct it.
What a student’s garden can be on day one
Deliberately boring:
- One folder. Everything they read, save, or write goes in it, untouched.
- One index file, listing what’s in the folder with a line about why each thing is there.
- A habit of adding to both.
That’s it. That’s a garden. No app, no subscription, no AI. Plain text and folders outlive every tool you’ll use to read them, which is why our own system is built from them.
The index is where the learning shows. Writing “why this is here” for each item is a small act of synthesis, repeated hundreds of times. It is also, not coincidentally, the exact skill a citation is testing.
Teaching point two: teach change management and revision control
Get your shit in git
Version control is professional literacy, not a developer specialty.
Strip away the tooling and it gives you three things every knowledge worker needs: an undo that actually works, a written record of why each change was made, and a way for several people to work on the same thing without overwriting each other. Nurses, accountants, journalists, and playwrights all need those three things. Only one profession routinely gets taught them.
We put our knowledge system in git for an unglamorous reason: our note-taking app doesn’t back up its own external folders. But what we got was a complete history of every decision, and the ability to answer “why is this like this?” two years later. That second thing turned out to matter more.
A commit history is a record of iterations
Iteration is one of our load-bearing ideas. Cornelius Minor’s line, collected on that page, is as compact as it gets: “Learning is a series of iterations.” Not linear. Not first-try. A sequence of attempts, each one informed by the last.
Now consider how school usually evidences learning: a final artifact, submitted once, graded on its state at a deadline. The iterations — the false starts, the restructuring, the paragraph that got cut and was right all along — are invisible. We assess the last frame of the film and call it the movie.
A commit history is documentary evidence of iteration. It shows the attempts in order, with the reasoning attached. It is the most honest portfolio artifact I know of, and it is generated as a byproduct of doing the work rather than assembled afterward as a performance of having done it.
If you want students to value process over product, stop asking them to narrate their process in a reflection paragraph and give them a tool that records it automatically.
Version control is mercy, made structural
The iteration page also collects a line from Craig B. Smith about retesting: if you’re willing to work, “there’s always mercy.”
Version control is that sentence implemented in software. Every change is reversible. Nothing you try can destroy what already worked. The worst outcome of an experiment is that you revert it and know one more thing.
That is psychological safety as a property of the tooling rather than a promise from an adult. And it changes behavior in the direction every educator says they want: students who cannot lose their work take bigger swings at it.
There’s a related point about sharing. The creative process, as Brit Cruise puts it on that same page, comes down to getting good at sharing work in progress. Version control and its social layer — branches, pull requests, review — are the professional apparatus built precisely for that. Not “here is my finished thing,” but “here is what I changed, here’s why, tell me what you think.” That is a critique workshop with a paper trail.
Diffs are how a human supervises a machine
This is where the two teaching points meet, and it is the most practical thing in this piece.
Revision control is what makes AI collaboration safe.
You can let a tool make changes to your work when every change arrives as a diff — a precise, line-by-line account of what it did — that you can read, question, and revert. Without that, delegating to a machine means trusting it. With it, you are supervising it.
Our weekly audit is allowed to touch the system because everything it does lands in a commit we can inspect and undo. That is the entire basis of the trust. Not the model’s quality. The reversibility.
“Human in the loop” is a slogan in most AI discourse. It gets asserted, rarely specified. The diff is what makes it a mechanism instead of a posture, and it is teachable in an afternoon.
If a student is going to use these tools — and they are — the single most useful skill you can give them is the habit of reading exactly what changed before accepting it.
What this looks like without turning into a CS class
You do not need the command line, branching strategies, or merge conflicts. Aim at the concepts and let the tool be whatever is at hand:
- Version history in a shared document already teaches “see what changed and when.” Start there; it’s free and everyone has it.
- Have students write the reason for a change, not just the change. A commit message is a one-sentence rationale. That’s the transferable skill, and it’s a writing exercise.
- Practice reverting. Deliberately break something and put it back. The confidence this produces is out of all proportion to the effort.
- Then, for anyone interested, real git. A repository of their own garden, which also happens to be a backup, a portfolio, and a public presence if they want one.
The concept is change management. Git is one implementation. Teach the first; offer the second.
The layers are a communication stack
Something we noticed only after writing the design notes: the knowledge system is the storage end of a stack we already teach.
Our communication stack describes ideas moving through three levels — conversation, then discussion, then publication — at three speeds: realtime, async, and storage. The layers of the knowledge system map onto the slow end of that almost exactly.
| Stack level | Speed | In the knowledge system |
|---|---|---|
| Conversation | Realtime | Working notes — thinking out loud, provisional |
| Discussion | Async | The index and its authored guides — worked over, revised |
| Publication | Storage | The library, immutable, plus what we publish from it |
That page makes a point worth repeating in an education context: async and storage are not lesser speeds. For many Autistic and Disabled people they are the accessible ones — the register where you can compose a thought without racing the clock or the room, and where written communication becomes the great social equalizer.
Most schooling runs almost entirely at conversation speed. Discussion happens in a period, at volume, in a room, on the spot. Then the artifact is graded and discarded, so nothing reaches storage at all.
The same pattern shows up in caves, campfires, and watering holes, David Thornburg’s spaces for solitary reflection, gathering to learn, and peer exchange. A garden is cave infrastructure — the private place where external knowledge becomes internal belief — and school is chronically short of caves.
Building a knowledge system is how a learner gets a cave with a door, and a record that survives the term.
Own the garden, don’t rent it
Our technology page argues for indie ed-tech: tools learners build, own, and control on the open web, against platforms that do things to students rather than fostering agency. Giving someone their own digital domain, that page says, is a radical act.
Apply that to the garden and the stakes get clear.
A learning management system is the anti-garden. Work goes in, is graded, and cannot come out in any useful form. Cross-references don’t exist. Search is bad. And when the student graduates or the district changes vendors, the whole accumulated record evaporates — not maliciously, just because nobody designed for the student keeping it. Thirteen years of knowledge work, rented, then repossessed.
Our system is plain files in ordinary folders. There is no vendor, no login, and no format that needs an application to open. It can be read with a text editor in ten years, moved to any machine, and inherited by anyone. That is not nostalgia for simple tools. It’s the only property that makes a thirty-year garden possible.
Toolbelt theory finishes the thought: learners should assemble their own toolkits rather than receive a standard-issue one. Which means the goal is not for students to use our stack. It’s for them to have a stack. The Field Guide page ends with eight portable ideas for exactly that reason — none of them require our tools, and none require AI.
What the AI did, and what it did not
We should be precise, because this is where education conversations about AI usually go wrong in both directions.
What it did. Wrote the index over the library. Analyzed documents to work out what they were. Proposed categories. Drafted the design notes. Audits the system weekly for broken links, stale counts, and contradictions. Wrote most of the tooling.
What it did not. Choose a single source. Decide what we believe. Alter any original. Approve its own risky changes. Write anything published in our voice without a human rewriting it.
Two boundaries do the work. First: AI writes the index, never the sources. The originals are immutable, so every derived claim can be checked against something a human put there. Second: a human holds every risky decision. The audit sorts what it finds into apply-now, needs-my-signature, and ask-me-a-question. Broken links get fixed on autopilot; anything structural waits for a checkbox.
We are wary of techno-solutionism and technoableism, and we are not going to pretend a folder structure fixed anything structural. This did not create capacity. It stopped us from spending the capacity we have on re-finding things we already had. Our AI collaboration guidelines go further into where we draw lines.
The reason this is worth showing to educators is not that AI built it. It’s that the boundaries are written down, enforced by the tooling, and legible to anyone who wants to check.
Honest limits, for classrooms
We put an honest-limits section on the design notes, so here’s the version for anyone thinking about handing this to students.
- Grading a garden would kill it. The moment it’s scored, it becomes an assignment folder with extra steps and gets optimized for the rubric. Whatever this becomes in a classroom, it has to stay the learner’s.
- Access to these tools is not evenly distributed. Any plan that assumes every student has a personal machine, reliable connectivity, and an AI subscription is a plan that widens a gap. The paper-and-folder version has to be first-class, not the fallback.
- Privacy is a real problem here. A garden is a record of what someone has been thinking about. That is exactly the sort of data that should not be casually visible to a school, a vendor, or a parent by default. Private by default, published by choice.
- Dependency is a genuine risk. A student who has only ever had a machine index their reading has not practiced deciding what matters. The order — practice first, tool second — isn’t a preference. It’s the safeguard.
- We have not tested this with students. We built it for a small Disabled-led nonprofit, and we’re reasoning outward from that. Treat everything above as an argument, not evidence.
- Our own bus factor is still low. The library and index are readable by everyone on our team; the machinery is understood in depth by one person. We’re documenting our way out of that, and it isn’t finished.
Anyone who tries this with actual learners will find out things we can’t. We’d like to hear them.
Start absurdly small
If any of this appeals, the on-ramp is a single week and no budget.
- Make one folder. Everything a student reads or writes goes in, unmodified.
- Make one index file. A list of what’s in the folder, with one line each on why it’s there. Written by hand.
- Turn on version history, in whatever they already use.
- Once — deliberately — break something and put it back. Then talk about what that means for how much risk they can afford to take.
- Only then introduce a tool to help with the indexing, if you want to at all.
Steps one through four contain the entire lesson. Step five is a convenience.
The measure of a garden isn’t how clever the tooling is. It’s whether the person who made it can find what they need on a day when nobody is around to ask — and whether it’s still theirs in ten years.
Related reading
Ours
- The Stimpunks Knowledge System — the design notes, including honest limits and eight portable ideas
- Our Knowledge Garden — how the whole site is organized as an ecosystem
- Our Technology — indie ed-tech, and the case against renting your work
- Our Learning Space — the pedagogy this all sits inside
- Communication Stack — conversation, discussion, publication
- AI Collaboration — where we draw our lines
Concepts