Well, I finally bit the bullet and bought a month of the ChatGPT Pro 100 plan. Conversion into CAD makes it even pricier, but I’ve been realizing lately that for a very focused user, the value you can get out of it is much, much higher. Almost absurdly so.

I worked for a time as a product manager on a blockchain safety-related project that lasted a few years. We had an engineering team in the EU that I met with a couple of times a week, and while they did a good job, the experience working with them is not like the experience I have working with Codex. With real human engineers, you go into your Jira cards or whatever to keep everything organized, talk through proposed changes to whatever the current state is, and then you wait. And wait and wait and wait. And hope. You hope they’re going to come back with some next stage of the work piece that fits the ask and the criteria, and that moves you forward on the next thing.

But it can take days or weeks to accomplish something that to a non-engineer seems like not a big change, but has a lot of moving pieces under the hood. And there is usually a lot of back and forth and going back to the drawing board and refinement until things reach an acceptable level. So that is the baseline I am comparing against, from the perspective of product manager.

My experience with Codex makes that entire process seem obsolete. Changes that would have taken weeks are done in five minutes in a big batch. There’s back and forth, but the process of talking it out and giving some very light guidance makes the whole thing not just resolvable in a conversation, but built by the end of it. And not to trash-talk human engineers – because I still believe there’s a lot of value there – but when I work with Codex, I don’t have to worry about making anybody annoyed with my nitpicky product managerial behavior. Which… let’s face it, is constant. That’s what the job is, more or less.

But in tackling larger projects with a lot of interconnected moving pieces – as opposed to one-off tools or piece-meal work – I found that Codex lets you move so fast that you encounter other kinds of problems in simply tracking what the hell is going on, and what is happening next. It accepts all your bad habits and poor communication into its endless bucket, and does its best to give you what you want. But if what you want is unstructured and evolving (aka “exploratory”), it can get gnarly keeping things straight.

So that’s why at a certain point, I had Codex spin up an on-going lightweight system to manage tasks. It’s based loosely off Jira, but in its purest form is simply a .md file that has named numbered “cards” for each issue. I also tried having it do a graphical representation of the contents of the cards where I could update them that way. But what I found is that both the detailed sheet and the graphical UI version of looking into the issues become not that relevant to check constantly as the human operator. The GUI I didn’t really touch again after having built it. The .md file I would track in the side panel during early build conversations. But now I don’t even open it. Because I just say to Codex things like, “What’s the next logical batch of work to accomplish here?” Or I say to finish all the low-hanging fruit to correctly complete as many cards as you can. And it tells me what the work block is going to be, which cards it will solve, etc. And then it. Simply. Does. It.

It’s unreal. Is it production ready? Could I ship this code out to real users? I don’t know, and I don’t care, because I am building crazy custom tools for me that narrowly suit my extremely specialized use case and weird ideas. And if I had to engage an engineer to execute on these, it would cost me tens of thousands of dollars at the very least. And take probably a two year build, and by that time it damn well better be a piece of software that is going to earn me money over the long haul to get back what I sank into it.

But like I said, even if I drop a hundred or two hundred bucks in a month or two, the value of what I get back, and what I’m enabled to do is so so so so so much higher that it’s just ridiculous.

One other note I wanted to add when I was on the Plus plan and constantly battling against the dreader 5hr usage limit… I told Codex to measure the remaining weekly & monthly usage before and after completing each task, and then estimate usage. At first it was strictly based on Agile-style story points, which are more about perceived (squishy) complexity. But over time, we were able to refine the estimates to be pretty accurate predictions of how many usage points we were likely to use, based on the contents of cards that were queued up for the next staged run.

There’s a related sizing skill that Codex made, which I also had include as part of that chunking cards into sub-tasks to be able to more completely and accurately step through them.

I will say that using a card based system this way has been invaluable – even if I never actually lay my eyes on most of the “cards” that get generated. It gives a more structured interaction, and much more qualified outputs – at least they seem that way, as someone totally unqualified to judge realistically at the technical level (I’m really not a software engineer).

