Collections
A Collection is a self-contained body of Kioku work, fully isolated from every other Collection.
Most people never need more than one. Collections exist for the times when two bodies of work should not mix — a language deck that shouldn’t surface during work study, a throwaway experiment you want to keep out of your real review history, or a dataset you intend to hand to someone else as a file. Because each Collection is its own space, that isolation is built in rather than a filter you have to remember to apply.
What a Collection contains
Section titled “What a Collection contains”A Collection is everything that makes up a working set, stored together:
- Content — every Element (your Topics, Extracts, and Items), the Cards that render them, and the Sources they were imported from.
- Review history — the record that drives scheduling, so each Collection keeps its own log of what you reviewed and when.
- Scheduling parameters — the tuned scheduling settings and your desired retention target live per Collection. Two Collections can be tuned differently, and running the parameter optimizer in one does not touch the other.
- Settings — most preferences (queue limits, review rhythm, theme and color scheme, onboarding state) are stored per Collection, so they travel with it.
Media (such as occlusion images) is kept in a folder that sits alongside the Collection rather than inside it. That distinction matters when you move a Collection around; see Back up and export.
Switching Collections
Section titled “Switching Collections”Switching the active Collection points Kioku at the target Collection. Everything that depends on your data — scheduling, review and the queue, undo and reschedule, importing — operates against the new Collection and never carries state from the old one.
The interface resets in step. When a switch happens, Kioku clears the in-memory state of the Review, Browse, Reader, and Plan views, re-applies the theme from the new Collection’s settings, reloads the Collection list, and returns you to the dashboard.
The guarantee this gives you is the one in the glossary: Collection switching resets things so no state leaks between Collections. A Queue assembled in one Collection cannot bleed into another, and an undo in one can never roll back a Review in another.
When to use more than one
Section titled “When to use more than one”Reach for a second Collection when the work genuinely should not share a queue or a history:
- Unrelated subjects you want scheduled independently. Separate review streaks, separate due counts, separate optimizer runs.
- A sandbox. Try out import modes, the cloze workflow, or scheduler settings without polluting your real review logs.
- Data you’ll hand off. Because a Collection is a single file, you can export one and give it to someone else, or import one they send you.
Prefer a single Collection when your material is related enough that interleaving it in one Queue is a feature, not a problem. Incremental reading is at its best when reading and recall across your subjects mix in one session; splitting that across Collections fragments the very interleaving that makes it work.
Related
Section titled “Related”- Back up and export — export a Collection as a file, import one, and keep snapshots.
- Data locations — where your Collections, media folders, and backups live on disk.