LoreWeaver Architect : everything it does

Upload the documents you already wrote. Plain text, Markdown, and XML are read directly, and images go through OCR so that text living inside a picture (a scanned page, a map, a photographed notebook) arrives as prose like everything else. No restructuring first.

Documents in the hundreds of thousands of words are split on paragraph boundaries rather than at a fixed offset, which is what keeps a long contiguous passage from timing out an extraction or being cut through the middle of a sentence.

Build a selection in the file grid with Ctrl or Cmd click, then act on the whole set at once: mark ready, mark not ready, or delete. The action bar shows the count, delete is confirmation-guarded, and a partial failure reports the file that could not be removed rather than rolling back the ones that could. Bulk actions issue one request for the selection instead of one per file, which is the difference between toggling forty documents and toggling forty documents forty times.

Lore is sliced into overlapping chunks sized to the model's context window, roughly 2,000 tokens with about 15 percent overlap and a hard ceiling of 20,000 characters per chunk. The overlap is what preserves an entity's context when it straddles a boundary. The ceiling is what stops one enormous paragraph from blowing the request.

Each lore document carries a ready flag, and only ready chunks feed entity extraction. That single switch is how you aim the pipeline: park the drafts, mark the canon ready, and the AI only ever reasons over the material you meant it to.

Every extracted entity records which chunks of which document contributed to it. That is a provenance trail running from a row in your export back to the sentence in your lore that produced it, which is what makes an extracted world auditable instead of merely plausible.

Architect reads your uploaded lore and proposes entity types and fields that fit the world you actually wrote rather than a generic template. A courtly political epic and a survival sim do not deserve the same schema, and they do not get one.

Start from a valid five-type baseline instead of an empty file: Character, Location, Item, Arc, and Beat. It is a real schema, not a placeholder, and it works with every schema operation from the first click.

Bring a schema you already have. SQL DDL, JSON Schema, Prisma schema, Markdown tables, and YAML are translated into Architect's format by the AI. A schema Architect itself produced is recognised by its own signature and imported directly, with no AI round-trip and no cost.

Download the current project schema as an XML file straight from the schema view, so the structure of your world is portable and reviewable outside the tool that made it.

Rename a field, change its type, rewrite its description, toggle whether it is required, or edit its allowed values, and the change propagates to every existing entity of that type. A schema edit is a revision, not a fresh start.

A field can be constrained to a defined list of allowed values, enforced in the exported schema as a restriction rather than left as free text. This is what stops "faction" arriving in your engine as forty spellings of six factions.

Reorder entity types by dragging. The order persists per project and is applied consistently across the schema view, the entity list, and the sidebars, so the thing you care about most is where you put it.

Removing an entity type asks first. Core fields can still be deleted, but they warn plainly about what depends on them rather than silently refusing. You are trusted with the sharp tools and told where the edges are.

Architect reads every ready chunk and produces typed entities with their fields filled from the text. Hundreds of entities out of a long document in a single pass, every one of them editable afterwards.

Running extraction again merges new findings into the entities you already have instead of overwriting them. There is no separate update step and no reset: re-running always adds and refines. That is what lets a project keep absorbing new lore for as long as it lives, rather than being a one-shot import you can never repeat.

Scope a run to specific entity types. The prompt is restricted to the types you asked for, and a post-filter discards anything outside them even if the model ignores the instruction, so a targeted run stays targeted whatever the model decides to volunteer.

A truncated or malformed model response no longer fails the whole job. The extractor recovers what it can and carries on. In a hundred-chunk document, one bad response used to cost the entire run.

Ask for what you mean, not what you typed. A natural-language search runs over the project's entities grounded in the lore itself, so it surfaces entities related by narrative context rather than by name match: "everyone present at the betrayal" finds the people the lore puts at the betrayal, even when not one of them has a word of your query in their name. It reasons chunk by chunk across every ready chunk rather than truncating the lore to fit one context window, so evidence buried on page 300 counts as much as evidence on page 1. Proposed matches are validated against real entity ids, so a hallucinated result is discarded before you ever see it. It is a distinct mode: the ordinary text field still does plain substring matching and never calls a model.

Fold duplicate records into one. Long lore spread across many documents reliably produces the same character three times under three spellings. Merge is how that becomes one canonical entity without discarding what each mention contributed.

Give an individual entity its own icon and colour, overriding its type's defaults, so the ones that matter are findable at a glance in a list of hundreds. AI-suggested icons are validated against the canonical icon set before they are applied, so an invented icon name never reaches the interface as raw text.

Entities reference each other by name through the earlier steps, and this step resolves those names into identity-based links. "Captain Vane" in a paragraph becomes an actual edge to the actual Captain Vane record, and from that point on the graph no longer depends on spelling.

Narrative structure uses named relationship types rather than one catch-all "connects to": a beat belongs to an arc, a beat follows a beat, an action hangs off a beat. Because the type is explicit, the narrative board and the filters read your structure instead of guessing at it.