---

It’s crazy how much I accomplished since yesterday morning, when I began the post section above. It’s also hard for me to recall as to what my own personal inward “agentic state” was when I wrote the above, so I’ll have to reboot.

One question I’ve been having seeing people reverse engineer major software suites like Adobe, Word, etc using AI is that at a certain point, you have to start asking: why would you use anyone else’s software? Especially when AI could reverse engineer anything, or give you a control surface into any process that is completely customized. Yes, yes, I know good software takes a lot of work and refinement. But eventually… it won’t? It will just be good straight out of the box. That is still not really the case today, as I’m well aware after banging away on Codex for many days solid now. It takes an incredible amount of hand-holding, patience, careful review, and guidance to end up with software that is really good and usable. But the point is that it is within sight. It’s achievable. I am doing it.

I also can’t overstate how important it is that this liberates complex software development from commercial demand, or the need to make your money back for the time spent developing, etc. Especially if this is something you made in a few days, and your actual usage cost during development is relatively low. And the fact that you can make things perfectly customized to your own use means you don’t have to beg and plead with other people to come use what you made. You don’t have to do it as an SaaS and run a bunch of infrastructure and plead for investor monies. You can just simply do it.

For the moment with current state of Codex, I will say that if I did not have a background in product management, I think it would be VERY VERY difficult to be able to use Codex as a non-programmer for any kind of complex custom build. You might be able to pull off narrowly-focused apps or utilities with it, where you can let it make much of the decisions about how it should go on its own. And that might very well be good enough. But I have a very particular vision in mind, which has been clarified a lot by running it through this process and getting the results I’m getting. It’s changed my whole way of thinking about how to interact with and organize work with AI tools.

One other thing that I am glad I figured out is that there are two roads into a complex application. I took the first one, of first getting Codex to build every section based on what the section does, get its functionality more or less working. When you do that approach, you end up with a really cruft-ridden UI/UX – or at least I did. So once I had completely sketched out the full functionality, then I went through and did exploratory design patterns for the specific types of actions and transitions which recur often across the application suite. And then in refining and improving those on first a pattern-specific level, and then a sample UX implementation level, now I’ve refined and improved the overall functioning of the app tremendously. But if I had started only with the isolated patterns, I would not have had enough context information about the work being done to understand how to design patterns for it… so…. 6-7.

Anyway, I’m doing too many things at the same time, so thought I would just drop these preliminary notes to come back and expand on more as the project develops more!

I keep seeing news stories like this, trying to debunk the idea that Ukraine’s drone strikes against Yandex did not cause a massive outage of apparent bots on social media. So far all the pieces like this I’ve seen hinge on trying to say that the Cloudflare graph is for search bots, not social media bots. And then they bring out a bunch of experts in the space (who track the data science more closely than I do, I have no doubt), who said “We don’t see it.”

But the simple fact is on Twitter now, you do see it. Even still. The difference is day and night. If you go onto “controversial” tweets, or look at the White House timeline for recent tweets, it’s all people with extremely critical hot takes against that account.

So, I think we can say, search bots do not equal social media “bots.” But beyond that, how much evidence of which kind proves the difference that is everywhere obvious when you go on Twitter?

I posted elements of an experiment I ran last night for the second time, so as to get cleaner results than my even more hodge-podge first run. I’m thinking about it as Narrative Rehydration, and you can see more at the Github repo linked.

Briefly, in my own language, Narrative Rehydration focuses on whether you can take a sort of loosely encoded version of an underlying story structure, and with some other elements that we will get into, plop the whole package into a gen AI system, and have it render results which are faithful to the structural skeleton described. We’re not trying to reproduce exact words from some original text version of a story, because there is none.

Instead, a sample story broken down into this format would look like the below. I had the system encode Little Red Riding Hood, and then went in and tinkered with it a bit for clearer separation of parts:

