Project Explorer · working sheet

Seeds of the Throne

Seeds of the Throne began as years of conversations and thousands of story ideas. The Project Explorer shows how those ideas are being organized into characters, a world, a timeline, and a finished series.

Interpretive still life of recovered records aligned against hidden-system evidence.

Recovered records held against the working evidence.

Story development tools

See how the authoring system turns ordinary language into finished story work.

The Project Explorer shows the live notes, decisions, and workshop used to develop Seeds of the Throne. Each step keeps confirmed decisions separate from suggestions and unanswered questions.

This is a public, read-only look at the real project, so it contains full spoilers. You can try the workshop, but your draft stays in this browser unless you export it.

  1. The author explains the story in ordinary language.

    The system records those ideas and separates confirmed decisions from suggestions and unanswered questions.

    Read how the system is designed
  2. The current workshop asks one consequential question at a time.

    Each question helps the author decide a missing cause, character choice, relationship, world rule, or event.

    Open a workshop question
  3. Accepted answers are added where they belong.

    An accepted decision can update character notes, the timeline, world rules, plot events, and the list of remaining questions.

    Review decisions and supporting information
  4. Use the completed plan to write and revise scenes.

    The planned system will create scene outlines, draft prose, check continuity, revise weak sections, and assemble the manuscript for the author's approval.

    Read the system plan

Seeds of the Throne is the working example. The notes, decisions, and workshop below are the live project, not a demonstration mockup.

Vault overview

See the whole story-development system at a glance.

605 notes work together as one system. The vault remembers where ideas came from, what the author decided, what remains uncertain, and what should happen next.

The vault turns conversations into organized story memory. It preserves sources, separates decisions from suggestions, finds missing connections, supports research and workshops, prepares scenes and prose, checks continuity, and publishes selected material without surrendering author control.

  • Working now Capture, memory, workshops, and research already operate.
  • Needs repair Current-state agreement, automatic checks, and decision updates still drift.
  • Planned next Durable answers, manuscript production, and mobile save are not built yet.
  1. Capture

    Conversations, mobile notes, and raw ideas are preserved.

  2. Understand

    Current context and compiled notes explain what the project means now.

  3. Decide

    Workshops ask one important question and preserve the author's answer.

  4. Develop

    Research, alternatives, story structure, and focused tests strengthen the work.

  5. Create

    Scene plans, prose, images, and manuscript material are produced for review.

  6. Share

    Selected material becomes the story site, Project Explorer, and public posts.

What lives where

Each area has a job. Folder names are secondary detail.

  • New material

    Preserves incoming ideas and the order in which they developed.

    00 Inbox, 01 Sessions

  • Story memory

    Keeps the detailed working knowledge and a smaller briefing used to resume work.

    02 Story, 03 Context

  • Research

    Separates questions, reports, and usable findings from story decisions.

    04 Research

  • Public work

    Holds reviewed material prepared for readers.

    05 Public

  • Drafts

    Holds scenes and manuscript candidates awaiting review.

    06 Draft

  • Decisions and direction

    Records choices, contradictions, current work, handoffs, and verification.

    07 QA, 07 Coordination

  • Development tools

    Diagnoses missing connections and tests possible story directions.

    08 Story Loop, 09 Story Exploration

  • Reusable methods

    Provides repeatable methods for writing, research, images, websites, and checks.

    skills, scripts

What already works, what needs repair, and what is still planned

Working well

  • Idea and session capture
  • Human-readable story memory
  • Author authority and decision boundaries
  • Research kept separate from story truth
  • Workshop questions that wait for an answer
  • Decisions, contradictions, and open questions
  • Visual identity and image controls
  • Markdown files and recoverable history
  • Searchable file access

Needs repair

  • One trustworthy current-state view
  • Automatic checks before a change is merged
  • Shared labels and stable record identifiers
  • Updating every affected note after a decision
  • Keeping the weekly cycle current
  • Clearer boundaries around older folders
  • A cleaner split between the repository and the live site

