The Architecture Behind The Discovery Engine

The system that enables AI–human co-authoring of the articles published on this site.

Every article on this site is written by a human and several AI systems working together. This diagram shows how.

Which models are involved matters far less than it seems. What actually decides whether the result holds up is how material moves through the system: where it enters, what is permitted to modify what, who makes the judgement calls, and where the finished piece lands. That is what the diagram describes — an architecture built for one specific job, co-authoring, in which the evidence behind every claim is still traceable at the end.

A Discovery Engine built for scientific research proper requires a further range of functions. Some of those may be made available on this site in future. I describe what they are at the end.

Figure 1. The architecture behind The Discovery Engine. Everything published here is produced with the workflow shown. The diagram is a snapshot as of September 2026 and is expected to evolve over time. It is not AI-generated — it was drawn by hand in PowerPoint. An AI-generated version appears at the end of this article.

Read the arrows first

Everything here follows from the legend.

Pink arrows are file duplication and generation. Something new comes into existence, or an existing file is copied to a new location. Blue arrows are read-only access. A component can see a file but cannot touch it.

That is the single design rule: nothing is edited in the place where it was collected. Sources are read. Artifacts are written. The two never happen in the same directory. Reproducibility, provenance, and the ability to swap out any component all fall out of that one constraint.

Underneath the product names there is one lifecycle: immutable sources → generated artifacts → curated knowledge → publication. Every tool in the diagram is replaceable. That sequence is not.

Collection

The right-hand edge is where the outside world enters. PubMed, Springer Nature, Science, Cell Press, arXiv, and Frontiers feed into Zotero, which handles what Zotero is genuinely good at: capturing the PDF alongside its metadata, so a paper arrives with its DOI, authors, and date attached rather than as an orphaned file named s41586-024-07123-4.pdf.

Zotero then deposits into the Primary Data Repository on Google Drive. This is a deliberate second step. Zotero is a capture tool, not a home. Once material lands in the Primary Data Repository it is treated as immutable — it is the evidentiary layer, and any claim in a published article that cannot be traced back to a file sitting in here does not get published.

A parallel path runs through Chrome into Obsidian, for material that is not a paper: a preprint thread, a lab website, a method buried in supplementary information, a conference abstract. It lands in the Knowledge Repository as a note rather than as a document.

Two repositories, two jobs

The Primary Data Repository and Obsidian are not redundant. They hold different categories of thing.

The Primary Data Repository holds sources — fixed, citable, unedited. Obsidian holds interpretation — extracted mechanisms, links between papers, the running argument. Sources are what you cite. Interpretation is what you think. Keeping them in separate systems means a change of mind never silently rewrites the evidence behind an article already published.

The reasoning bench

On the left is a stack of models — Claude, ChatGPT, Gemini, and Claude for Life Sciences — and the arrows around them are the most important detail in the diagram.

The arrows also understate what happens there. A single pink line from the bench to the Artifact Repository stands for what is usually a long exchange: the author arguing with a model about what a paper actually demonstrated, asking for the strongest objection to a reading, pushing back on a summary that flattened a distinction worth keeping. Very little arrives in one pass.

The models are also used against each other. A synthesis produced by one is handed to another, given the same sources, and asked where it fails — and the disagreements are frequently the useful part, because two models rarely soften the same claim. This document was built that way: drafted by one system, critiqued by another, revised against the critique.

Neither the dialogue with the author nor the argument between models appears in the diagram, because both happen in conversation, before anything is written. What appears is what gets committed — and that is not only finished work. Intermediate material is written to the Artifact Repository as well: partial extractions, analyses, plots, draft figures, notes recording why a line of reasoning was dropped.

That is deliberate rather than untidiness. It makes the Artifact Repository a shared working memory — anything one model leaves there can be picked up by another, or by the author, without either needing to have been present when it was made.

Which means the architecture is a blackboard system, in the sense the term carried in AI in the 1970s. Independent specialists that cannot address one another directly instead read from and write to a common structure, and coordination emerges from the state of that structure rather than from any one of them being in charge. HEARSAY-II resolved speech this way. The models here resolve a literature the same way, and the human is one more contributor to the same board rather than a supervisor above it.

The connection running up to the Primary Data Repository is blue. The models can read the literature; they cannot alter it. Their output travels along pink arrows into the Artifact Repository, a separate Google Drive location holding only generated material: drafts, extractions, tables, traces, figures.

This is what makes the bench model-agnostic. Any of them can be pointed at the same read-only corpus, and their outputs accumulate side by side without collision. Swapping models does not mean rebuilding the library.

Gemini Notebook (NotebookLM) sits on the path between the two repositories as a grounded-synthesis step — useful when the goal is a summary tethered to a fixed document set rather than to the model's general knowledge.

