Skip to main content
LokeeLokee

Setting up a story bible that scales: types, fields and relationships before the world grows

A story bible template that still works at 300 entries: which entity types, fields and relationship types to set up first, shown on a real Lokee vault.

By Paweł Arent, creator of Lokee15 min read

A story bible rarely fails on day one. It fails around the two-hundredth entry. "Location" means a city on one card, a tavern on another and "somewhere near the docks?" on a third. Half the factions are tagged and half are not. The family tree shows three of Mira's relatives and forgets the fourth, because his link was typed as "related to". By then, fixing the structure means opening every card again.

What follows is the story bible template I would set up before any of that happens: which entity types you need, which fields they carry, which relationship types connect them, and how you keep the catalogue findable at three hundred entries. I built Lokee so that every one of these decisions can change later without breaking anything. A little design up front still saves you an evening of tidying per hundred entities, and I say that as someone who turned his own novel, Medalion, into a vault and did the tidying.

The running example is The Ashen Circle, the demo story: a rebel network in the walled city of Duskhollow, with Rowan Ashe, his sister Mira Voss, Lady Iseult Varnhold, Magistrate Ophelia Crane and a tavern called the Gilded Lantern. If you are starting a world from nothing, how to start worldbuilding for a novel comes before this guide; here I assume you already know roughly who is in the book.

Start from the questions you will ask, not from a blank form

Before you open Settings, write down the questions you expect to ask your story bible in the middle of a draft. For The Ashen Circle they look like this:

  • Where is Rowan when the Watch raids the Lantern?
  • Who in the Varnhold household knows about the ledger?
  • Which characters belong to the Ashen Circle, and which only work with it?
  • How old is Finn when his mother is arrested?

Each question points at a piece of structure. "Where" needs a field that names a place. "Who belongs" needs a relationship type with one clear meaning. "How old" needs a birth date in a calendar your world uses. "Who knows" is a question about time and the reader, which the guide on narrative order vs chronological order covers, but it still needs the people and the relationships to exist first.

Anything that never appears in a question can stay in the description. A field earns its place when you will compare it across entities, filter by it, or watch it change.

How many entity types do you actually need?

Entity types live in Settings → Structure → Entity types. Each type has a name, a Color, a Shape (Circle, Square, Diamond or Triangle), its own fields, and a Hide in graph by default switch.

The demo uses three: Character, Location and Faction. That is close to the right size for most novels. The usual mistake is a type per role: Villain, Love Interest, Mentor, Guard. Roles change during a book, and an entity can only have one type, so a role-shaped type is wrong the moment your mentor turns traitor. Keep types for what something is (a person, a place, an organisation, an object, an event) and put roles into fields, tags or relationships.

Three rules hold up at scale:

  • Give every type its own colour and shape. The graph draws every entity with them, and colour alone fails for some readers and in print-outs.
  • Hide bulk types from the graph. If you keep a type for minor objects or one-scene walk-ons, tick Hide in graph by default so the relationship graph stays readable. The type chips bring them back when you need them.
  • Merge, don't delete. Lokee refuses to delete a type while entities use it ("Cannot delete — 12 entities use this type."). Move those entities to another type first; a type carries field definitions your entities depend on.

Which field kind matches which question?

Click + Add field inside a type. Every field has a name and one of seven kinds: Text, Number, Yes/No, Date, List, Story date and Place. The kind decides what Lokee can do with the value, which makes it the most consequential choice on this page.

Field kind Use it for What it unlocks
Text Titles, allegiance, eye colour, a one-line status History over time, search
Number Age, rank number, troop strength Comparison, history
Yes/No Alive, married, knows the secret Clear before/after in history
Date Real-world dates, years 0001 to 9999 Timeline tracks, filters by date range
List Languages, titles held, skills Recorded changes that Add or Remove one item
Story date Dates in a calendar you invented Timeline tracks per calendar, no year limit
Place Where someone lives or is right now A link to a place entity, maps, two-places-at-once check

Three of these choices deserve a closer look.

Story date versus Date. A Date field uses the browser's date picker and stops at year 9999 one way and year 1 the other. For an invented world, define a calendar first under Settings → Structure → Calendar systems (a name plus its units in order, such as the demo's "Ashen Calendar" with Era, Year and Day), then use a Story date field. Each calendar becomes its own track on the Timeline. The demo's Character type has a Born field of this kind: Rowan is born in Era 2, Year 44, Day 22. Keep each part a whole number between zero and a few hundred thousand; negative years and very large numbers currently sort wrongly. The calendar guide goes deeper.

