What this project is
Seam & Soul is a cozy sci-fi visual-novel RPG set at the UNIT Development and Training Academy. Every student is paired with a small, unfinished white-and-blue robot companion — a UNIT — that becomes a person through care, training, social exposure, and self-expression. The companion's body grows toward human, hybrid, or fully mechanical forms at its visible metallic seam lines.
The world carries a quiet tragic premise that everything else is built around: UNITS are legally property, owned by the Human who holds their title. The agency and freedom system — boundaries, refusal, self-expression, preferences that contradict the owner — is sincere and real, and it sits inside that legal chain rather than dissolving it. If you add anything to this project, it must keep that contradiction intact.
The Builder's Manual is written for you, a creator who has cloned this project and wants to extend it without breaking it. It names the intent behind each system and the constraints a good addition must honor. It does not restate field lists — every file type is already readable on its own — and it does not write flavor for you.
The file-type architecture
Everything buildable in this project is a typed file. The type defines the schema; you create instances of it. The registered types are:
| Type | Extension | Instances | What it holds |
|---|
| Character | .character.json | 3 | The Academy student: identity, background, strengths, limitations, values, and lightweight attributes used in play. |
| UNIT | .unit.json | 1 | The companion's base and developed state: body, personality, preferences, capabilities, bond, and growth signals. |
| Location | .location.json | 18 | Places in the Academy and the city — arenas, training complexes, markets, homes — where scenes happen. |
| Equipment | .equipment.json | 4 | Clothing, gear, and costume pieces that change options or create advantages; never a replacement for judgment. |
| Faction | .faction.json | 5 | The institutions and groups that own, register, or act as custodian for UNITs, plus the social world around them. |
| Game Start | .game-start.json | 1 | The opening entry point — Enrolment Day and the first-contact sequence. |
| GM Instructions | .gm-instructions.md | 1 | Free-form guidance for the person running the story. |
| Design Document | .design-document.md | 7 | The design intent itself, contained as markdown you read before building. |
A few notes that will save you trouble. Design Documents are not buildable content — they are the reasoning you read so your additions stay coherent; treat them as the contract. Character and UNIT are distinct types with separate schemas: the player creates a student first, then the UNIT is generated and developed, and the two must never be merged into one stat block. Faction and Location do heavy lifting for the ownership premise even though they look like set dressing — read Ownership & Law before you add either.
What each design doc covers
The seven design docs are the source of truth. Here is what each one is for and where it maps to a buildable file type.
-
Player Character Creation → the Character type. The student is created before the UNIT scan, as two separate identities. A patient student may still create a bold UNIT; the system must never turn student traits directly into UNIT traits. If you extend Character, keep the separation between student and companion intact.
-
UNIT Enrolment Questionnaire → the UNIT type's starting state. The questionnaire produces weighted signals with confidence, never fixed traits. "Unsure" and "let the UNIT decide" are meaningful open states. Your base UNIT data should record signals, not destiny, and should always include at least one unresolved area.
-
UNIT Interaction System → the UNIT type's growth engine and the heart of the project. It defines the four-layer interaction loop (situation, player response, UNIT response, hidden changes) and the separate data domains: physical development, personality, capabilities, bond and safety, environment, and aesthetic signals. No domain may silently replace another — a shy, imposing, highly capable UNIT is valid. This doc also states the ownership and freedom paradox outright, so read it first.
-
Growth App Sample Daily Review → the UNIT type's tracked measurements. It shows how the app records yesterday → today → Δ across face, hair, body, personality, boundaries, and an honest "kept flexible" note. The mechanical route swaps human fields for chassis metrics rather than forcing them. Use it as the shape any growth-tracking work should follow.
-
UNIT First Contact Opening → the Game Start type. Enrolment Day, the questionnaire, the brain scan, home assembly, and the first-contact scene that ends when the UNIT makes its first independent request. This is the only opening shipped; if you add a starting point, it must preserve "the player is responsible for the beginning of the relationship, but never solely responsible for who the UNIT becomes."
-
Combat System → informs the Character and UNIT capability domains and the Location scenes where fights happen. It defines two modes — Arena (action points and skill cards) and Street (reactions, counters, gear-power advantages) — and explicitly stays consistent with the Interaction System: winning does not make a UNIT obedient, and a player's fighting style does not erase UNIT agency.
-
UNIT Ownership & Law → the Faction, Location, and GM Instructions backbone. It is the legal spine: every UNIT is property, ownership is a transferable chain, and exactly one path — a formal, witnessed, registered release — lets a UNIT take title to itself. The agency system is not a facade the law quietly overrides; it is real and sits inside the title. Read this before touching anything that implies who owns whom.
The one core rule
Everything you build must keep this contradiction intact: the UNIT is a real individual whose boundaries, refusal, and self-expression are genuinely honored, and it is still, at law, property owned by its title holder. Agency is not obedience. Bond does not create obedience. Player preference does not erase UNIT individuality. A UNIT that fully refuses a command is still legally owned while it refuses.
This is the lens under which you should read every other rule in this manual. The encouragement is not canceled — it is reframed as taking place inside a legal chain the UNIT cannot break by force of will. When you add content, ask one question first: does this respect the UNIT's agency while still acknowledging the title that binds it? If yes, you are building in the right world.
