NovelForge: Schema-Driven Card Generation for Million-Word Fiction Projects

The problem NovelForge targets: consistency across hundreds of chapters

Long-form AI fiction breaks in a predictable way. The model forgets a character's eye colour, contradicts a relationship established forty chapters earlier, or returns prose that looks fine until you try to file it. NovelForge's README names these three pressures directly: maintaining consistency, keeping control, and sustaining inspiration. Its answer is to stop treating generation as a single text blob and start treating it as data with a shape. Each unit of the novel (a character, a scene, an organisation, an item, a concept, a chapter draft) is a card, and each card type can carry a Schema. The README states that AI generation is validated against that structure, which the project frames as reducing output that looks usable but is messy once you try to store it. The intended user is not someone writing a short story in one sitting. It is someone building a project large enough that a knowledge graph and a context-injection language become worth the setup cost.

Cards, schemas and the @DSL context pipeline

The core mechanism is a card store plus a context assembler. Cards are typed and schema-defined, so a character card and a scene card have different fields, and generation is expected to fill those fields rather than free text. The README describes the generation flow as field-granular streaming: you enter a requirement, fields fill progressively inside the dialog, and you confirm or feed back to continue. That session ends when the dialog closes, which is a deliberate scope limit rather than a bug. Context injection happens through an @DSL that references project data, so a prompt can pull in specific cards instead of dumping the whole project. On top of that sits a relationship graph with dynamic information, which the README says keeps later generation closer to what has already been written and to established character relationships. Version 0.9.4 extended this to scene, organisation, item and concept cards, and unified extraction into a preview-then-confirm flow: extraction runs against the current chapter text, you see a preview, you can adjust it manually, and only then does it write back to cards or the graph. That human checkpoint is the most defensible design choice in the project, because automatic graph writes from model output are exactly where silent corruption would enter a long manuscript.

Running it: ports, LLM configuration and the .env keys

The README's run guide is the place to start, and the release notes add two concrete configuration points. Version 0.9.7 introduced a backend port setting read from backend/.env under the key APP_PORT, with a default of 54321 and validation in the 1-65535 range. That is the one config key the release notes state explicitly. Version 0.8.2 mentions an .env setting for the maximum number of retries on assistant tool calls, though the exact key name is not given in the material available here, so check the repository's .env example before assuming it. Model setup happens in the LLM configuration page, and 0.9.6 added a capability test there that probes basic chat, streaming, structured output and tool calling. Run that test first: NovelForge depends on structured output, and the release notes themselves recommend setting DeepSeek and Qwen style providers as OpenAI-compatible while reserving the OpenAI provider entry for official models such as GPT-5. Version 0.9.2 mentions one-click front and back end startup, and 0.9.0 notes that the 0.9.x line changed the database enough that older files may not open directly, with a migration script published but explicitly not guaranteed to succeed. Back up the database file before attempting it.

The code-style workflow engine and where it is fragile

Version 0.9.0 replaced the old DAG editor with a code-style workflow model using Python-like statements and a special marker DSL. The README is unusually candid about this trade. On the plus side: linear logic, a Logic.Wait primitive for sequencing, an async=true flag for asynchronous steps, and a claim that a feature expressed in a few dozen lines of code often needed hundreds of lines of nodes and edges in the old DAG form. On the minus side, the README states plainly that code-style workflows are less visual than a DAG and more sensitive to string and code formatting, with parameter serialisation, dictionary field types and variable references being the usual sources of validation or runtime errors. That is a real cost. Non-programmers who could drag nodes will find this harder. The mitigation is a workflow Agent that takes a natural-language description, generates or edits the workflow code, validates it, and offers a preview before applying changes. The README itself flags that the Agent may still have bugs, and the 0.9.0 notes describe the whole migration as exploratory.

Chapter length control and the token cost you pay for it

Version 0.9.3 collapsed chapter continuation length control into two modes, and the distinction matters more than it looks. In prompt-constrained mode, the word count is only expressed in the prompt. The README says the text reads more naturally and costs less, and that this suits cases where exact length is not critical. In control mode, the target total is split into multiple rounds with allocated budgets, which the README says gives steadier length control at the cost of more tokens. Control mode currently uses a fixed multi-round budget strategy. There is no adaptive budgeting described, so a very long chapter means a fixed number of passes regardless of how the earlier passes actually landed. If you are paying per token on a long manuscript, that is the setting to watch, and the honest framing is that you are trading money for predictability rather than getting both.

Review, memory extraction and the graph backend choice

Review was reworked in 0.9.3 into a single pattern: generate a review draft, then confirm it as a review result card. Different card types can use different review prompts, but the result card structure stays the same, and result cards are archived automatically into a root-level review results folder. The same release notes state that review results no longer depend on the old record model. Memory extraction in 0.9.4 covers character dynamic information, relationship extraction into the graph, and scene, organisation, item and concept state. The README adds a caution worth repeating: these lightweight state and memory features are meant to be used on demand, not all at once, to avoid inflating context complexity. On storage, 0.9.1 added SQLite support for the relationship graph while remaining compatible with Neo4j. That is a genuine fork in the road. SQLite keeps the deployment to a file with no separate service, while Neo4j suits graph queries at a scale SQLite will not handle comfortably. The material does not give thresholds for choosing between them, so that decision is yours to make from your own project size.

Alternatives and the licence boundary

The obvious comparison is a general-purpose assistant such as a chat interface with a long context window. That approach has no schema, no card store and no graph, so consistency is maintained by pasting more text into the prompt. NovelForge's difference in approach is that consistency is enforced by structure and retrieval: the @DSL pulls named project data, and the graph records relationships that later generation can reference. The cost is setup and rigidity. A second comparison is a plain outliner or wiki with a separate AI plugin. That gives you stable storage and no schema validation, so AI output arrives as text you file by hand. NovelForge trades that manual filing for a validation layer and a migration risk each time the schema changes. On licensing, the repository is AGPL-3.0. If you run a modified version as a network service, the licence's network clause is the part to read, and that is a question for your own legal review rather than something this article can settle. For private manuscript writing the obligation is minimal; for embedding NovelForge in a hosted product it is not.

Maintenance cost and what to verify before you commit a manuscript

The release cadence visible here is roughly monthly through 2026, with 0.9.5-1, 0.9.6 and 0.9.7 landing between May and August. That pace is a signal about stability: 0.9.0 changed the database enough to require a migration script, and the notes warn that the script may fail and that you should back up the db file first. A tool that stores your novel in a schema that shifts this often carries a real upgrade tax. The 0.9.7 notes show the maintainers adding safety constraints against deleting built-in resources or overwriting user modifications, and distinguishing custom, built-in and modified states, which suggests the upgrade path is being taken seriously. Still, the practical test is to run one project through a full version bump before you trust it with a manuscript you cannot afford to lose. Verify three things in this order: that the migration script runs cleanly on a copy of your database, that your chosen model passes the LLM configuration page capability test for structured output and tool calling, and that your graph backend choice holds up at your project size. NovelForge is a serious attempt at a hard problem, and the README documents its own weak points more honestly than most projects do. That honesty is not the same as a stability guarantee.

Editorial conclusion

Adopt NovelForge if you write long fiction and want every AI output to land in a typed, reviewable card rather than a chat transcript, and if you accept AGPL-3.0 and a fast-moving 0.9.x schema. Do not adopt it if you need a stable database across upgrades or a permissive licence for closed distribution. Before committing a manuscript, verify the migration path from your existing database, confirm which graph backend you will run (SQLite or Neo4j), and test your model in the LLM configuration page for structured output and tool calling.

Official sources

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. RhythmicWave/NovelForge on GitHub