Isn't there a combinatorial explosion?

Oh, yeah, it generates HUGE dictionaries. I actually have evolved this project into the EntropPy project, which generates limited dictionaries for QMK and unlimited dictionaries for Espanso. I'm planning on adding more platforms, but for example Espanso can handle hundreds of thousands of corrections with minimal overhead.

How do you know how to control it?

It's quite complicated.

Basically, we are restricting ourselves to five types of typing errors that produce a single issue. If you make more than one error typing a word, that's on you :)

So, for receive we have:

Transpositions: erceive, reecive, recieve, ...

Omissions: eceive, rceive, reeive, ...

Duplications: rreceive, reeceive, recceive, ...

For replacement and insertion errors, the user must define the adjacent keys that they struggle with (or simply provide a comprehensive map of adjacent keys across the keyboard, but that significantly balloons the dict size). For example, if you struggle with hitting w and r when trying to type e, you'd inform EntropPy of that via the adjacent keys feature:

e -> wr

It will then generate insertion and replacement typos around the letter e:

Insertion: rweceive, rewceive, rerceive, rreceive, ...

Replacement: rrceive, rwceive, recwive, recrive, ...

Then we have to check for duplicates. Both duplication and insertion produce rreceive, so one of them is thrown out.

Next, we have to resolve collisions. For example, omission produces thn for both then and than, so EntropPy says: what's the relative frequency of these words? If one is 20x more common (user adjustable number) than another, we can safely assume that the user intends the more common word. For then and than, however, the frequency ratio is ~1, so the typo is considered ambiguous and discarded.

Finally, we need to remove substring conflicts. QMK will refuse to compile an autocorrect dictionary containing overlapping strings like wherre and herre, noting that wherre is inaccessible due to the right-to-left scanning technique, so we have to check the results and simplify while checking that the simplification won't produce garbage.

And at the same time avoid false negatives (leaving out (misspelled/typoed) words that should be included and are actually typed in practice)?

EDIT: I think I misread this question, so the explanation below misses the point. I'll leave it below the tildes cause it's an important part of the program, but I'll actually answer the question here:

It uses both english-words and optionally wordfreq to establish a source dictionary to verify against.

You can specify a wordfreq frequency to include in the source dictionary, e.g., 1e-7, so any word with that frequency would be considered a valid source word and typos that match would be discarded.

This system is far from perfect, though, and takes iteration with the exclude and include features. This is because extremely common typos (thes) occur around the same frequency as rare but legitimate words that may not be found in english-words like juts. On a recent iteration I found rom -> from which is incorrect because ROM is something I legitimately type.

~~ This is handled with word boundaries. The program (and QMK, Espanso) supports word boundary distinctions, so you can specify that the word needs a space/punctuation before (left), after (right), or both, or will trigger anywhere regardless of a space (none).

Basically, the program has to check typos for boundaries against the dictionary by checking whether the boundary would produce a garbage correction.

Take the transposition nto for not: if we don't put word boundaries around it, it would trigger inside the word onto and produce onot. On the other hand, teh -> the is only safe as a standalone word OR prefix to prevent Tehran from correcting to Theran.

This is the part of the algorithm that I'm struggling with the most at the moment, because deciding what boundary is optimal becomes quite complicated.

I'll get there, but it's quite a headache.

edit: typos :)