time:morning > mother > give > basket @ girl
mother > warn > "Stay on the path." @ girl
girl@woods > meet > wolf
wolf > ask > "Where are you going?" @ girl
girl > answer > "To grandmother's cottage." @ wolf
wolf@cottage > swallow > grandmother
wolf@bed > disguise > as[grandmother]
time:afternoon@cottage > girl > say > "What big eyes you have."
woodcutter@cottage > cut > wolf.open
grandmother.alive > emerge

Within this, I’m referrng to each line as a “frame” and > marks are acting as flexible connectors between elements within a frame, which consist of things like time & setting, actors (symbols), actions/events, and objects. There are also some text bits which are “pinned” within the frame, in quote, such that they are supposed to be used verbatim in final outputs – versus the rest which is supposed to be interpreted and fleshed out by the renderer based on rules included in the packet.

I won’t repro the whole thing here, you can see it in the readme on Github, but included in the demo packet sent to the renderer are also instructions for reading the coded syntax above, and then the registry slices. This story example does not use my full Lorecore registry, but instead uses a demo of simplified registry slice contents, which looks like this:

REGISTRY SLICE — the only units that may appear

Characters — each entry: key — Name | “byname” | description

• girl — Maria | “the girl in the red hood” | A young girl carrying a basket to her sick grandmother.
• mother — Esmeralda | “the girl’s mother” | Sends Maria with the basket; warns her to stay on the path.
• wolf — Grumple | “the hungry wolf” | Tricks Maria, reaches the cottage first, swallows the grandmother, waits disguised in her bed.
• grandmother — Monique | “the sick grandmother” | Lives alone in the cottage; swallowed; emerges alive.
• woodcutter — Gary | “the passing woodcutter” | Intervenes; cuts the wolf open.

Props & settings — named only, never act

• basket — “the basket of food”
• bed — “the bed”
• cottage — “grandmother’s cottage”
• woods — “the dark woods”
• path — “the path”

So the included Registry slices is like the cast of characters & props list, and any important information about them.

Then the encoded frames at top say what the characters & props did or had done to them, etc.

And then there are rules, instructions, and constraints that are included:

ALLOWED USAGE

• First mention of a character: name + byname in apposition, set off with commas. Write the byname without quotation marks. Later mentions: bare name.
• Quoted speech in frames is pinned: reproduce it verbatim. Never paraphrase, extend, or add dialogue.
• Props (basket) never act. Settings (woods, path, cottage) never act.
• Nothing outside this slice may appear. No new characters, no new places.

LICENSED INVENTION — declare it or don’t do it

• [manner] — how a licensed action is done. Must not change the action.
• [texture] — sensory detail of a licensed unit or its immediate scene. No new entities.
• [bridge] — minimal linkage between frames (“afterward”). No new events.
• BANNED: new characters, new plot events, new dialogue, motives, added causes.

Then for the demo packet, I am asking the renderer to produce three different versions based on the packet contents: SHORT, EMOJI, LONG. Emoji is obviously the most compressed, followed by Short, and Long allows for the most liberal invention.

Without going into it deeply here, it then runs some checks, to try and force the renderer to account for itself in any inventions that it did, units that it used from the registry slices, and so on. I had prior versions of these checks I ran in an earlier one that I think might have been different or better, but anyway, this gives still the idea.

Lastly, this is a “rehydrated” SHORT rendering of the encoded story-frames included at top. This is meant as a baseline against which to compare other model’s renderings. I think this rendering comes from a Muse work session:

• In the morning, Esmeralda, the girl’s mother, gave the basket of food to Maria, the girl in the red hood.
• She warned Maria, “Stay on the path.”
• Maria, in the dark woods, met Grumple, the hungry wolf.
• Grumple asked Maria, “Where are you going?”
• Maria answered Grumple, “To grandmother’s cottage.”
• At the cottage, Grumple swallowed Monique, the sick grandmother.
• In bed, Grumple disguised himself as Monique.
• In the afternoon, at the cottage, Maria said, “What big eyes you have.”
• Gary, the passing woodcutter, cut Grumple open at the cottage.
• Monique emerged alive.

