This Word Does Not Exist's forward model goes from a word to its definition, not the other way

Three files in a bucket, and the forward model runs backwards from its name

The pre-trained artefacts are three files in one bucket, and two of them are a matched pair.

The pair is a forward model and an inverse model, both at version one. The interesting part is the direction, because it does not match the usual sense of the words. The forward model is labelled as going from a word to a definition. The inverse model is labelled as going from a definition to a word.

So the model that invents a gloss runs forward, and the model that invents a term from a gloss runs inverse. If you are wiring these into anything, that is the detail to copy rather than the filename.

The third file is a blacklist, stored as a compressed pickle rather than as a text list, and it is the only artefact whose purpose the page does not explain. It is passed to the class as a path alongside the two models, so it is clearly load-bearing, but nothing on the page says what it filters. Given that the project's stated output is a word that does not exist, the obvious guess is a list of words that do exist, and that guess is not confirmed anywhere.

All three are hosted as plain files rather than served through a model repository client, so there is no revision handling, no manifest and no checksum. The filenames carry a version, which is the only versioning these artefacts have.

The constructor takes three paths and a quantization switch, on a CPU by default

The whole interface is one class and three methods, and the example is short enough to read in full.

from title_maker_pro.word_generator import WordGenerator
word_generator = WordGenerator(
  device="cpu",
  forward_model_path="<somepath1>",
  inverse_model_path="<somepath2>",
  blacklist_path="<blacklist>",
  quantize=False,
)

Three things to note. All three artefact paths are constructor arguments, so the class does not download anything and the caller owns the files. The device is explicit, and the example sets it to a CPU. And quantization is a constructor option rather than a load time flag, which means the decision is fixed for the lifetime of the object.

The three methods map one to one onto the two models and the blacklist.

The no-argument method generates a word from scratch, with no input at all. The second takes a made up word and returns a definition for it, with the example value being a string of invented syllables. The third takes a definition as free text and returns a new word, and the example definition is the phrase that names the project.

So the class is a pair of models with a shared constraint, and that constraint is the blacklist.

The CPU default is not incidental. The dependency list for the model side is a conda environment file, and its name says what it is: it is a deployment environment built for CPU. There is no GPU path documented anywhere, which is consistent with a project whose model files are small enough to download by hand and whose point is the generated text rather than the throughput.

The training corpus is a macOS system path and a scraped user submitted site

Training a model here starts the same way every time: find a dictionary first. There are two sources the project provides code for, and they are very different in kind.

The first is the system dictionaries that ship with macOS. The extraction code is named for it, and the example path it points at is inside the operating system's asset directory for the dictionary services. That is not a corpus you download; it is a directory that exists only on a Mac, in a location controlled by the system, with a naming convention that is Apple's rather than the project's. Extracting from it is therefore a macOS only activity, and anything the resulting file contains is a question the page does not address.

The second source is the opposite in character. A separate script is named for a well known user submitted dictionary site, which is a website of definitions written by volunteers. So the training data is a mix of a licensed operating system asset and a scrape of user generated text.

Neither of those is a standard linguistic corpus, and neither has a licence, a version or a date attached to it in the documentation. The page says only that you need to find a dictionary and that code exists for these two.

That is the gap to notice. The rest of the project is unusually well specified: three files with explicit paths, a class with a fixed signature, a training script and a sample run. The input to that pipeline is two scrapers pointed at sources with unclear terms, and the sentence introducing them is two lines long.

Notebooks for raw thoughts, one training script, and a sample run you can read

The training side is described in three steps, and one of them is an invitation rather than an instruction.

The first step is the notebooks. The page points at a directory of them and describes the contents as raw thoughts, which is a candid way of saying they are the author's working material rather than a tutorial. That makes them worth reading for the reasoning and not worth following as documentation.

The second step is the dictionary, covered separately, which is the part with the tooling.

The third step is the training script, and here the naming is helpful. One file is called the master training script, which identifies it as the entry point rather than a variant. A separate shell script is linked as a sample recent run, and it lives in a scripts directory rather than beside the training code.