The graph is editable, not just viewable. Connections are clickable, their type and description can be rewritten in place, and the edits persist. Filters narrow a dense graph down to the relationship types you are actually thinking about.

A visual canvas for the Arc to Beat to Scene hierarchy. Drag entities in from the explorer, connect them, and lay the story out spatially. Node positions and connection labels persist, so the arrangement you built is the arrangement you come back to.

Beats carry dialogue in a screenplay-like format with parentheticals and conditions, so what a character says and the circumstances under which they say it live in one authored line rather than in a line and a comment about the line.

Beats belonging to no arc are surfaced in their own folder with a warning marker instead of being silently invisible. The structural holes in your story are shown to you, which is the only useful thing to do with them.

Branch nodes render as cards with one labelled row per branch, each with its own colour and its own output port, and the connection leaving a branch inherits that branch's colour. The card grows with the branch count. The intent is that a branching story is readable straight off the canvas without opening anything.

Double-click a branch node to edit it: label the branches, colour them from a preset palette or a hex value, reorder them, delete them. The editor is backed by the same entity records as everything else on the board, so a branch is not a special case living in its own store.

Project-scoped typed variables (boolean, integer, string, and float) give branch conditions something real to test against, so a branch turns on state rather than on a note describing what the state would be.

A single action that links loose arcs and beats into the hierarchy, callable from anywhere in the app rather than only from the view that happens to own the graph.

XML, JSON, CSV, Unity, and Unreal. The generic formats matter as much as the named ones: anything that can read structured data can consume an Architect project, including engines nobody here has thought about.

Every exporter produces a ZIP archive with one file per entity type rather than a single undifferentiated dump. That is what makes the output droppable into an existing pipeline without writing a preprocessing step first.

Ampersands, angle brackets, and quotes inside your field values are escaped on the way out. An apostrophe in a character's name does not produce a malformed file, which sounds like a small promise until it is broken.

Choose which language model runs your operations. The preference is per-user and stored server-side, so it follows you across devices and sessions, and the catalogue tracks current models rather than freezing on whatever was good at launch.

The prompts driving extraction and schema generation live as files outside the application logic, with the originals preserved beside them, and they are re-read on every run rather than cached at startup. That means extraction behaviour can be corrected without shipping a release, which is why quality can improve between version numbers. To be precise about what this is: it is an operational capability, not a setting in your account. Hosted users do not edit prompts.

Every model operation is recorded with its duration, the model used, input and output sizes, and whether it succeeded. Nothing the AI did to your project is invisible after the fact.

Long operations report real progress per chunk ("processing chunk 1 of N") rather than an indeterminate spinner over a multi-minute job. Both extraction and semantic search report this way.

Models are shown with a visual cost tier instead of a raw price string, so choosing one is a legible decision made at the moment of choosing.

A sweep every five minutes finds and clears model tasks that died mid-flight, so a crash or a provider timeout cannot leave the progress monitor wedged forever waiting on something that is never coming back.

Sign-up is open, with no invite and no beta key, and a new account starts with three euros of credit. That is enough to put a real project through the whole pipeline before you decide anything.

Credits are deducted atomically before a model operation and rolled back if it fails. You are not charged for a run that did not happen.

Metered operations check your balance before they start rather than failing halfway through, and the estimate you are shown is a real computed number. Where an operation scales with the size of your project, the estimate scales with it: a semantic search over many chunks is priced as many calls, because that is what it is.

Balances are held and shown in euros, topped up through Stripe, with live exchange rates behind the conversion. Optional automatic top-up exists so a long extraction does not stop halfway for the sake of a few cents.

Each model task records what it actually cost in euros alongside its token counts, so spend is attributable to the work that caused it instead of arriving as one opaque monthly number.

Invite collaborators to a project by email as owner, editor, or viewer. The role is enforced on every project-scoped operation on the server, not merely reflected by hiding buttons in the interface.

Project activity is logged, and every entry is stamped with the application version that produced it, so behaviour can always be traced back to the exact build it came from.

An operator view across users, credit balances, model task history, projects, and an audit log, with sortable tables. Support questions get answered from records rather than from guesses.

A guided first run, plus contextual hints that appear as you reach each step and can be dismissed or reset from your profile. A six-step pipeline needs a way in.

Report a bug or request a feature without leaving the tool. A screenshot is captured automatically, and you can annotate it with arrows and boxes before sending. Reports land directly in the tracker the team works from, which is the only reason they get read.

The running version is displayed in the interface at all times. When you report something, which build it happened on is never in question.

Board background and entity row colours are per-user and stored server-side, so your workspace looks the way you left it on any machine you sign in from.

A Playwright suite drives the whole pipeline against a real backend on every change: project creation, lore upload, schema generation, entity extraction, relationship resolution, the narrative board, and export. The workflow described on this page is tested as a workflow, not as a pile of parts that each pass alone.