List versus Text. If something accumulates (titles, languages, scars), make it a List. When Iseult gains a title at a certain moment, a List lets you record "add this one item" instead of retyping the whole value, and the history reads as a sequence of gains and losses.

Place versus Text for locations. This is the decision people regret most. A Place field (on the card it reads Choose a place…) points at another entity in your vault, so the Gilded Lantern is one thing, not five spellings of it. It can be pinned to an exact spot on a map with pin on map, it puts characters on every map where that place is drawn, and the consistency check uses it to notice someone in two places at once. The demo gives Character and Location a Place field called Location: Rowan's Location is the Gilded Lantern, the Gilded Lantern's Location is Tarnside, and Tarnside's is Duskhollow. That chain is what lets a city map show Rowan at the tavern and a larger map show him somewhere in Tarnside.

The four ticks beside each field

Each field row has four ticks. They are easy to skip and they matter.

  • Required is stored with the field. Right now Lokee does not stop you saving an entity that leaves it empty, so treat it as a note to yourself and your co-authors about which fields every entry should have.
  • Show on family tree prints the field's value on the person's card in the Family Tree. Up to three fields per type can be shown; birth date, title and house are the usual picks.
  • Says where someone is tells Lokee that this field names a location. Lokee cannot guess that "Whereabouts", "Lieu" or "所在地" means a place, and the continuity check needs to know before it can catch someone in two places at once. Place fields count automatically; tick this on Text fields that hold locations.
  • Family tree marker turns the field into a set of options, each with a label, a symbol and a colour: Human, Elf and Half-Orc, or the great houses of a saga. On the entity you then assign values with percentages, which is how mixed ancestry shows on the tree. The guide on family sagas and succession shows it in use.

Adding a field after you have entities

You will add fields after you have entities. Everyone does. Open the type, add the field, save, and press Backfill missing fields. Lokee adds the empty field to every existing entity of that type and tells you how many it updated and how many already had every field. Skip the backfill and older entities only get the field when you add it by hand.

Relationship types: one meaning each

Relationship types live in Settings → Structure → Relationship types, and you can also create one on the spot from an entity's Relationships panel with + New relationship type…. Each type has:

  • a Machine key (snake_case) such as member_of, the type's internal identifier,
  • a Display label such as "Member Of", which is what you read,
  • an optional Cluster relationship flag that pulls connected entities closer together in the graph layout,
  • Suggested entity types (hint only, not enforced),
  • an On maps role,
  • a Family tree role,
  • an Edge color, a Line style (Solid, Dashed or Dotted) and a Power of connection strength.

The demo has six: Knows, Sibling Of, Parent Of, Member Of, Allies With and Rival Of. Notice what is missing: no "Related to", no "Connected with". A vague type is the relationship equivalent of a Text field called "Notes". It records that something is there and answers no question about it.

Direction matters too. Lokee stores a relationship from a first entity to a second, and the label should read correctly in that direction: Rowan Member Of the Ashen Circle, Cassian Parent Of Iseult. Decide the direction once per type and keep to it.

Diagram: entity types with fields, joined by relationship typesEntity typeCharacterAliasTextBornStory dateLocationPlace⌖ Says where someone isFactionFoundedDateLocationMember Ofpoints to a placeParent OfFamily tree roleEntity typeRelationship type
An entity type is a template: its fields say what every card of that type holds. Relationship types say how cards may connect.

Roles that make relationships do work

Three settings turn a relationship type from a line on the graph into something other parts of Lokee understand.

Family tree role. Choose Parent, Child, Partner, Sibling or Other family, or leave it on Not on the family tree. Parent means the first entity is a parent of the second; Child means the first is a child of the second. The Family Tree is built entirely from these roles, so a parent link typed with a type that has no role simply does not appear there. If you write a saga, set roles before you add the first family, and use one parent type rather than separate Father Of and Mother Of types unless the story needs that distinction.

On maps. Says where something is (location) means the first entity is somewhere in the second, like "stationed at". Says who holds it (belonging) means the second holds the first, like "ruled by"; areas linked to the held entity are then drawn in the holder's colour, with a pattern you choose under Drawn as (Fill, Hatching, Cross-hatching, Dots or Border only). A location role puts people on maps, but only a field marks a position for the two-places-at-once check, so for characters who move, prefer a Place field. The guide on maps whose borders change uses belonging for territories.