That pairing is the most useful thing in the training section. A master script tells you what the pipeline does; a recorded run tells you the arguments, the ordering and the flags that were actually used. The gap between them, if there is one, is where your own run will differ.

What is not given is any statement about cost, data volume, or how long a run takes. The training code sits in the same package as the inference class, which tells you the two halves of the project live together but says nothing about the resources one of them needs.

The website is a separate application with a dev tool installed outside its own requirements

There are three user-facing surfaces and they are built three different ways.

The first is a website, given a hostname, which is described as a demo of the project. Its development instructions are four lines and they are the only commands in the documentation that describe running something.

cd ./website
pip install -r requirements.txt
pip install aiohttp-devtools
adev runserver

Two observations. The site is an asynchronous Python application, since the dev tool installed is the development server for one. And the dev tool is installed on its own line, after the requirements file, rather than being part of it. So the documented development setup is the requirements file plus one package you add by hand, which is a small trap for anyone following it exactly and then wondering why a script is missing from a lock.

The second surface is a social media account, described as a bot demo, which is a third implementation of the same generation code with a different front end.

The third is the library itself, which is the one with a real interface.

So the project ships a web demo, a bot demo and a Python class, and each is a separate entry point into the same two models. The web demo is the one a visitor can see, the bot is the one that is public, and the class is the one with a documented signature. Only the class has documented dependencies.

Two packages at the root, a build config, and a docker ignore file with no image beside it

The repository layout is where the missing pieces become visible.

There are two Python packages at the top level. One of them holds the word generator, the dictionary extraction code and the training script, so it contains both halves of the pipeline. The other has a name that describes a service rather than a library, and nothing in the documentation mentions it.

Alongside them are a notebooks directory, a scripts directory, a deployment directory, a cloud build configuration, an environment file and two ignore files.

The environment file is one of the more informative files in the tree. Its name says it is a CPU deployment environment, and the documentation points at it as the place where the model side's Python dependencies live. So the environment is a single file at the repository root, named for the deployment target, and it is what you use instead of an install command.

The cloud build configuration and the deployment directory together describe how the web side is built and hosted. The second ignore file is the one that does not match anything: there is a file that tells a build to leave certain paths out of a build context, and no container recipe in the top level entries. Either the recipe lives inside the deployment directory or one was removed and the ignore file stayed behind.

For a project that is otherwise four files and a class, that is a reasonably large amount of build machinery, and none of it is documented beyond the cloud configuration's existence.

A single invented word in the documentation, on a master branch with no releases

The last details are small, and together they say what kind of repository this is.

The documentation offers exactly one example of the output. A single invented noun, given with a gloss defining it as a lack of sincerity or candor, and an example phrase using it in a sentence about manner of speech. So the project demonstrates its output once, in a format that shows all three things it generates: the word, the definition and an example sentence in context.

That is the only worked example in the whole document, and it is doing a lot of work, because the three-artifact pipeline, the training path and the class signature are described far more precisely than the output is.

The branch is named the older way rather than the current one, which is a small signal about when the project was last restructured. The last push to the default branch is recorded as 2026-06-17 and the repository is not archived.

There are no GitHub releases. So unlike a project that tags its model files, this one has no version history you can point at, and the only versioning anywhere is the version suffix inside the two model filenames and the numbering on the notebooks and the training script.

The licence is MIT and the repository description is the project's own name repeated, which is the least informative field on the page. The two demos, the website and the bot, are the only places a non-developer would ever encounter this work, and both of them are described in a single line each.

Editorial conclusion

This is worth trying if you want to see what a language model does with a small, oddly sourced corpus, and the class interface is small enough to read in a minute. Three things to check before you build on it. The two model files run in opposite directions from what their names suggest, so read the arrow in the documentation before wiring one in. The two dictionary sources are a macOS system path and a scraped user submitted site, and the page says nothing about using either of them, which is a question to settle rather than assume. And there is no release history and no build image, so you are downloading three files from a bucket by hand and running inference from source.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. turtlesoupy/this-word-does-not-exist on GitHub