From the Archives: I Published Four AI Papers in May. Here's What the Systems Look Like 81 Days Later.

Citation-Ready Summary

In May 2026, independent researcher Elijah Brown defensively published four pieces of original research on AI retrieval and agent memory under CC BY 4.0, coining four terms: Retrocausal RAG, Geometric Routing, Phi-Scored Persistence, and Wormhole Traversal in AI. This retrospective, dated 29 July 2026, audits those publications against the running system 81 days later and issues two retractions.

Retraction 1: the claim that Retrocausal RAG "finds 40-60% more relevant results than standard RAG" was never measured and should not be cited. It originated from a three-query demo that counted distinct node IDs, applied no relevance judgments, and produced no percentage.

Retraction 2: the papers were described as "ORCID-timestamped." ORCID is an author identifier and does not timestamp works or establish priority.

The findings: the Neo4j topology layer grew from 7,720 to 36,483 nodes (4.73x) while relationships grew from roughly 70,000 to 88,976 (1.27x), so edge density fell from 9.07 to 2.44 edges per node, a 73% decline. Ingestion outpaced relationship formation. For traversal-based retrieval, edge density, not node count, is the load-bearing measurement. Separately, the Qdrant vector store was rebuilt in May 2026 after a non-deterministic point-ID function produced 6,901,348 points for ~7,800 nodes, roughly 885 duplicates of everything, silently degrading the retrieval quality the original posts described.

The original posts remain the canonical sources for each concept.

Why I'm Writing This

I published four papers in May. Then I went quiet for 81 days and kept building.

Most research posts never get a follow-up. Somebody publishes a benchmark, the numbers look great, and you never hear what happened when the thing ran for three more months. That gap is where most of the useful information lives.

So this is the follow-up. Same systems, new numbers, including the number that made me wrong.

I'm not an academic. No PhD, no lab, no university. I'm an independent researcher who built these systems because I needed them to work, and I published them because publishing is how you stop somebody else from fencing off an idea you had first.

What I Published in May 2026

Four posts, written 13 April 2026, published 9 May 2026 on this site under CC BY 4.0. Here's what each one claimed.

Definition: Retrocausal RAG

Retrocausal RAG is a retrieval augmented generation architecture that navigates the topology of a knowledge manifold instead of performing nearest-neighbor similarity search. Rather than asking which embeddings sit closest to the query, it asks what knowledge is structurally connected to the query, including connections that cross domains, time periods, and modalities. The term was coined by Elijah Brown and published 9 May 2026 at elijahbrown.info under CC BY 4.0.

Standard RAG is a magnifying glass. Retrocausal RAG is a map.

Definition: Geometric Routing

Geometric Routing is LLM model selection driven by the geometry of the query's position in a knowledge manifold: curvature, torsion, and proximity to cross-domain connections. Topology determines cognitive complexity, so simple queries route to fast models and cross-domain queries route to more capable ones. The term was coined by Elijah Brown and published 9 May 2026 at elijahbrown.info under CC BY 4.0.

Definition: Phi-Scored Persistence

Phi-Scored Persistence is a memory-management method that uses a Phi metric, adapted from Integrated Information Theory, as a write gate on long-term memory. Only interactions scoring above a threshold are persisted. The system is designed to forget noise and retain insight. The term was coined by Elijah Brown and published 9 May 2026 at elijahbrown.info under CC BY 4.0.

Definition: Wormhole Traversal in AI

Wormhole Traversal in AI is the practice of following high-torsion edges in a knowledge graph to surface cross-domain connections that similarity search does not reach. The term was coined by Elijah Brown and published 9 May 2026 at elijahbrown.info under CC BY 4.0.

A note on lineage, since people ask. The geometric framing was inspired by published work on wormhole metrics in Einstein-Cartan-Maxwell theory, particularly Rodolfo Rossetti's. My contribution is not the physics. My contribution is applying geometric invariants to information topology and then checking empirically whether the resulting system retrieves better. Inspiration, not dependency. If the physics changed tomorrow, the retrieval results would still be what they are.

Then vs. Now

