Book Payoff: designing a smarter vocabulary triage system for Ember Reader

Ember Reader already does what a reading app with lookups is supposed to do. You tap a word, get a translation or explanation, save it, and review it later. That works. It is useful.

But the longer I sit with it, the less I like the word saved. It hides too much.

A saved item can be a word that clearly matters and will keep showing up for the next hundred pages. It can also be a word that helped you through one muddy sentence and will never matter again. It can be something interesting but peripheral. Something you want to keep near you without turning it into homework.

A lot of reading apps treat those cases as if they were basically the same. One action, one bucket, one implied future: review.

I do not think that is quite right.

Save, Inbox, SRS

The distinction I keep coming back to is simple enough that I almost distrust it:

Save — don't lose this.
Inbox — decide what is worth learning.
SRS — I'm willing to keep paying for this.

That last line is the important one. SRS is not free. It costs time, attention, and a little mental space every time an item comes back around. Not dramatic each time, but real — and it compounds once enough items pile up.

Save is lighter. Save belongs to the reading moment. You are in the middle of a paragraph, trying not to lose the thread. In that moment, the real question is not "should this become a flashcard?" It is smaller and more immediate: "Do I want to keep track of this?"

That is what saving is for.

Inbox is different. By then the item is out of the sentence and out of the pressure of reading. Now there is room for judgment. Does this deserve review? Light review? No review at all? Was it just useful once? Is it the kind of thing that will pay me back if I learn it?

That is where the interesting design space is.

For a while I kept framing this as a smarter Save button — one that already knows something, that hints whether a word is worth keeping. The more I thought about that, the less I liked it. I do not want Save to become heavy. I definitely do not want the app arguing with the reader in the middle of reading, like some tiny bureaucrat leaning over the page.

Inbox is a better place for intelligence, because Inbox already implies unfinished business. It already means: this is here, but we have not decided what it becomes.

So the idea I am actually interested in is not "smart save." It is smarter triage between Save and SRS.

Book Payoff

The question I want Ember Reader to ask is not just: is this word unknown?

That question sounds reasonable, but it does not get you very far.

The better question is this: if this word sticks, how much easier does this book become?

That is what I mean by Book Payoff. Not a precise score — just a heuristic about how much learning a particular item is likely to help with this particular book.

That last part matters more than it first seems.

Think about a novel set in a specific historical trade or subculture. The vocabulary of that world might almost never appear in everyday language, but it repeats across every chapter, anchors scenes, and makes whole passages click once it stops feeling unfamiliar. If you only look at global frequency, you miss it entirely. A word can be unimportant in the language overall and still be high-value inside one text. Reading tools should care more about that distinction.

Rereading is where this idea becomes especially interesting to me. Some items are worth learning not because they rescue the current sentence, but because they would make the next encounter with the book noticeably better. A word can be high-value because it helps unlock the world of this book, not because it ranks well on a general-purpose frequency list. That distinction matters.

What the system would actually look at

The obvious signals first:

• How often does the lemma appear?
• Is it spread across the book or concentrated in one section?
• Will it come back in chapters the reader has not reached yet?
• Does it appear in repeated phrases or recurring situations?

Then sentence-level context. A word pulled from an otherwise clear sentence is often a better study candidate than one pulled from a paragraph that was opaque end to end. If everything around it was murky, isolating one item may not be especially meaningful.

Then there are user signals: has this item been saved before? Is it already in review? Does it keep showing up as a friction point?

None of this needs to be perfect to be useful. Even rough heuristics could make Inbox noticeably smarter.

Not a filter — an intensity gradient

Once you start thinking this way, something else becomes hard to ignore: the problem is not just which items survive triage. It is how much intensity each item deserves.

The blunt version is binary — into SRS or not. Real reading is messier than that. Some items deserve strong reinforcement. Some deserve a lighter touch. Some are worth keeping without turning them into recurring chores.

People save things for curiosity, uncertainty, partial understanding, emotional resonance, or just the vague feeling that something matters before they can explain why. I do not want the system flattening that into yes or no.

What I want is a better handoff from raw saving to deliberate learning. Save freely. Decide later. Let the system help without pretending it should be the final authority.

V1: what I can actually build

This whole thing can sprawl fast. Global frequency models. Better lemmatization. Difficulty scoring. Adaptive review tracks. All interesting. All also a good way to vanish into complexity and never ship anything.

The goal here is not to add a feature for the sake of having one — not to sprinkle "intelligence" over vocabulary saving and pretend that counts as product thinking.

So the V1 I can actually imagine building is much smaller:

Index the book on import. Count lemma recurrence and rough spread. Put a plain Book Payoff label on saved items in Inbox. Keep the human in charge.

Even that small change would feel meaningfully different. Instead of staring at a flat list of saved words with no signal, a reader would see which items are likely to keep paying off — and which ones mostly did their job in the moment they were saved.

That is enough to test whether the idea has teeth. Later — explanations, sorting, filters, different review intensities. But the first version does not need to be ambitious in every direction. It just needs to make the decision point a little less dumb than it is now.

A lot of systems are good at helping you collect words. Far fewer are good at helping you decide what those words should become.

Reading gives you uneven material. Some encounters are rich. Some are incidental. Some are worth carrying forward. Some are worth carrying lightly. Some mostly belong to the moment you hit them. If Ember Reader can get a little better at telling those apart — even imperfectly — it starts becoming more than a reader with lookups and review. It starts becoming a tool that understands something about how reading-driven learning actually feels from the inside.

That is the direction I want to push.

Not "AI decides what you learn."
Not "save less."
Not "everything becomes a flashcard."

Just this: help the reader move from saved vocabulary to chosen vocabulary, with real attention to what will actually pay off in the book they are reading.