Lexora

Most vocabulary tools ask a learner to re-enter a list they have already written. Lexora imports the list as it stands and splits each line into a structured entry — alternatives, word families, grammar patterns — with a confidence score on each split.

A line it cannot split confidently is not guessed at. Those are collected on a review screen to be corrected in a few seconds, and everything else imports straight through. The same restraint governs imagery: illustrations are used where a picture teaches the word and deliberately omitted where it would teach the wrong thing.

Every answer updates two numbers for a word: how stable the memory is and how hard the word is for that learner. The next review is placed where recall is predicted to fall to ninety percent, so easy words step back and stubborn ones return quickly.

That is the difference between a review queue and a schedule, and it is the reason the backend has to be reliable about ordering — a review placed against a state that was never durably committed is a review placed against nothing.

An event-driven core has one recurring correctness problem: a state change is written to the database and the event announcing it is published separately, so a crash between the two leaves the system telling a story its own data does not support.

Lexora commits the state change and the events it produces in the same transaction, through a transactional outbox. Either both happened or neither did. Publication becomes a separate, retryable step that can fail without producing a lie.

Background workers do the slow work, so a request returns when the state is durable rather than when everything downstream of it has finished. This is what keeps the interactive path predictable while the amount of work per change grows.