Project Explorer · working sheet
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.
Recovered records held against the working evidence.
Story development tools
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.
The system records those ideas and separates confirmed decisions from suggestions and unanswered questions.
Read how the system is designedEach question helps the author decide a missing cause, character choice, relationship, world rule, or event.
Open a workshop questionAn accepted decision can update character notes, the timeline, world rules, plot events, and the list of remaining questions.
Review decisions and supporting informationThe 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 planSeeds of the Throne is the working example. The notes, decisions, and workshop below are the live project, not a demonstration mockup.
Vault overview
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.
Conversations, mobile notes, and raw ideas are preserved.
Current context and compiled notes explain what the project means now.
Workshops ask one important question and preserve the author's answer.
Research, alternatives, story structure, and focused tests strengthen the work.
Scene plans, prose, images, and manuscript material are produced for review.
Selected material becomes the story site, Project Explorer, and public posts.
Each area has a job. Folder names are secondary detail.
Preserves incoming ideas and the order in which they developed.
00 Inbox, 01 Sessions
Keeps the detailed working knowledge and a smaller briefing used to resume work.
02 Story, 03 Context
Separates questions, reports, and usable findings from story decisions.
04 Research
Holds reviewed material prepared for readers.
05 Public
Holds scenes and manuscript candidates awaiting review.
06 Draft
Records choices, contradictions, current work, handoffs, and verification.
07 QA, 07 Coordination
Diagnoses missing connections and tests possible story directions.
08 Story Loop, 09 Story Exploration
Provides repeatable methods for writing, research, images, websites, and checks.
skills, scripts
Current story development
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
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 assessment0 / 10major story problems resolved
Story files
Search 605 documents about the world, characters, plot, research, decisions, workshops, and earlier ideas.
Give the bad bargain enough actual value to tempt an intelligent Konrad.
This packet supports the existing Story Completion Workflow. Its central gate was author-accepted on September 6. It does not answer SC-010 Question 7 or advance that checklist. Central synthesis: Astra, reviewed for integration on September 5.
Samuel approaches Konrad at his most vulnerable, claims that he too fell and was caught, and says he needs Konrad. He offers an apparently separate autonomous group with dominance over Samuel's group. The separation is false: the groups share a containment structure in which Samuel holds the hidden structural advantage.
These constraints inherit their source status. A working physical model, timing estimate, or accepted macro constraint does not establish every implementation detail.
Modules: 05, 07, 09. Read their accepted results before closing this gate. Open prerequisites can be explored provisionally, but do not mark dependent choices final. Module numbers are topic IDs; use the dependency order in the workshop index.
What apparently verified success makes Konrad trust the bargain while misunderstanding its boundary?
AUTHOR-ACCEPTED: Samuel's performed vulnerability and false autonomous-group offer make Konrad believe he is entering as the needed superior party; Daemon verification is resolved in Module 11.
PROPOSED: Konrad can issue genuine orders while Samuel observes dependencies. Strong alpha/beta fit; surveillance must have a later causal route into control.
PROPOSED: Samuel sacrifices something real to appear captured. Preserves both men’s intelligence; the cost must be meaningful and later recoverable only through the coup.
PROPOSED: The daemon genuinely controls one subsystem and falsely generalizes to Samuel. Strong technical temptation; avoid letting a single hack grant all authority.
PROPOSED: Followers, work and infrastructure return under Konrad’s formal role. Emotional and institutional appeal; signed terms must show the difference between appearance and actual limits.
Non-canon situation: Konrad orders Samuel to surrender a visible privilege; Samuel complies, and the daemon marks that narrow success while Konrad announces a much larger victory.
Record what each person wants, can know, can refuse, and can actually change. Name the observable difference between the selected alternatives.
Module: 10 · Daemon confidence and the autonomy promise
Gate: What apparently verified success makes Konrad trust the bargain while misunderstanding its boundary?
State: DRAFT / PROPOSED / AUTHOR-ACCEPTED / REJECTED / DEFERRED
Author answer (verbatim):
Exact restatement:
Selected option or new answer:
Why this tradeoff:
Rejected alternatives and reasons:
Prerequisites resolved / deferred:
Scene test: choices, permissions, evidence, cost:
Adversarial result:
Remaining uncertainty:
Explicit acceptance wording and date:
Affected notes updated:
QA decision reference:
Workflow task and macro-depth effect:
Website rebuild and verification:docs/faction.html, the matching source in 05 Public/Atlas/, and the workshop projection.SC-003 already accepts false process enforceability, sustained environmental confirmation, and Konrad's motivated reasoning. The alternatives here test how that confirmation is experienced; they cannot replace the accepted cause with a single forged technical proof.