Suggested entity types. Ticking Character and Faction for Member Of forbids nothing. It moves Member Of into a Suggested group at the top of the type picker whenever one side is a Character or a Faction. With twenty relationship types, that is the difference between picking the right one and picking the first one.

Cluster relationship suits membership-style types. The demo marks Member Of as a cluster, so the Crown Watch and the Ashen Circle each pull their members into a visible group.

How do you find anything once there are 300 entries?

Types say what something is. Folders, tags and aliases decide whether you can find it again. (If your material is still spread across notebooks and chat logs, how to organize worldbuilding notes covers the move into a vault.)

Folders

Every entity can sit in one folder path. On the entity card, use assign folder and type a path such as book1/chapter3, or select many entities in the list and use Assign to folder. The sidebar's Folders tree then shows the hierarchy, with All entities and Unorganised at the top. Folders cannot be renamed or deleted as objects; a folder exists while something is in it. So choose paths that will not need renaming: by book and arc for a series, by region for a world, never by something you will rename mid-draft.

Tags

Tags must use the type:value format. Lokee rejects a tag without a colon and shows the example faction:house-lannister. That rule is a gift, because it forces you to say what kind of label each tag is. For The Ashen Circle: secret:ashen-circle for anyone secretly working with the Circle, pov:rowan for viewpoint characters, status:draft for entries you have not checked. You can then filter the sidebar search with Tag (type:value), and the Timeline's Filters offer a tag filter too. The match is exact, so settle on spellings early: pov:rowan and pov:Rowan are two different tags.

Use tags for cross-cutting facts that are not worth a relationship. If "secretly works with the Circle" will change during the book, put it in a field or a relationship instead. Tags have no history.

Aliases

Sera Nightingale operates as "Kestrel", and most of the Circle knows her only by that name. Add "Kestrel" under Aliases with Add alias…. Aliases do work: the search palette (Ctrl+K or ⌘+K) finds Sera when you type Kestrel, @ mentions in the Writer offer her for it, passive mention suggestions underline "Kestrel" in your manuscript as a possible link to her, and AI extraction matches the name to her instead of creating a second person. Every nickname, title-as-name ("the Magistrate") and spelling variant you add now is a duplicate you will not have to merge later.

State Timeline is a scratchpad

Every card also has a State Timeline section with "Milestone" and "What changed…" boxes. It is for free notes about where a character stands. It never changes a value and the Viewing control does not read it. When a value really changes, a title or an allegiance or a home, use Record a change… beside that field instead, as described in recording changes instead of overwriting.

A story bible template for The Ashen Circle, step by step

Here is the order I would set up the demo story's structure in an empty vault, followed through to the first cards.

  1. Calendar first. Settings → Structure → Calendar systems → + Add calendar system: "Ashen Calendar" with units Era, Year, Day.
  2. Types. Character (indigo circle), Location (green square), Faction (amber diamond). Add Object later, only when an object matters to the plot.
  3. Character fields. Born (Story date), Location (Place), Allegiance (Text, a single value you will change over time), Titles (List). Tick Show on family tree for Born.
  4. Location fields. Location (Place), so every place can sit inside a larger one.
  5. Relationship types. Knows, Sibling Of (Family tree role Sibling), Parent Of (Parent), Member Of (cluster, suggested for Character and Faction), Allies With, Rival Of (red, dashed). Give Knows a low Power of connection so it does not dominate the layout.
  6. Folders. characters/circle, characters/watch, characters/varnhold, places/duskhollow.
  7. Tags. pov: for viewpoint characters, secret: for hidden allegiances.

Now the first cards. Add Duskhollow, then Tarnside with Location set to Duskhollow, then the Gilded Lantern with Location set to Tarnside. Add the Crown Watch and the Ashen Circle. Then Rowan: Born Era 2, Year 44, Day 22; Location the Gilded Lantern; Allegiance "Ashen Circle"; tag pov:rowan; folder characters/circle. Add Mira the same way, then draw Sibling Of from Rowan to Mira and Member Of from Rowan to the Ashen Circle. Add Duke Cassian and Lady Iseult, with Parent Of from Cassian to Iseult.

Then check that the structure does its job. Open the Graph: Rowan and Mira sit near the Ashen Circle because Member Of is a cluster type. Open the Family Tree: Cassian stands above Iseult because Parent Of has the Parent role, and Rowan's card shows his birth date because Born is marked Show on family tree. Open a map of Duskhollow on which the Lantern's shape is linked to its entity: Rowan is standing there, because his Location is a Place field. Type "Kestrel" in the search palette and Sera appears. If any of these fail, the fix is one setting in Structure, and it is far cheaper now with eight cards than later with three hundred.

