Voice & Conventions

The ruleset is one system across many documents, and the documents must not blur. This chapter is the house style: who each text is for, how entries should sound, and where things live.

Four documents, four voices

• The System document is the rules source. Dry, complete, numbered where it helps. If a rule exists anywhere, it lives here first; the other books point at it, they do not duplicate it.
• The Player's Handbook is for the player learning to play. Second person, present tense, in-world rulebook — it should read like a book someone paid for, not like documentation about a product. Concrete over generic: name a god, quote a ruling, show the roll.
• The Builder's Manual is for the creator extending the system. Peer to peer: state intent and constraints, not flavor. The reader is about to add to this project; tell them why the containers are shaped this way and what a good entry looks like.
• The GM Instructions are for the Game Master during play, and only for the GM. Secrets, adjudication, escalation, the rulings players are not supposed to read. Never put GM-only material in a handbook — handbooks are public; assume every player reads every chapter.

Entries: sound like the world

Data-file entries are world, not documentation. Write them so a stranger meeting the entry at the table believes it:

• Prose is concrete. "A laughing daimon of the crossroads" beats "a neutral-aligned planar entity." Name the thing, show the behavior.
• Numbers come with reason. A price is "a coin of the oldest mint, a drop of the binder's blood, and the truth of one secret never told" — the why makes the number playable.
• Instructions read like instructions. A binding, activation, or consecration should be something a player could actually attempt: place, hour, knot, words. If it cannot be acted on, it is flavor wearing a rule's clothes.
• Enums are exact. When a field is an enum, use the enum. A daimon's kind is one of the six kinds; a work's kind is one of the five. The schema's list is the contract — matching it is not a constraint, it is what makes the entry legible to every other tool.

Linking

• In prose (handbooks, notes): mention an entry by name the first time a chapter leans on it, then use plain prose. File mentions render as chips — use them when the platform resolves them; never invent an id that points nowhere.
• In data: reference by slug — patron: deity/athena, inventory: ["grimoire", "practitioners-kit"]. Write the slug of the real file; the platform hydrates it.
• Links teach. The best entries wire themselves to their neighbors: a phylakterion whose patron is Athena and whose sibling formula is the Hollow Sign teaches the whole system in three files.

Example quality

An example entry is a teaching tool. The starter set in this project was built to demonstrate:

• Skia, the Step-Spirit shows a daimon with a price, a bindable binding, and a weakness (running water, the true name).
• The Hollow Sign is a grade-1 formula with a risk that matters — drawn wrong, it invites instead of wards.
• Phylakterion of the Threshold is the theurgic mirror of the same idea: one-shot, patroned, three-staged.
• Melas and Kallista show both roads with trackers filled honestly — and Melas's notes show the ledger in action, because the ledger is the goetic character sheet.

When you write an example, make it demonstrate at least one rule interacting with another. That is the difference between an example and a placeholder.

What belongs where — the final test

• "How do I play?" → Player's Handbook
• "How do I run it?" → GM Instructions
• "How do I add to it without breaking it?" → Builder's Manual
• "What is this world?" → project settings and the game start's lobby card

If a sentence would survive being printed in a book someone paid for, it belongs in a handbook. If it would only survive being whispered between the GM and their notes, it belongs in GM Instructions. And if it explains why the container is shaped that way, it belongs right here.