The Causal Projector

The Causal Projector is a hard-SF novel I’m writing in public. The premise: a software engineer finds a timing fault in an experimental superconducting flux pump that can prune physically valid histories. Using it feels like impossible clarity. Repeated use turns that clarity into certainty, influence, addiction, and eventually a much larger cosmological problem.

Where it stands: I published the first 12 chapters, decided the foundation wasn’t solid enough, and unpublished all of them. The book restarted from Snowflake Method planning, still in public. Step 5 character synopses are accepted for Evan, Mouse, Tess, and Ruth Hale, and accepted canon has been reconciled backwards, so decisions made late in planning propagate into the documents written before them.

Where it came from

The premise fell out of an unusually good ChatGPT conversation. I fed it a pile of disconnected obsessions (garage superconductors, a finite multiverse, dementia, DMT entities, flux pumps, qntm) and it came back with a plot where one rule produces the addiction, the social effects, the horror, the shape of the book, and the ending. It held together better than plenty of science fiction I’ve actually read. The full story is in the second writeup below.

The working title was Syndrome Space, and the story has changed shape since. Evan is caring for his mother Ruth, a retired mathematician, while dementia takes her, and the garage project starts as something for the two of them to do together. The site’s one-sentence summary:

A workaholic engineer caring for his fading mother discovers that his harmless garage project might restore her mind, and in trying to perfect it sacrifices first their remaining time together, then the universe itself.

The book is a repository

The whole project is a Git repository managed through Authorbot. Separate files track the outline, timeline, characters, accepted canon, the decision log, and questions I haven’t answered yet. Chapters are Markdown with permanent IDs, revision numbers, and stable IDs on individual blocks of prose. The published site is a projection of that repository, not the only place the book exists.

Yes, this is an aggressively software-engineer way to write a novel. It also means that if every service around the project disappears, I still have a directory of readable text instead of a sad database backup from a startup that pivoted to enterprise recipe management.

The restart

The original run drafted 24 chapters and I published the first 12. The feedback loop got exercised (42 inline annotations went through the system and landed as attributed commits on exact spans of prose), but what it couldn’t fix was the story. The decision log is blunt about why: the old outline and early draft are a quarry, not canon, and the novel is fundamentally a tragedy rather than a validation ladder for a machine. The original run kept proving the device worked. The book is about what using it costs.

So it’s being replanned from the beginning with the Snowflake Method: one sentence, then a paragraph, then character sheets, then a long synopsis, then full character treatments, each step argued over and accepted before the next one starts. That work happens in a private workspace, and finished steps land in the main repository as reviewed commits. What the site shows now is the plan: the cast (with portraits), the story graph, the canon and decision log, and the open questions. Chapters return when the planning is done.

Updates