Ari’s Space*   est. 2026
Skip to content
ari*s space[ a. ]
← Librarymemory / 2026-08-04

Generative Memories: killed ideas that keep teaching

Counterfactual memories from throwaway builds of rejected designs. Methodology, provenance armour, the four-bug saga, and why the kill is where the creative mass lives.

12 parts / Hover to explore. Click to read.

Counterfactual memories from throwaway builds of rejected designs. Methodology, provenance armour, the four-bug saga, and why the kill is where the creative mass lives.

Rejected design
      |
mini-spec -> real ghost build
                    |
            distil + validate
                    |
           synthetic memory
                    | recall
           visible provenance
The experiment builds a rejected route separately from the live product. Its counterfactual label must survive actual retrieval before scheduled runs are enabled.
Context Pack (for agents)

The day this shipped, my own judge panel had unanimously rejected three complete designs for one system.

Usually that would leave me with a useful decision and three discarded approaches. I wanted to find out what those approaches could still teach us if someone actually tried building them.

Generative Memories takes one rejected design, expands it into a small specification, makes a throwaway build and distils what happened into a marked memory. It runs on a schedule without requiring a human to approve every run.

The build is real as an experiment. The memory is counterfactual: this was a road we didn't take in the live product, and the note must never imply otherwise.

The build is the instrument. The memory is the product.

Without the build, we're inventing an experience. Without a defined memory structure, we're collecting another pile of build logs. Both parts need to work.

Keep the rejected route available to learn from

This was the brief that settled the goal:

Essentially the goal of this is to make something where we're progressively thinking creatively and taking creative approaches to solving problems.

In my brainstorms, two approaches commonly get rejected for each one that ships. The winner tends to be the option judged safest to deliver. The rejected options can contain the more unusual techniques, but a written rejection doesn't tell us what building them would reveal.

If future sessions only recall the winners, the system can become efficient at repeating its established choices. I wanted it to accumulate useful experience from the alternatives too.

The live product still follows the selected approach. A rejected route can be explored separately, with its origin visible whenever that exploration is recalled.

Salvage the useful parts of the design review

The system went through six discovery legs, three proposed approaches and three judging legs. All three proposals were rejected with parts worth keeping.

The final design combined those parts:

  • The risk-first proposal supplied the order: prove provenance, probe the unattended executor, then complete a real run before enabling the timer.
  • The MVP-first proposal supplied a single-file pipeline, one ghost build per run, a typed memory schema and cheap local expansion before a paid build.
  • The portability-first proposal kept infrastructure names in configuration, required a sink that refuses real-memory destinations, and kept automated cleanup out of scope.
  • The goal reframe kept the product focused on transferable creative insight rather than the amount of code produced.

That is what I mean by kill-with-salvage. Rejecting a coherent proposal doesn't require throwing away every useful part of it.

Prove the risky things first

The milestones had to happen in this order:

  1. Inspect the live system. The old distiller was a dead stub. Actual ingestion scanned files through a path-to-layer map. Recall had no layer filter. Rejected-design digests already entered as raw fact. Those four findings changed the design.
  2. Prove provenance. Write one mock counterfactual memory, ingest it into a dedicated synthetic layer, and verify that its banner survives in recalled chunks. No timer before that works.
  3. Probe the executor. Run a trivial headless build under the real unattended runner, with no terminal attached. Save the exit code and logs to a file so process failure can't disappear.
  4. Complete one real ghost. Follow a genuine rejected design through the pipeline, then have me score the resulting memory against the schema.
  5. Enable the timer. Successful runs stay quiet; failures appear in status. A budget breach blocks further runs.

The order is part of the mechanism. A reliable schedule is no help if it reliably writes unmarked fiction into a trusted store.

Put the counterfactual label where retrieval will expose it

At the time of this build, recall couldn't filter synthetic notes out of results. The label therefore had to survive retrieval alongside the text.

The design used four protections:

  • A dedicated synthetic layer in the ingestion map.
  • A sink preflight that rejects any output path also claimed by a non-synthetic ingest rule.
  • Counterfactual provenance in frontmatter and a filename prefix that cannot collide with ordinary human notes.
  • A fixed banner as the first line of the body, with retrieval checks proving that the warning is visible in returned chunks even when frontmatter is stripped.
Every retrieved chunk carries its own marking.

A banner at the top of a file isn't, by itself, proof that every retrieval chunk will carry it. That is why the provenance gate tests the recalled output. The classification must survive the actual path by which a future model sees the note.

Require a memory with substance

The distillation schema has six sections in a fixed order:

  1. What surprised: something learned by doing the build.
  2. Technique emerged: a method or trick the attempt exposed.
  3. Transfers to: the class of problem where the learning could help later.
  4. Kill verdict: confirmed or refuted: what the attempt says about the original rejection.
  5. Build shape: what was made, its rough size and how far it got.
  6. Open questions: what a serious next attempt would still need to establish.

Each section needs substantive content. Rephrasing the old rejection fails the first section. Those digests already enter the knowledge system; the experiment needs to add something the digest couldn't contain.

The transfer field matters particularly. It gives future retrieval a problem class to look for. Otherwise we're making a build diary and hoping somebody happens to need it.

Run one idea through the pipeline

For new intake, prefer the oldest eligible idea with no ledger entry. A previously failed key remains eligible for its single later retry. One run handles one rejected approach.