So you can see more or less how the renderer synthesizes from the raw encoded frame desciptions that tell story actions, and glues that together with the registry slice information, and then clothes it according to allowed/licensed usage in the packet.

Ultimately, the packet here is a simplified version of a “cassette” to use the terminology of tape.deck.

Anyway, I saved complete results from four different renderers based on the text packet shown in the Github repo’s readme file. They are:

• ChatGPT render results
• Deepseek results
• Gemini
• Perplexity

And since Muse designed the packet in its demo version (and did the original lift for my real bigger registry, before I moved it over to Codex), I had it do scoring of results above.

• Muse scoring of results

There are many different findings that are interesting here, and I’m frankly racing to keep some sort of semblance of being able to track all of what I have going on in some semi-coherent fashion. If nothing else, I think it’s interesting that four different models render this frame in different emojis:

time:morning > mother > give > basket @ girl

• ChatGPT: 👩🏻‍🦰🎁🧺👧🏻
• Deepseek: 🌅👩🎁🧺➡️👧
• Gemini: 🌅 👩‍👦 🧺 ➡️ 👧
• Perplexity: 🌅👩➡️🧺👧

It’s noteworthy that three of the four renderers interpreted time:morning as emoji-sunrise 🌅. And then to see the various interpretations of [woman|mother] and how giving (🎁) a basket (🧺) to (➡️) girl (👧🏻) is variously portrayed. I personally prefer ChatGPTs one as the most cleanly legible. I see that a woman gifted a basket to a girl pretty readily, without too much extra cruft… I don’t actually care about morning\sunrise etc here so much as that core action happening, regardless of time of day.

Anyway, all of this is significant because it shows a proof of concept around a simple version of cassettes. More to come! My actual work is so far ahead of what I’ve even been able to blog about here, and it’s only been a handful of days I’m plugging away at this…

Well, despite only being on a $20~ ChatGPT Plus plan, and being subject to 5hr usage limits, I’ve managed to make a lot of progress on the various parts of the tape.deck app. Last time, I only had some wireframes, and a simple spec, now I have a lightweight Jira clone running in ChatGPT Work that has split everything down into tasks (and sub-tasks) and stages, story pointed it all out, and figured out a means to estimate 5hr usage % for each given card relatively accurately ahead of time.

Because I’ve got a structured way to track and step through tasks in some kind of logical order, I was able to get up and running a functional Registry app view:

The Registry was its own set of tasks to extract, review, promote, or ignore both symbols (entities) and links betwen them from the 142 books in the Lorecore series. Now – as far as I can tell anyway – all the important bits and bobs in the multi-verse of my story now each have their own registry entries, which track who or what that thing is, where it is referenced in the series, and links out to other entities, etc. This runs either in the browser in ChatGPT (where it is small and cramped) or in another browser running off a port on localhost.

Then there is now a functional knowledge graph or “story space” view which shows those symbol units and their connections as clusters. It looks something like this:

It’s all evolving a bit, but implementing a Jira-like tracking system with numbered “cards” for issues with semi-accurate build estimates has really helped change the game for how this process can go. I still have to work around the 5 hour limits, but I can do so with a much clearer plan of what can be accomplished, and not have things get stuck in a void of “Thinking” forever, until its used up its allocation, without ever finishing anything… (One trick I devised for planning is instruction the system to decide what to focus on to achieve in the next five minutes that will have the highest overall impact for moving forward.)

I’m really really close to pulling the trigger on the next higher tier subscription so I can reduce some of this friction and waiting, but I’m scared that if I do that, I will just end up using it even more than I already am – and maybe my brain is already spinning fast enough! Plus, there’s the $$$ question too. But the more I use this, the more I think how absolutely insane it is to be able to do all this solo, with no engineer, for $20 a month. Even $100 or $200 for a month if you have a really targeted project you’re doing is maybe the deal of the century…