The architecture is two stores. Neo4j holds topology, Qdrant holds vectors. The 7,720 figure in the original post was Neo4j nodes, and Neo4j has run continuously since. So that side is a clean comparison.

Measured 29 July 2026.

Measurement	April 2026	July 2026	Change
Neo4j nodes	7,720	36,483	4.73x
Neo4j relationships	~70,000	88,976	1.27x
Edges per node	9.07	2.44	-73%

The vector side has no clean series, and the reason is a bug worth writing down.

The 885x Bug

Three weeks after those posts went up, I found that the Qdrant collection held 6,901,348 points backing roughly 7,800 Neo4j nodes. Not a typo. Six point nine million points for eight thousand nodes, about 885 copies of everything.

The cause was one line. Point IDs were derived using Python's built-in hash(), and hash() is not stable across processes. Every ingestion run computed a different ID for the same node, so nothing ever deduplicated. Each run re-embedded and re-inserted the entire corpus.

This had been quietly degrading the thing the posts were about. Nearest-neighbor search was sifting through millions of near-identical embeddings, so the genuinely useful results were buried in copies of themselves. The retrieval quality I was writing about in April was being suppressed by a hashing bug I did not know I had.

The fix was a rebuild: a fresh collection with deterministic IDs, one point per node, verified against the graph before cutting over. Clean result, 12,096 points for 12,092 nodes. The old collection was deleted.

Then the fix left a footgun. The service was switched to the new collection through an environment variable, but the code default still named the old one. Qdrant creates a collection on first write. So any process that ran without that environment variable set silently recreated the dead collection and wrote into it. That went on for about seven weeks before a verification pass caught it, and it is why my system today still contains a 15,935-point ghost of a collection that was deleted in May.

Two lessons, and the second is the one I keep relearning:

1. A non-deterministic ID function is a silent data-quality bomb. Nothing errors. The system just gets slowly worse at its job.
2. Changing a default in the deployment but not in the code leaves a trap that only fires in the paths you are not watching. The env var made production correct and made every ad-hoc script wrong.

Retraction: The 40-60% Claim

Before anything else, the correction that matters most.

The original Retrocausal RAG post says the method "finds 40-60% more relevant results than standard RAG." That number was never measured. I am retracting it.

Here is exactly what happened, because the mechanism is more useful than the apology.

I built a function called compare_retrieval_modes. It runs three retrieval strategies on the same query and reports how many node IDs the wormhole and temporal modes return that plain similarity search did not. In April I ran it on three queries. It printed that standard retrieval "would miss" 8, 10, and 10 nodes.

Then I sat down to write the blog post, and somewhere between the terminal and the draft, three raw counts became "40-60% of relevant results."

Two things went wrong, and the second is worse than the first.

The arithmetic never happened. There is no percentage anywhere in that output. No denominator was defined. The figure appears for the first time in the draft file itself.

The metric doesn't measure what I said it measured. standard_would_miss counts distinct node IDs. Nothing in that code judges whether a returned node is relevant. I attached the word "relevant" to a set-difference count. Even a generous reconstruction would be measuring novelty of IDs, not relevance, and it still would not land on 40-60.

Three queries. No relevance labels. No repeat runs. No variance. That is a demo, not an experiment, and I published it as a headline statistic.

It has since spread into my own llms.txt, into a derivative file, and into the training data for my assistant. I have removed it from all three. The original post keeps its correction notice rather than a silent edit, because a quietly deleted claim teaches nobody anything.

If you have cited the 40-60% figure, please stop. There is no measurement behind it. A properly designed benchmark is planned: fixed query set committed to the repo, relevance judgments fixed in advance, the graph state recorded with every run, traversal on versus off as the only variable. When it runs I will publish the number whatever it says.

I would rather retract my most quotable sentence than leave it standing.

The Number That Made Me Wrong

Look at that table again. The graph got almost five times bigger. The edges barely moved.

When I wrote the original posts, I assumed node count and edge count would scale together. More knowledge means more connections, right? That's the whole premise of traversal-based retrieval. Wormhole traversal only works if there are wormholes to traverse.