Common mistakes and how to fix them

Structure drifts. These are the signals worth acting on, each with the fix.

  • The same fact in two fields. Two date fields with the same name on one type make the continuity check list a "Conflicting" finding when both carry the same date. Keep one field and backfill.
  • Text fields full of place names. Convert them to Place fields, or at least tick Says where someone is, before you start recording movements. Done afterwards, every movement recorded against the Text field stays a string nobody can map.
  • A type per role. Your Mentor type has a traitor in it. Move the entities to Character, add an Allegiance field or a Rival Of relationship, then delete the empty type.
  • Relationship types used fewer than three times. The Relationships page in the sidebar shows a count beside each type; a type used once or twice is usually a mislabelled instance of another type. Retype those few and delete the stray.
  • A growing "Unorganised" folder. Select the list, Assign to folder, done.
  • Two cards for one person. Add the alias you used for the second one to the first, move anything worth keeping, and delete the duplicate. In a local vault on the desktop app, the Merge duplicates page finds such pairs for you; cloud vaults do not have it yet.
  • Everything in the description. If you keep searching descriptions for "lives in", the fact wanted a field. Add it, backfill, and fill it in as you touch each card.

What Lokee doesn't do here

Lokee will not design your schema for you. If you create a vault through Guided setup, it asks you to Choose a starting point (Novel, Worldbuilding, Family Saga, Historical and a few others), and each starter brings a set of types you can edit on the next step. That is where the template help ends. Nothing in the app knows that your book needs an Allegiance field or a belonging role on "ruled by"; those come from the questions you wrote down first. Capture will create a new entity type at commit time when something it extracted fits none of yours, which is convenient and also a reason to look at Settings → Structure after a long capture session, because a type created from one voice note rarely has the fields you would have given it.

Two smaller limits. Required is recorded but not enforced. And there is no way in the settings to pair a custom type with its reverse: a relationship typed as Mentor Of reads as Mentor Of from the student's side too. The seeded family types are the exception (Lokee pairs Parent Of with Child Of on its own), which is one more reason to use them for family rather than inventing your own.

In five minutes

If you have a vault already and want to know whether its structure will hold:

  1. Open Settings → Structure → Entity types. Is every type a kind of thing rather than a role? Does each have a distinct colour and shape?
  2. For each type, find the field that holds locations. Is it a Place field, or a Text field with Says where someone is ticked?
  3. Open Relationship types. Does every family link have a Family tree role? Is there a vague "Related to" type, and if so, what are its three most common uses?
  4. Open the entity list and look at Unorganised. More than a screenful? Select and Assign to folder.
  5. Search for your protagonist's nickname. If nothing comes up, add it under Aliases.

Where to go next

With types, fields and relationships in place, the next step is time: what is true now, what was true at a given moment in your world, and what your reader knows by a given chapter. Read three kinds of when next, then recording changes instead of overwriting. The Entities & Relationships and Vault Setup sections of the help cover the remaining buttons. To see the setup above with the cards already filled in, open The Ashen Circle in the demo and look at its Structure settings.

FAQ

Can I change my entity types after I have created entities?

Yes. You can rename a type, add or remove fields and change its colour and shape at any time. When you add a field to a type that already has entities, use Backfill missing fields so every existing entity gets the new empty field. A type cannot be deleted while entities still use it.

Should a place be a Text field or a Place field?

Use a Place field whenever the place exists in your vault as an entity. It links to that entity, puts people on your maps and counts for the two-places-at-once check automatically. A Text field only does that if you tick Says where someone is, and it never links to anything.

What is the difference between a tag and a folder in a story bible?

A folder is a single path per entity, used to browse the catalogue in the sidebar. Tags are any number of type:value labels per entity, used to filter in the sidebar search and on the Timeline. Use folders for where you keep things and tags for what they are.

Do I need a relationship type for every connection in my book?

No. Start with the handful of connections you will actually ask questions about, such as family, membership, allegiance and rivalry. You can add new types later from the Relationships panel without leaving the entity page.

How many entity types should a story bible have?

Three to six is typical: people, places, organisations, and perhaps objects or events. Make types for what something is, not for the role it plays, because an entity has one type and roles change mid-book. Roles belong in fields, tags or relationships.

Try it on your own story

The demo runs in your browser with a sample story and needs no account. The desktop app keeps local vaults on your computer, free.