[Written with GPT-6 Instant, and a loooot of hand-holding. Doesn’t quite get at everything I want to get at, but an acceptable placeholder for now!]

---

Traditional propaganda attempts to establish a particular [linear] narrative. It connects events, people, and ideas into a story designed to lead an audience toward a specific conclusion. A leads to B, B explains C, and C becomes evidence for D. But there is another, less recognized attack surface around generative AI, one that doesn’t require a coherent story or even a specific conclusion. Instead, it relies on flooding the information environment with fragments that repeatedly associate certain people, organizations, events, and ideas. The goal is to make those associations so prevalent that they become part of the background context from which AI systems construct answers. This is associative saturation.

Imagine thousands of articles, posts, and websites repeatedly mentioning a particular institution alongside corruption, foreign influence, and secrecy. None needs to make a direct accusation or present a complete argument. Some fragments may be accurate, others misleading, and others entirely fabricated. What matters is their accumulated effect. When an AI assistant searches the web to answer a question about that institution, it encounters a dense cluster of related concepts across seemingly different sources. The repetition creates an appearance of corroboration, even when those sources are recycling the same unsupported associations. The information environment develops certain habits: particular concepts keep appearing together, and certain connections become easier to make than others.

This exploits a basic characteristic of generative AI: these systems don’t simply retrieve and repeat information. They synthesize relationships, construct explanations, and produce conclusions based on patterns in the material they encounter. They also draw on learned bundles of characteristics that tend to occur together. When associations are repeatedly reinforced in retrieved material, they can exert an outsized influence on the resulting answer. A model may connect two concepts because they frequently appear together, not because reliable evidence establishes a meaningful relationship between them. The strength of an association becomes confused with the strength of the evidence. The attacker doesn’t need to dictate the final conclusion, only strengthen the associations that make certain conclusions more likely to emerge. The model’s generative process performs the final synthesis.

This is what distinguishes associative saturation from conventional narrative warfare, although the two can work together. Traditional propaganda repeats messages to reinforce particular interpretations. Associative saturation reinforces the relationships between concepts that make those interpretations seem natural in the first place. A campaign can simultaneously push explicit narratives toward human audiences while flooding the wider information environment with loosely connected fragments. In some respects, this resembles the dynamics of QAnon, where scattered clues and loosely connected claims encouraged participants to construct their own elaborate explanations. With generative AI, the machine can perform much of that connective work, assembling apparently coherent answers from a manipulated collection of sources.

The under-recognized target here is not necessarily the human audience or even the AI assistant rendering search results, although both remain important. It is the topology of the information space itself: which concepts cluster together, which connections are repeatedly reinforced, and which explanations become easier to generate as a result. Rather than controlling a single story, associative saturation attempts to shape the underlying patterns from which many different stories can emerge. This makes it a potentially powerful complement to traditional propaganda, because the same information environment can influence both what people encounter and what AI systems subsequently tell them.

Narrative warfare attempts to control the conclusions being transmitted. Associative saturation attempts to control the space of conclusions that can be generated.

---

[Originally inspired by this Ben Shultz tweet, where I got to trying to elaborate more fully what it would look like to try to manipulate the model itself over and above human end-consumers.]

So I’m moving my Lorecore symbol registry out of Muse and into Codex, which seems more competent for this kind of data approval and management pipeline work. The failures I kept seeing out of Muse related to its inability to seemingly sort out symbol unit relationships and identities with one another in such a way that it could quickly and without repetition give me items for review in an efficient manner.

Codex was able to ingest a handoff from Muse, and seems to be swimming through it, though eating up my usage, which is why I originally kept them separate. But right now, it will just be (I hope) a bigger up from usage in Codex, combined with the eventual performance boost of having it all in one place. Still figuring out then, what Muse is actually best at. I did like how it handled orchestration, so maybe that is the best place to leverage its strength in the work I’m doing.