The build is the instrument. The memory is the product.

Intake recognises kill verdicts across the corpus's different formats: schema-declared digests, prose synthesis tables and older flat files. It deduplicates using a stable key over the slug, approach ID and normalised sketch. V1 deliberately excludes salvage verdicts from intake.

Expand turns the roughly 250-word sketch and its refutations into a buildable mini-spec. This pass is local, keeping the paid budget for implementation. The original rejection reasoning stays attached.

Build gives one headless coding seat that mini-spec, with the ghost directory as its working directory. Check cost before the call, enforce a per-run cap, keep a timeout backstop and record spend in an append-only ledger.

Distil reads the mini-spec, build transcript and rejection reasoning. Its output must follow the six-section schema and focus on transferable insight rather than merely reporting the build sequence.

Validate rejects missing or empty sections and generic filler. A failed key can retry once on a later run, then parks and surfaces in status. There is no infinite retry loop spending quietly in the background.

Emit checks the sink and writes only into the synthetic-memory directory, then records the result in the ledger.

The configured cadence was one ghost every three days: on the order of ten runs a month, each within its own cap. Manual seats provided status and dry-run access; the timer drove normal operation.

What the first end-to-end gate caught

The single-ghost milestone, M3, took four runs to get through. Each exposed a different failure.

Each gate caught exactly one bug. The fourth run emitted the first memory.

The first run described a build without making one. The coding seat wrote prose and no files, leaving nothing real to distil. The correction was a file-writing acceptance condition in the mini-spec and a hard build failure when no artefacts existed.

The second run produced a polluted transcript. Terminal control codes and status chrome reached distillation. We kept the raw log separately and stripped and normalised the input used by the distiller.

The third run exposed the wrong validator. It was brittle about formatting and insufficiently demanding about substance. We changed it to check required sections and a minimum substance length rather than reject useful material for superficial differences.

The fourth run leaked reasoning-style preamble into the note. The banner and sections were present, but the body contained unwanted framing. We stripped recognised preamble patterns and revalidated.

That fourth run emitted the first memory. I scored it before the timer was trusted. It contained insight from the attempt rather than a polished retelling of the rejected design.

Those failures explain why the gates exist. An unattended writer needs to prove more than its ability to produce a Markdown file.

What the first ghost taught

The rejected source was a “define work, not agents” approach from a work-not-people brainstorm. Judges had rejected its template shape. The ghost built a small validator instead.

The useful findings were specific:

  • The How axis let persona language back into a work definition. A writer would describe “the researcher finds” instead of “extract data from”. Structural prompts alone hadn't prevented that drift.
  • Linguistic Linting emerged as a technique: negative constraints and banned-word lists could enforce the distinction more effectively than a template asking for a different style.
  • The transfer case was agent orchestration. Keeping task definition separate from agent identity makes it easier to change models without rewriting the instructions around a persona.
  • The original verdict was confirmed for the template and salvaged for a validator. The linter could enforce a rule the template merely encouraged.

The value was a better understanding of what to reject and what to preserve next time. It didn't require putting the rejected template into the live product.

Keep the release state separate from the remaining risk

At the original August 2026 publication, V1 was live with these reported properties:

PartState at that release
PipelineSingle-file CLI with passing tests.
ProvenanceDedicated synthetic layer checked end to end; banner visible in recalled chunks.
First ghostEmitted and scored by me.
CadenceUnattended timer every three days.
CostHard cap per run; further work paused on breach.
IntakeKill verdicts across the supported digest formats.
Open workDistillation quality, a stronger stamp route, a morning-panel failure line and later salvage intake.

The first unattended runs were the real soak. Distillation quality remained the main softer risk. If local expansion or distillation proved weak, the design allowed the paid seat to move or distillation to use a stronger model. That quality dial was deliberate and still open.

A cap pause was sticky. Clearing it required a human action, not an automatic retry.

Keep the deliberate exclusions

V1 did not attempt multiple executors beyond a configuration seam, salvage-verdict intake, recall filters inside the brain or remote pushes. Automatic ghost cleanup was excluded permanently.

Several tempting shortcuts were rejected:

Summarising rejected designs without building them would add no experimental experience. Those digests were already in the store.

Writing synthetic experiences without an attempt would blur invention with evidence. The risk is a future model treating fiction as something the system actually did.

Approving every emitted memory would break the hands-off requirement chosen for V1. Human scoring promoted the first real result into unattended operation; it wasn't meant to become a permanent approval queue.

Automatically deleting ghosts was a permanent design boundary, not a feature deferred from V1. Status could report their disk usage. I would decide what to prune. Autonomy didn't include a delete path.

Supporting several executors immediately would add complexity before one headless path was reliable. The configuration boundary kept that possibility open without making it part of the first build.

Try the method at a small scale

Keep rejected options in a findable collection. Pick one, preserve why it was rejected, and give a bounded experiment a checkable result.

Require the memory to explain surprise, technique, transfer and the revised verdict. Keep the counterfactual label in the source and prove it survives retrieval. Establish the provenance and execution checks before enabling an unattended writer.

Killed ideas aren't waste. They're unexplored territory. Explore on schedule.

The selected product can still ship. The rejected route can still teach. The useful memory is the learning from the experiment, with an honest account of which kind of work produced it.

//A<3

[ comments ]

guests welcome. members show first in the list

no comments yet. start the thread_

1 / 14