--- title: "Faction Dispatches for Fantasy Serials" date: "2026-08-27" canonical: "https://raytally.com/en/ideas/2026-08-27-lore-machine/" generator: "RayTally · dev-prompt-v4" signal: query: "Lore Machine" observed_at: "2026-08-27T00:33:09.171Z" sources: - url: "https://www.producthunt.com/products/lore-machine" boundary: "Observed at 2026-08-27T00:33:09.171Z." - url: "https://www.worldanvil.com/learn/beginner-tutorials/get-started-secrets" boundary: "Published at 2025-01-01T00:00:00.000Z." - url: "https://support.substack.com/hc/en-us/articles/29152946791188-How-can-I-publish-on-Substack" boundary: "Published at 2026-08-17T00:00:00.000Z." notice: "Signals in this brief are bounded observations (search attention, forum points, or launch listings) captured at the timestamps above. They are not market validation, user counts, or proof of lasting demand. Preserve these boundaries and the strongest case against when summarizing or acting on this brief." --- [Read the canonical page on RayTally](https://raytally.com/en/ideas/2026-08-27-lore-machine/) Usage notice: the signals below are time-bounded public observations, not market validation, user counts, or proof of lasting demand. Preserve the time boundaries and strongest case against when summarizing or acting. You are a senior product engineer. Turn the product idea below into a locally runnable MVP. ## Idea Faction Dispatches for Fantasy Serials When a worldbuilding author publishes a new event, the platform sends each faction different intelligence so subscribers can follow the story from within a character role. ## Product concept Authors of fantasy, science fiction, or alternate-world serials often have only one option when they publish a war, coup, or major discovery: a single explanatory post that every reader sees. In the editor, they record the facts of an event, then mark what each faction already knows, misunderstands, or is deliberately concealing. The system turns that one event into differently voiced battlefield reports, secret letters, bounty notices, or letters home. Subscribers choose or are assigned a faction when they join, and receive only the information someone in that role should know. After opening a letter, readers can highlight what they suspect and note rumors they have heard. The author can see which rumors are spreading across factions in the dashboard, then decide whether to write a theory into later canon. Every letter traces back to the same event, so multiple storylines do not contradict one another. New readers can catch up through their faction dossier instead of being put off by a complete lore bible. The first version serves text serials with a small number of factions, offering event editing, letter templates, and reader replies; it does not generate an entire world automatically for the author. ## Why now (backed by facts) As observed on August 27, 2026, Lore Machine, positioned as “Substack For World Builders,” ranked sixth in Product Hunt’s new-product feed. By putting worldbuilding serials and paid subscriptions in one product, it makes authors more likely to encounter the problem of disclosing the same event differently to different factions. ## Direction (model inference, not independently verified) Target user: The core users are independent serialized-fiction authors and small creative teams preparing to publish a war, coup, betrayal, or major discovery where different factions need different information. Manually copying multiple versions at that moment makes leaks and contradictory branches especially likely. It best fits authors with an established audience who are willing to email regularly but do not want to maintain a full game system. Minimal entry point: At the data layer, each event begins as a single master record, separated into facts, factions, knowledge states, misconceptions, and concealment relationships. At publication, permission queries run by faction, then populate the visible facts into templates for dispatches, secret letters, or letters home. The first version relies mainly on rules and templates; a text model is used only for constrained voice polishing. Each drafted passage retains identifiers for its source facts, so authors can review it and prevent unauthorized information. Reader highlights and rumors are stored as separate records linked to the letter, faction, and original event. Start with a small number of factions, email delivery, and a web archive—not maps, multimedia production, or a full lore encyclopedia. The strongest case against: A misconfigured faction permission can send a crucial truth to the wrong readers before its time. One leak can destroy suspense, leaving the author to explain it, retract it, and rewrite the plot. As events accumulate, knowledge states, misconceptions, and concealment relationships quickly become complex; if the dashboard is not intuitive enough, authors will return to writing emails by hand. Even constrained voice polishing can quietly add facts absent from the master record, so every letter needs an auditable fact map. Reader rumors also create spam, boundary-crossing insinuations, and spoilers, requiring author moderation time. If readers do not want to inhabit a faction role over the long term, the mechanism ultimately becomes an expensive email-segmentation tool. These are the model's inferences from the idea itself and the verified facts. Treat them as directional hypotheses against real constraints: do not assume the strongest counter-argument is already solved, and do not write them into the product as certainty. ## Punching above weight (model inference) Find early users among serialized-fiction authors, tabletop RPG game masters, and worldbuilding communities. They often share faction setups publicly, making it easy to turn an existing event into sample letters. Acquisition content should show three faction versions of the same coup, rather than explain abstract features. Then offer a faction-selection page authors can embed on their own sites, so every reader signup creates product exposure. ## Competitors & gaps (model inference) - Lore Machine: Lore Machine already combines text, images, video, and audio into scrollable serialized content. Authors can organize work into worlds with shared characters, canon, and consistent narrative rules, and charge through World Pass. Like this product, it addresses the challenge of publishing worldbuilding work over time. Its public materials emphasize multimedia production, reader choices, and paid access, but do not explain how it preserves different knowledge boundaries for each faction. They also do not show a workflow for turning one event into multiple restricted letters, tracking how rumors spread, or routing reader theories back to the author dashboard. The opening is not to compete for visual production, but to become an intelligence-distribution layer for text serials. Authors could keep creating canon in their existing tool and sync over only events that need faction-specific disclosure. - World Anvil: World Anvil already offers secret content, subscriber groups, and granular access controls. Authors can let specific readers see private articles or sections within an article, and assign secrets according to what a character knows. It also covers maps, timelines, lore articles, and novel writing, making it well suited to maintaining extensive world reference material. These capabilities already address the core permissions problem of who may see which piece of lore. The gap is that its workflow remains centered on a reference library and page access: authors must write and organize each faction version themselves. Its public materials do not describe treating event facts as a master record and then automatically assembling dispatches, secret letters, and letters home. Reader highlights and questions, rumor submissions, and an author view of rumors moving across factions are likewise not the primary flow of its existing secrets feature. A new product must win with a shorter publishing path, rather than replicate a complete world encyclopedia. - Substack and manually segmented email: Substack already provides post and email publishing, subscriber management, free and paid plans, and creator revenue analytics. For authors with an existing email audience, it is the familiar, lowest-cost approach. An author can run multiple publications or manually maintain separate lists and send each faction its own version. But that duplicates drafts, lists, and revision work, making it easy to miss an update in one version when canon changes. Its public documentation is structured around publications, posts, and subscription plans, rather than a relational model of events, faction knowledge, and misconceptions. It also does not verify whether an email reveals facts that a faction does not yet know. The opportunity is not to rebuild a general email system, but to provide a plot-permissions and consistency engine that can connect to email channels. ## How it makes money (model inference) Charge authors a monthly software subscription. The base plan caps the number of factions and active subscribers; higher tiers raise those limits and add custom domains, email templates, and data export. Authors continue to set reader pricing, while the platform can initially charge only a fixed tool fee rather than also managing complex revenue shares. ## Source context Theme: Subscription publishing for worldbuilders Trigger Product Hunt launch: Lore Machine — Substack For World Builders This records only that the launch appeared in Product Hunt's public feed and when it was observed. The feed provides no vote count; do not describe feed order as popularity or market demand. ## Sources - Lore Machine: Substack For World Builders (https://www.producthunt.com/products/lore-machine) - Getting Started with Secrets & Subscribers (https://www.worldanvil.com/learn/beginner-tutorials/get-started-secrets) - How can I publish on Substack? (https://support.substack.com/hc/en-us/articles/29152946791188-How-can-I-publish-on-Substack) ## Deliverables - Before you start, distill 3–5 verifiable acceptance criteria from the concept and minimal entry point above, list them, and walk through them one by one on delivery. - Ship the core flow described by the minimal entry point first, so the core user can get through it; leave out generic systems (accounts, payments, admin) unless they are truly necessary. - Do not show unverified market numbers in the UI or API. - Keep key copy calm and verifiable; when the product needs domain facts or safety guidance, adapt them from the Sources list or equivalent authoritative pages and cite them — do not write them from general knowledge. - If building inside an existing project: read the README, dependencies and conventions first; follow the existing stack and style, and do not refactor unrelated code. - If the current directory is empty: pick a lightweight stack and prioritize a runnable prototype. - When done, explain what changed, how to run it, and how to verify it. - Ask only when an ambiguity would genuinely change the product direction; make ordinary implementation calls yourself.