That draft of the simple spec for tape.deck that 6.1 Sol generated is “pretty good.” Not perfect, but pretty good. Some things I would have excluded for initial tighter focus, but also, whatever. Some of it represents a sort intellectual archaeology of how the idea and the process have evolved too, so don’t want to cut too much of that out. But neither do I want to overwhelm potential readers with TMI, which is incredibly easy to do when your workstream involves generative AI as an essential part of your tooling and ideation.

So, I thought a next useful step would be expose another side of those explorations that I’ve done to show some of the ground that has been covered, and what the findings were, so as to bring it all back to the main branch eventually to continue composing pieces of the amalgamated toolbox that tape.deck represents.

Anyway, what follows are simplified wireframes I had ChatGPT do of different key screens within what I imagine one implementation of tape.deck could look or function like:

---

Story Space view

So this screen visualizes a theoretical corpus – in my case it is EPUB files from a linked narrative multiverse project. And this would be generated after subjecting those files to conversion to plain text formats, and then running my SYMBOL SCAN skill over them to pull out the most important-seeming entities (“symbols”) and associations between them for review and promotion.

This story space view then lets you visualize those various symbols and their connections as linked clusters, which can then be expanded or recombined in other ways in other views.

Registry view

For each symbol node that appears in the story space, there is a corresponding registry entry. This is a record of all known information about a given symbol, including its “attestations” – which books it appears in, what quotes reference it – key links to other symbols, usage rules or restrictions for that symbol.

[Apparently Lucasfilm has a FileMaker database they use for a similar purpose for Star Wars in-universe continuity, which is called The Holocron.]

As the composition process progresses through the workspace, one of the things that gets included in the capsules for any finished “cassette” (to be sent out to renderers or playback environments) is registry slices. That is, one of the key capsules that gets transmitted with cassettes is enough information from the included symbols’ registry entries to allow renderers to faithfully reproduce the underlying cassette’s contents.

Builder view

These next few screens feel a bit jumbled to me, and they have some different tab or section labeling that is inconsistent with each other. But the point this is trying to make is that cassettes can be composed out of nested units: capsules (and sub-capsules), blocks, frames. These can be chained together as sequences, or linked via decision-points for branching narrative outcomes. The above screenshot is intending (I think) to show the ability to arrange and edit capsules, chains, and blocks together in a Builder interface.

Anyway, these are all just initial visualizations and the specifics are not all completely nailed down yet.

Cassette view & preview

Two different views into the same finished cassette, the first showing more the complete package (capsule flow, registry, etc), and the second a more focused view into the specific linear content elements in their arranged final forder:

Focused version:

Rendered outputs view

From the finished cassette, various types of rendered outputs could be produced, either by the creator of the cassette directly themselves, or by third party renderers or playback environments which might read from the cassettes down the road. The most obvious modalities that come to mind for rendered outputs would be text, audio (narration, music, sound effects), video, VR artifacts or scenes, etc.

As I wrote about in my original post about a workflow for using AI in video, each of the generated outputs is pegged to the frame, block, or capsule which it depicts or renders through available media formats. Conceivably, the creator of a cassette (or a cassette’s own automated evidence gate checks) could go through a review queue of generated outputs and approve or reject items which do or do not match the ideal vision represented by the cassette. And then, in those cases, approved artifacts could be included with the cassette as it travels onwards to other generation or playback environments.

Or presumably, from there, the cassette creator could simply output various different complete renders: a finished ebook (or series), a dramatised audio book, a complete video, etc. And then the selected artifacts made available are the only authorized ones by the cassette’s creator, and the underlying cassette does not travel. And they could always come back in a few years and use new technologies to re-render the underlying story structure without having to re-write it.

Anyway, hopefully the visualizations help ground it more!

It’s difficult to describe the process behind using AI to build a tool that you don’t quite know what it is, but now that you have the ability to do it, you’re compelled to continue and to find out.