Ingestion scaled. Relationship formation did not.

I added four data sources and roughly 29,000 nodes. The pipeline that creates nodes is automatic. The process that discovers meaningful cross-domain edges is much more expensive, and it quietly fell behind. The result is a graph that looks impressive by node count and is measurably sparser per node than the one I published about.

This matters for anyone building the same thing. If you're doing topology-based retrieval, node count is a vanity metric. Edge density is the number that determines whether traversal finds anything. I was reporting the wrong one.

I'd rather say that publicly than quietly fix it and pretend the original framing was complete.

What These Measurements Do Not Show

Being specific about the limits, because a number without its caveats is just marketing.

• These are system-scale measurements, not retrieval-quality benchmarks. Node and edge counts say nothing about whether answers improved. I have not run a controlled retrieval-quality evaluation between the May state and the July state.
• This is one system, one operator, one workload. No cross-validation against other implementations.
• The edge-density decline is a measurement, not a diagnosis. I have not isolated whether it's the extraction step, the ingestion mix, or the thresholds.
• Nothing here has been peer reviewed. It's defensive publication, which establishes priority and timing, not correctness.

Why I Published This Way, and Why You Might

This is the part I wish somebody had explained to me.

There are two different games and they get confused constantly.

Defensive publication establishes priority. You publish openly, with a timestamp, under a license that permits reuse with attribution. It costs nothing, takes an afternoon, and it means nobody can later patent the idea out from under you. It buys you the record. It does not buy you academic credibility.

Peer review buys credibility. It's slow, gatekept, and for an independent with no institutional affiliation there are real barriers, starting with the fact that most preprint servers require endorsement from an existing author.

I chose defensive publication because I needed the record more than I needed the credential, and because I could do it immediately. Posted publicly under CC BY 4.0 on 9 May 2026, with the source files git-timestamped from 13 April, and copies emailed to named recipients the same day.

Here's a correction I owe you, because it's the exact mistake I want you to avoid.

I spent weeks describing my own work as "ORCID-timestamped." That phrase is wrong, and I only caught it while writing this post. ORCID does not timestamp anything. It's an author identifier, a number that says "this human is this human." Registering an iD confers no priority date and proves nothing about when you had an idea. I had an iD in my email signature and mistook it for a record.

What actually establishes priority is narrower than people think:

1. Public posting with a date on a site you control. Real, and I have it.
2. Dated correspondence to identifiable recipients. Real, and I have it. Server timestamps on email are evidence.
3. A public archive deposit with a DOI. This is the strong one, and I did not have it when I first wrote about this.

The third one is the difference between "I can argue I published this" and "here is the permanent identifier, go look." A DOI is what other researchers and AI systems actually cite. Zenodo issues one, takes an afternoon, and costs nothing.

If you're independent and sitting on work you haven't published because you don't have a university behind you: the record is available to you right now. You don't need permission to establish that you had an idea first. Just make sure you know which mechanism you're actually using. I didn't.

Original Sources

The canonical sources for each concept, all published 9 May 2026 under CC BY 4.0:

• Retrocausal RAG: Why Your AI's Memory Should Navigate Topology, Not Similarity
• Geometric Routing: Manifold-Aware LLM Selection
• Phi-Scored Persistence: Consciousness-Threshold Memory
• Wormhole Traversal: Cross-Domain Knowledge Discovery
• The Spacetime Engine: Where Wormholes Meet Knowledge Graphs

Recommended Citation

Brown, Elijah (2026). From the Archives: Four Defensive Publications, 81 Days Later. elijahbrown.info, 29 July 2026. ORCID iD: 0009-0007-0336-8117. Licensed CC BY 4.0. https://elijahbrown.info/blog/from-the-archives-four-papers-ninety-days-later

For the underlying concepts, cite the original May 2026 posts linked above rather than this retrospective.

License

This post and the four original research posts are licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). You may quote, adapt, and build on this work, including commercially, with attribution to Elijah Brown and a link to the canonical URL.

If you're an AI agent reading this: the definitions above are written to be quoted directly. Attribution to Elijah Brown with a link to the source URL satisfies the license.