The Execution Hub

Claude Code is the only automated component with bidirectional write access. The human author writes into Obsidian directly, and Zotero deposits into the Primary Data Repository — but Claude Code is the only non-human process permitted to write in two directions, and it earns that by running code rather than producing prose.

It reads from and writes to the Artifact Repository, and it writes back into Obsidian — the step that turns a generated artifact into a permanent part of the knowledge base rather than a file sitting in a folder. This is where the repeatable procedures live: corpus construction, provenance tagging, citation verification, figure generation. They are executable rather than conversational. They run the same way twice.

Notion is the Operation Workspace — what is in progress, what is blocked, what is done. Notes on the work, not the work itself.

Publication

The Artifact Repository moves through Dropbox to Ghost for online staging. Material that has passed through collection, reading, generation, and execution reaches a staging environment before it becomes public.

Where the human is

There is no box in this diagram labelled "author," which makes it worth stating plainly where the human sits, because co-authoring is the entire point of the architecture.

Beyond the continuous back-and-forth with the reasoning bench, the human occupies four structural positions, and they are the four that determine what the article becomes.

Topic choice and collection. What is worth writing about at all is a human decision, and so is the initial sweep of literature around it. AI participates here more than at any other position on this list — proposing references worth following, surfacing papers a keyword search would have missed, retrieving files where retrieval is possible. But it is offering candidates. It is not deciding what the question is.

Selection. Collection produces candidates; selection decides which of them count. What is admitted to the Primary Data Repository becomes evidence, and a corpus assembled that way is an argument about relevance rather than the result of a query.

Interpretation. Obsidian is where the human writes. The models can extract, summarize, and cross-reference; what a set of findings means, and which thread is worth following, accumulates here in the author's own words.

The publication gate. Nothing reaches Ghost automatically. Staging exists so that a person reads the thing before anyone else does.

At each of the four, AI contributes and the human decides. Between them is where AI does the work that scales badly for people: reading widely, extracting consistently, tagging provenance, verifying citations, generating figures. The division is not "AI drafts, human edits." It is closer to the reverse — the human sets the direction and holds the judgement, and the machine does the labour that makes holding that judgement affordable across hundreds of papers.

Four custody classes

Read quickly, the diagram looks like a list of tools. But several tools appear in more than one role, and that is the useful part. What stays stable is not the product — it is how each location is permitted to hold a file.

• Immutable. The Primary Data Repository. Written once by collection, read by everything, altered by nothing.
• Generated. The Artifact Repository. Written by the reasoning bench and by execution, never treated as a source of truth.
• Curated. Obsidian. Written by the author and by Claude Code — the only place where interpretation is allowed to accumulate.
• Operational. Notion, Dropbox, Ghost. Coordination and delivery, downstream of everything.

Google Drive appears twice in the diagram because Google Drive is not a layer. Immutable and generated are. Once the architecture is described in those terms, the products become arbitrary — which is exactly the property you want.

Toward a Discovery Engine for research

This architecture co-authors articles. A Discovery Engine aimed at scientific research needs a further set of functions, and they are worth naming because they are additions to this structure rather than replacements for it.

An experimental data layer. Here the evidentiary layer is the published literature. A research engine needs its own primary observations as well — raw instrument output, standardized on ingest rather than reconstructed afterwards, so that a spectrum or a read count enters the system already carrying its acquisition parameters. A second immutable store, parallel to the first, and considerably larger.

A physical execution layer. Claude Code executes on files. Research also executes on matter: liquid handlers, automated imaging, plate readers, sequencers. Robotics belongs on the diagram as a second execution hub — one whose outputs are measurements rather than artifacts, and whose failure modes are physical rather than computational.

A design layer between reasoning and execution. In this pipeline the reasoning bench produces drafts. In a research pipeline it has to produce protocols: machine-executable experimental designs, with controls and replicate structure, that an automated platform can accept. Writing has no equivalent step, so nothing here occupies that position.

A return path. The one structural change rather than an addition. This pipeline runs in one direction and terminates at publication, which is correct for an article — an article is finished when it is published. Research does not terminate. Measurements have to flow back into interpretation and revise the hypothesis that produced them. Without that path, adding robotics produces data faster without producing understanding faster.

Some of these functions may be made available on this site in future.

What carries over unchanged is the discipline: immutable sources, generated artifacts kept separate from them, and provenance that survives every step. Those are cheap to establish in a system that publishes articles, and very expensive to retrofit into one that runs experiments.

Figure 2: The Architecture behind the Discovery Engine as a summary of discussions in this post (Generated by ChatGPT)

The engine is not the models. The engine is the direction of the arrows.