These things sometimes take time to reveal themselves though, and I think I’m starting to understand what this one is and how it functions, out of the other bits and bobs I’ve managed to piece together of the “grand idea” (more of an intuition) that is fueling the whole thing.

For now, it’s called tape.deck.

Here’s a faux diagram that I got ChatGPT to make, and I think grounding it in a physicalization really helps for comprehension:

The idea in a nutshell is this:

Generative AI makes it possible to realize the same composition in many forms. This calls for tools that let authors shape a story’s underlying structure and guide how it becomes text, images, audio, or video.

---

After much back and forth, I managed to coax a pretty coherent simple specification for what this app/system/workflow/pipeline/etc. ought to be able to perform – at least for now. On-going usage and exploration would guide future development. Included below is GPT-6.1 Sol text:

---

tape.deck — simple app specification

Version 3 · October 8, 2026

What the app does

tape.deck supports medium-independent authoring and composition. The author arranges symbols, blocks, capsules, and instructions into a cassette that different renderers can realize as text, images, narration, or video. Audio and visual references can guide those realizations.

Author once, render many.

A cassette contains the underlying composition and the information needed to interpret it. Different treatments can change its expression while preserving its authored arrangement and constraints. Specific human-authored text can be included when exact wording matters.

The composition package

• Cassette — the whole package from which a medium-independent composition can be mixed and rendered.
• Head capsule — the first capsule; describes the cassette and holds shared instructions, mix settings, and rendering constraints.
• Registry slices capsule — contains background references, definitions, and allowed usages for the symbols included in the composition.
• Content capsules — flexible containers holding blocks or nested sub-capsules. Capsules can be chained together in sequences.
• Blocks — groups of compositional material that can be chained into sequences within a capsule.
• Frames — sit inside blocks and identify which symbols perform which actions upon which other symbols.
• Symbols, or symbol units — addressable elements drawn from the registry, including people, places, objects, groups, and ideas.

Setting and instructions can be established at cassette, capsule, or block level. Descendant material inherits that context, with explicit local refinements. Conflicting constraints remain visible for resolution.

Main functions

Story Space

Browse the fictional universe through its source material, symbols, and relationships. A searchable network opens the supporting passages and recorded connections. Multiple sourced versions can coexist. Later, the app can suggest promising paths or unexplored connections as starting points for new compositions.

Registry

Import books and scan them for meaningful symbols. Proposed entries, relationships, and merges go through human review. Approved entries retain their source passages, descriptions, connections, and usage rules. Audio, images, and other files can be attached as references. Review decisions persist.

Builder

Compose frames within blocks, arrange blocks within capsules, and sequence capsules into a cassette. Support nesting and occasional branches through a zoomable flow. Selecting an element opens its composition and instructions; relevant registry material appears contextually. Direct text entry supports guidance and exact inclusions.

Mixing

The head capsule holds mix settings: desired treatments, constraints, and allowable renderer choices. These can include tone, emphasis, viewpoint, permitted invention, language, medium, style, format, and genre.

Renderers apply those settings through their own capabilities and may offer further adjustments within the cassette’s constraints. A revised mix can produce another realization while preserving the composition and earlier results.

Preview

Inspect the assembled cassette before rendering. Preview is a focused, read-only document over a dimmed or blurred background, with collapsible navigation and a compact flow overview. It shows the package and effective instructions being sent to the renderer. Registry details open when selected.

Rendering and results

Run the cassette through different renderers and retain the resulting versions. Read text, play narration and video, and open images large with arrow-key navigation. Compare alternatives, approve or reject results, revise mixes, and export selected outputs.

Playback and distribution

The distributed object is the cassette. A network, channel, distributor, or other recipient can purchase or license it and produce its own realization for an audience or subscribers [or for personal use]. The underlying composition persists across those versions.