Planned next Not built yet

  • Durable integration of conversational answers
  • Automatic reports of what a decision would change
  • Complete scene-to-manuscript production
  • Manuscript assembly and export
  • Reliable mobile save, resume, and synchronization

The next build order

  1. Make builds and checks reliable.
  2. Create one trustworthy current state.
  3. Normalize the records for one small complete path.
  4. Connect accepted decisions to every affected file.
  5. Prove one complete path from conversation to approved manuscript material.
  6. Expand only after that path works.

Current story development

See what the story already has and what it still needs.

The system checks the whole story for missing causes, weak character decisions, unclear rules, and unfinished events. The results show the author what to work on next.

Current story premise

The colonization process trains participants and contains dangerous criminals.

Humanity developed the Luminai inside an interactive colonization environment. Sylvan and his Luminai are tested against Samuel Franklin, a criminal already held inside the containment process.

The current story problem Make the formal separation, rapid financial collapse, processing, exposure, and accepted placement feel inevitable.

Read the current story assessment

0 / 10major story problems resolved

Current development pass0%
0%
Current sweep
Reassessment
Current task
RW-01
  1. 01 Reassessment
  2. 02 Causal sequence
  3. 03 Character agency
  4. 04 Systems + evidence
  5. 05 Scene design
  6. 06 Draft

Story files

Browse the files used to develop the story.

Search 605 documents about the world, characters, plot, research, decisions, workshops, and earlier ideas.

Current document 04 Research/Findings/32-40 - Vault-to-Image Graph Compiler.md

Vault-to-Image Graph Compiler — Synthesis of Reports 32–40

Finding

The next Visual World Compiler should not retrieve lore and ask a renderer to interpret it. It should resolve a small, source-traceable claim graph into a clean visual packet. Authority, time, relationships, environment, technology, uncertainty, and artifact freshness are separate compiler concerns and should remain separate until projection.

This is an engineering synthesis, not story canon. It does not adopt any unresolved visual design.

vault sources
  → claim extraction and source provenance
  → typed authority graph
  → scene-intent parsing
  → smallest sufficient subgraph
  → conflict, time, place, role, and visibility resolution
  → missing-definition validation
  → clean observable renderer packet
  → GPT Image
  → QA and provenance record

The clean renderer packet and the compiler trace are sibling outputs. The renderer receives observable instructions only; QA rules, citations, rejected alternatives, hidden motives, and unresolved branches remain in the trace.

Ten governing findings

  1. Authority belongs to individual claims. File dates and file-level labels are insufficient. Each load-bearing claim needs source, status, scope, and provenance.
  2. Conflict is graph data. Contradiction, supersession, deprecation, and non-combinability should be explicit edges. No general “latest wins” rule is safe.
  3. Image time is an event-resolved state. Equivalent year, birth-year-plus-age, chronological age, apparent age, rejuvenation state, role, and wardrobe resolve through separate temporal relations.
  4. Relationships require qualified participation. Direction, interval, public visibility, privacy, and scene role belong on relationship or participation records rather than being flattened into permanent character labels.
  5. Environments are layered. Geography, culture, era, social layer, site function, weather, condition, and event overlays should resolve over an environment master. Surface civilization and hidden civilization remain distinct layers.
  6. Technology is modeled by capability before appearance. Access, controller, users, affected populations, state, concealment, and physical consequences can be established while hardware appearance remains undefined.
  7. Retrieval is bounded evidence selection. Resolve known IDs and graph neighbors first. Semantic retrieval may supply candidate evidence, but cannot promote authority or settle ambiguity. Every selection needs a receipt.
  8. Resolution and projection are separate. The resolved subgraph retains IDs, provenance, alternatives, and diagnostics. The renderer projection strips those elements and emits only approved observable instructions.
  9. Uncertainty is typed. Missing identity anchors, contradictory canon, undefined appearance, irrelevant unknowns, and deliberately hidden facts have different severity. A scoped author waiver permits an experiment but never creates canon.
  10. Compilation is incremental. Claim fingerprints and reverse dependencies should identify stale packets, benchmarks, references, and images after a vault change, with an explainable path from the changed claim.

