Yeoun Studio V3 · From first outline to reviewed publication
Build what the player can actually experience before expanding a long lore document.
A display name is for readers; an ID is the address that keeps the work connected.
This follows the tab order in the current standard story editor. A reading-room work shows only Basic, Participation, Catalog, World, Characters, and Relationship Cast.
Purpose Define stable work and Goal-contract identity plus the basic description. Write Keep plot.id, title, one-line summary, expected minutes, and contract.id distinct. Good example plot.id = moon-archive; “Find the missing oath in the lunar archive.” Avoid/verify Do not rename a published ID like display copy or reuse a retired ID for a new meaning; resolve missing title and summary lint.
Purpose Choose self, self with an approach, or reading/advisory execution. Write Use self for open participation, self_with_approach for a starting-card choice, or reading_advisory with disclaimer and prompts for a reading room without Goal Graph. Good example “Self + approach—the investigation lens is fixed when a new worldline begins.” Avoid/verify The disabled canonical-character mode cannot be saved; review warnings and diffs because changing mode can delete contract, opening, and ending data.
Purpose Offer 2–12 public cards with different lenses, tools, and starting points for the same player. Write Connect stable ID, title, hook, difficulty, capabilities, briefing, first collaboration, start location and milestone, public FactRefs, allowed Affordances, and opening variant. Good example “Verify it yourself—inspect the seal and question the record keeper.” Avoid/verify Do not assign the player a forced profession or identity or expose hidden/secret facts; verify every reference and reviewed English localization.
Purpose Give each approach card its own first scene. Write Connect variant and scene IDs, a play-contract location, time, title, narration, participating actors, initial Director events, and narrator/character events. Good example “Archive · late night—the participating actor ‘archivist’ points to the empty oath case.” Avoid/verify Never author the player’s dialogue, thoughts, emotions, or voluntary actions; make each character speaker a participating actor and verify the approach link.
Purpose Pin progression, movement, time-skip, and failure handling into the publication revision. Write Choose guided_loop, open_journey, or hybrid, then fill checkpoints or locations, connections, anchor facts, and recovery routes. Good example hybrid: “archive↔garden; anchor seal_examined; recover a missed clue through the librarian.” Avoid/verify Do not disable NPC autonomy or server-authoritative world facts; validate start locations, connections, fact references, and paths.
Purpose Help customers discover the work and make an informed choice on list and detail screens. Write Attach an approved cover and add genre and mood tags, a concrete short entryHook, and content notes. Good example “Before the seal breaks, trace whose oath disappeared.” Avoid/verify Avoid sensational promises absent from the work or missing safety notes; verify the cover is this creator’s approved asset.
Purpose Manage the world namespace, shared rules, forbidden claims, and reusable Lore. Write Set stable world ID, title, rules, and forbiddenKnowledge; manually pin up to five LoreModules to exact approved revisions and inspect diffs before updating. Good example “The seal text cannot be read on a moonless night.” Avoid/verify Legacy embedded loreEntries, namespace conflicts, cycles, unresolved refs, and Lore that directly changes relationships or Goals cannot be published.
Purpose Define identity, judgment, voice, knowledge, and portraits for 1–8 characters. Write Start with values, boundaries, and core motives, then author register, address, averageLength, questionFrequency, emotionDirectness, silence style, sentence patterns, forbidden expressions, relationship/crisis changes, and good/bad line examples. Give each behavior rule an instruction plus examples, each reaction a principle plus one scene-ready line, and connect fact-gated authoredSecrets and native world/facts. Good example “polite; answers briefly; never states an unverified claim as fact”; principle “when worried, acts before lecturing,” example “Jaeyun quietly sets warm milk in front of you.” Avoid/verify Ban unconditional obedience, direct relationship writes, and unknown secrets. Never overwrite a legacy string rule without reviewing its structured conversion; verify authored-secret localization and approved portraits.
Purpose Choose which character cards are relationship characters in this work and set starting presence and continuity eligibility. Write Connect character reference, in-work role, present/offscreen/absent, continuationEligible, and a fact-gated continuity memory with eventCode, meaning, and source text. Good example “archivist / guide / present / ‘the night you kept the promise’ after promise_kept.” Avoid/verify Do not connect NPC IDs, unknown facts, or unconditional memories; eligible characters must pass mutual-choice authoring readiness.
Purpose Define incident characters separately from relationship characters. Write Add stable ID, name, role, knowledge boundary, voice, behavior and reactions, relationship-room eligibility, initial presence, and fact-gated secret prose. Good example “guard / gatekeeper / knows why the alarm rang but not the culprit / offscreen.” Avoid/verify Do not place secret prose on public approach cards or reveal it before its FactRef; leave relationshipCapable off for ordinary incident NPCs.
Purpose Move characters and NPCs between present, offscreen, and absent when conditions are met. Write Add rule ID, actor reference, target presence, all/any/none fact condition, minimum turns, focus-on-entry, and announcement. Good example After alarm_rung, make the guard present: “Footsteps approach in the corridor.” Avoid/verify Do not make an absent actor a witness to past events; check conflicting transitions and unknown actor or fact references.
Purpose Define slots and boundaries for relationship characters arriving from another work. Write Set min/max guests, slot ID and label, required status, allowed_list or active_connection, role, knowledge boundaries, local limitations, and arrival copy using {{guestName}}. Good example “0–1 connected companion; sees this world’s magic for the first time.” Avoid/verify Never grant new powers or world knowledge automatically; check min/max and ownership/public-reference validity for allowlists.
Purpose Define stable facts that ground Goal state and character knowledge. Write Choose local ID, label, public/discovered/hidden, and state_only/observable/tellable/secret; put only initially true facts in initialFactIds. Good example seal_examined / “The crack in the seal was confirmed” / discovered+observable. Avoid/verify A model sentence alone cannot create authority and secret must not leak as observable; use worldNamespace:localId where a FactRef is required and reject duplicate IDs.
Purpose Group facts into player-readable progress stages. Write Set stable ID, description, visibility, and all/any/none Fact conditions in completeWhen. Good example identify_owner completes when both seal_examined and witness_heard hold. Avoid/verify A milestone does not itself mutate facts or relationships; use Goal analysis to find conditions true at start or unreachable by any Affordance.
Purpose Map customer free text to executable server actions and resulting facts. Write Add stable ID, description, varied positive and negative examples, optional semantic anchors, recognition and availability conditions, eventCode, added/removed facts, and presentation or blocked directives. Good example inspect_seal; positive “look closely at the seal,” negative “tear the seal off”; add seal_examined. Avoid/verify Never write relationships or memories directly or let the player determine an NPC’s action; test conditions, result refs, and false-positive examples.
Purpose Visualize current Facts, Affordances, Milestones, and Endings and run real reachability through server GoalRuntime. Write Save the source contract, then run whole-graph analysis or select an Affordance sequence in the path builder. Good example Execute inspect_seal → question_archivist → restore_oath on the server. Avoid/verify This view stores no separate graph state; use failed traces and unreachable endings to fix their original tabs.
Purpose Define eligibility, outcome, and final presentation for up to 12 ending IDs. Write Add ID, label, true_ending/partial_ending/bad_ending, all/any/none Fact conditions, and either per-ID events or outcome-default events. Good example oath_restored becomes a true ending with its own scene when the restoration fact holds. Avoid/verify Do not grant relationships, memories, or capabilities as ending effects; check duplicate IDs, the 12-ending limit, reachability, and presentation.
Purpose Author the work’s common opening presentation. Write Order narrator or character roles with a display name and concise text. Good example narrator: “Blue light spills through the archive’s closed door.” Avoid/verify Never decide the player’s speech, thoughts, emotions, or action; check empty text and missing character names.
Purpose Define high-risk actions, supporting presentation, Director events, and EchoBeats that turn a remembered detail into observable behavior. Write Reference real Affordances/eventCodes and configure the Director trigger—such as quiet_turns or after_fact—actor, conditions, priority, and directive. For an EchoBeat, set minimum/cooldown turns, purpose, allowed memory sources, topics, kinds and preference polarity, then choose fallback or suppress and author matched/fallback actions. At least one evidenceTermsAny token must occur in the exact narration committed to the customer. Good example A matched “milk” preference yields “Jaeyun sets warm milk in front of you”; suppress creates no fallback action when no memory matches. Avoid/verify Never expose internal directives or proof tokens as customer-facing copy, and never let a Director/EchoBeat directly change relationships, memory, or capabilities. Test actor/fact/eventCode references, no-match behavior, and evidence wording.
Purpose Accumulate relationship evidence from committed facts and actor presence, then let the character decide accept, defer, or decline by context. Write Author evidence source fact, participant/observer/direct_target, reason and axis/signal effects, plus five contexts’ minimum axes/signals, required/forbidden events, targets, and defaults. Good example Participating in promise_kept adds trust+1; accept at signal 2+, otherwise default defer. Avoid/verify Plot/Lore cannot directly set the result and insufficient evidence must not be bypassed with a default accept; verify ending/private-room rules for eligible characters and run the server preview.
Decision-making principles keep a character recognizable across scenes more reliably than a list of sentence endings.
See the Creator Rights and Submission Policy and Rights Complaint Process for the binding requirements.