Playback is the experience-facing operation. It can present an existing render or generate a realization as it proceeds. A playback environment interprets the cassette’s authored arrangement, symbol references, allowed usages, and mix settings.

An interactive fiction experience could let audience choices influence the realization within permitted boundaries. A device could realize a cassette locally, or present a version produced elsewhere. These are possible applications of the same package and rendering model.

Manifest and review

Each rendering includes a manifest describing the basis of its content decisions and additions made by the renderer. Required human-authored wording can be pinned to persist verbatim in applicable outputs.

A separate review checks the realization against the cassette and flags omissions, undeclared additions, instruction drift, or unexpected symbol usages. Useful new usages can be approved and added to the registry. Uncertain findings remain available for human judgment.

The output can travel with a generated bill of materials, or GBOM, containing its input references, manifest, and review record.

Curation and reuse

Retain approvals, rejections, edits, and review decisions. Selected finished work can be scanned back into the registry, with new material proposed for approval. Over time, this record can support better suggestions and an experimental encoding of the author’s preferences.

Shared behavior

Work and decisions survive closing the app. Editing and browsing do not require model calls. Generation is an explicit action. Earlier compositions, mixes, and outputs remain available, and cassettes can be exported for use in other rendering or playback environments.

The main views are Story Space, Registry, Builder, Cassette, focused Preview, and Render Results. Mixing belongs within the Builder and cassette configuration. The visual style remains open.

First complete version

The first version supports importing source books, reviewing registry entries, composing and sequencing capsules and blocks, packaging and previewing cassettes, rendering text, reviewing results, and saving or exporting the work.

Images, narration, and video extend the same structure. Distributor playback, interactive experiences, suggested paths, taste encoding, and Content Credentials integration can develop from that foundation.

---

I’ll continue this in a separate post or this is going to get too long to parse all at once…

I’ll expand on this another time, but wanted to jot down this idea that with the lorecore books, I am not possessive about them from an “authorial sense.” Did I “write” them? Some yes, very much, some less. But there are myriad choices, branches, possibilities, taken or untaken. Much of it is merely the result and record of what is explored, discovered, provoked, or simply noticed. I think of myself more than anything as being the First Reader of one of these new works. And then I apply my own sort of human-intelligence filtering workflows against it until it matches the criteria of quality that I am looking for at any given moment (which fluctuates with time and further experimentation).

Okay, so I’ve topped up my AI subscriptions for the month, and got Muse to shoot out a kind of coherent statement about what happens after the SYMBOL SCAN skill explained earlier, in relation to my AI Lorecore books.

Basically, what happens is that once books are converted and scanned, the process pulls out working narrative units, “symbols,” which taken together with their metadata form a “registry” which Muse explains adequately in the passage below:

The registry is a catalog of everything that matters across the books. Its basic unit is the symbol: a person, place, object, group, or idea worth tracking. Each entry holds the symbol’s name, the passages where it shows up, and the other symbols it connects to, all backed by quotes from the text. It can be read in both directions — look up what the copper bit is, or look up which symbols appear in book 12.

It gets built by a process called the symbol scan. Each book is converted from its EPUB into plain text, which is faster to search and lets every finding point back to an exact passage. The scan reads through and proposes candidates: a name, where it appears, a quote showing it in context. Nothing enters on its own. Every candidate lands on an approval sheet — a simple checklist — where each one is looked at and either approved or skipped. Approved symbols become entries.

The links between symbols go through the same review. When two symbols keep appearing together, the scan proposes a connection; when two names turn out to be the same thing, it proposes a merge. Each proposal is either promoted or skipped, and the decision is written down permanently, so the system keeps a record of what has been decided. When later books are scanned, sightings of known symbols are added to their existing entries, and only genuinely new material goes through review.

Once the registry exists, it can be sliced — a subset of entries pulled out for a particular job — and entries can be linked together in new ways. The catalog is the raw material; a slice is the working set.

We’ll get into later how registry slices can be used, and talk about the mechanics of using and re-using symbol registry entries…