Core records for the next version

  • Claim: subject, predicate, value or object, status, scope, source, provenance, confidence, and temporal qualifiers.
  • Conflict: participating claims, relation type, severity, and explicit resolution when one exists.
  • Event or Interval: time coordinates, participants, roles, place, and state transitions.
  • RelationshipParticipation: parties, direction, role, interval, visibility, privacy, and observable consequences.
  • PlaceLayer: geography, culture, era, social layer, site function, conditions, and inheritance source.
  • Capability: function, dependencies, access, control, affected entities, state, visibility, and approved visible consequences.
  • SceneIntent: subjects, action, time, place, purpose, viewpoint, manifestation request, image type, and render style.
  • RetrievalReceipt: deterministic seeds, traversal rules, semantic candidates, selected evidence, exclusions, and score reasons.
  • ResolutionTrace: every resolved property, merge decision, graph dependency, source claim, conflict result, and gap.
  • RendererPacket: identity anchors, appearance state, environment, wardrobe, action, relationships-as-blocking, visible effects, composition mode, image type, render style, and negative constraints.
  • Gap: category, affected property, severity, dependency frontier, question, and disposition.
  • AuthorWaiver: exact scene and property scope, permitted invention, expiration, issuer, and non-canon warning.
  • ArtifactDependency: packet or image fingerprint, upstream claims and resolver version, validity state, and stale reason.

Resolution rules that should become invariants

  • A rejected, obsolete, unresolved, research-only, or generated-image claim cannot silently override established story authority.
  • A generic era or place envelope can constrain an image but cannot invent a named character appearance or named location.
  • Apparent age never defaults to chronological age when rejuvenation could materially change the image.
  • Hidden motives and private history do not enter renderer context unless translated into an approved observable action or expression.
  • Established function does not authorize invented hardware.
  • image_type and render_style remain independent fields.
  • A blocking missing definition stops production compilation; an exploratory waiver must be explicit, narrow, and temporary.
  • Every renderer instruction must be traceable to a resolved graph property or an explicit scene variable.
  • A changed upstream claim must either leave an artifact valid or mark it stale; silent uncertainty is not a valid state.
  1. Define claim, qualifier, provenance, conflict, and status schemas.
  2. Implement authority resolution and temporal/event resolution.
  3. Add qualified relationships, layered places, and capability/visibility models.
  4. Parse scene intent and select a bounded subgraph with a retrieval receipt.
  5. Separate graph resolution from clean renderer-packet projection.
  6. Add typed gap reports and scoped author waivers.
  7. Add fingerprints, reverse dependencies, stale-artifact reports, and targeted regression selection.

Each stage should have fixture-based tests before the next layer is allowed to consume it.

Immediate benchmark scenarios

  • Sylvan at multiple equivalent years: chronological age and apparent age resolve independently, with wardrobe constrained by the correct era.
  • Sylvan running on a beach while her Luminai manifests: identity, natural motion, place, contemporary surface civilization, and blue person-radiated energy resolve without turning the Luminai into a separate person.
  • Samuel during the Great War: role-specific apparent age resolves to approximately forty without rewriting his chronology.
  • A concealed advanced system in an ordinary setting: the packet shows approved consequences while withholding undefined hardware.
  • A two-character scene with a private adversarial history: blocking reflects only approved observable tension; the history itself never appears in renderer context.
  • A changed appearance anchor: only dependent packets, benchmarks, and images become stale, and each stale result explains why.

Remaining author definitions exposed by the research

  • Approved identity and appearance anchors for major characters at load-bearing eras.
  • Rejuvenation transition points and the allowed shape of apparent-age change between anchors.
  • Environment masters for named Seeds locations, including culture, class, infrastructure, maintenance, and ordinary life.
  • A controlled vocabulary for Luminai and daemon manifestation states, intensity, color, concentration, and behavioral effects.
  • Technology visibility decisions where capability is known but visible consequence or physical form is not.
  • Which unresolved graph gaps may be explored with waivers and which must always block.

Source reports

Decision status

Open. These findings are ready to guide the next implementation pass, but none becomes production behavior until it is implemented and regression-tested.