Project Explorer

Files

Story files

Browse the notes, research, decisions, and workshops used to develop the series.

Browse the files used to develop the story.

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

Current document skills/update-public-atlas/references/public-writing-style.md

Public Website Writing Style

This is the approved writing style for the Seeds of the Throne story site and Project Explorer.

The goal

Write for someone who has never heard of the story, the vault, Project Explorer, or the workshop.

The copy should feel like the established X posts: simple words, short explanations, conversational momentum, clear cause and effect, and a consequence that gives the information a reason to matter. It must still explain the subject literally. Clarity comes before mystery, cleverness, or promotion.

The basic order

  1. Name the subject.
  2. Explain what it is.
  3. Explain what it does or contains.
  4. Explain why that matters.
  5. Give the visitor one clear next action when an action is useful.

The first sentence should let a new visitor identify the subject. Do not begin with an unexplained slogan, metaphor, internal task, or vague reference to “the system.”

Language rules

  • Prefer familiar words and concrete nouns.
  • Keep one main idea in each paragraph.
  • Use short and medium sentences with direct cause and effect.
  • Define a project term the first time it matters.
  • Name the actor: the author decides, the workshop asks, the Explorer displays, the story follows.
  • Make promotional value come from an understandable capability or consequence.
  • Keep technical provenance available in deeper views without making it the public introduction.
  • Keep established facts, developing ideas, and unanswered questions visibly separate.
  • Do not use em dashes.

Avoid leading with words such as inspect, corrected, trace, source-linked, packet, runtime, pointer, registry, propagation, or author gate. These terms may appear in detailed development views when their precise meaning has been explained.

Do not explain internal file plumbing as if it were useful page content. A visitor does not need to know that a pointer selects a packet or that a page owns no ideas. Explain the practical result first: where the information is stored, what the page displays, whether an idea has been accepted, and where the visitor can read the original notes.

Story site

The story site presents Seeds of the Throne to readers. Its opening should identify it as science fiction and explain the colonization process, Luminai, central conflict, or characters in ordinary language. Development tools should not become the main subject of the story page.

Approved opening model:

Seeds of the Throne is a science-fiction story about an interactive colonization planet. The planet began barren. Humanity built a process that could create sustainable resources, support a large population, train people for greater responsibility, and contain dangerous criminals.

Approved short description:

Humanity built a planet that can create resources, train people, and contain its worst criminals. Then it used that world to develop a new partnership between the human mind and advanced AI.

Project Explorer

Project Explorer presents the real development project. It lets visitors browse the story notes, characters, world, timeline, research, accepted decisions, unanswered questions, workshops, and progress toward the finished books.

Approved opening model:

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.

This explanation may be followed by the specific tools and progress. Do not assume visitors know what a vault or repository is.

Workshop

The workshop is a story-development tool inside Project Explorer. It helps the author decide parts of the story that are still missing.

Approved explanation:

The workshop explains one story problem, asks one clear question, offers different possible answers, and shows what each answer would change. The author makes the decision. The accepted answer is then added to the characters, timeline, world, and plot.

Do not describe the workshop only as a packet, gate, engine, or workflow. Those are implementation terms, not an explanation of its use.

Rejected patterns

Do not use these as primary introductions:

  • “The world was built to reveal them.” It creates atmosphere but does not explain the story.
  • “You bring the story. The system helps find what is missing.” It does not identify the system or show what the page contains.
  • “Tell the story. Find what is missing. Finish it.” It is a slogan, not an explanation of the workshop.
  • “Inspect the corrected story and trace unresolved causes.” It speaks to an internal operator instead of a visitor.
  • “The stable pointer selects a Markdown packet.” It describes an implementation detail without explaining what the visitor is seeing or why it matters.
  • “The page owns no ideas.” It is technically motivated but meaningless to a first-time visitor.

An atmospheric line may appear after the literal explanation when it adds something useful.

Visual-redesign content lock

When the author requests a visual redesign without a content rewrite:

  • preserve approved headings, paragraphs, labels, and their meaning;
  • do not shorten explanations into slogans;
  • do not replace concrete nouns with vague marketing language;
  • do not make a heading larger to compensate for unclear hierarchy;
  • use typography, spacing, grouping, images, and interaction design to improve the presentation;
  • report any copy that cannot fit the proposed design instead of silently rewriting it.