Research with Nexus

Claude already reads and answers well from a store of documents. What Nexus adds is the record and the checks. Everything a piece of research produces becomes a document in the store, linked to the paper and to the work before it. Every claim on the way is checked by a second reader with access to your code. Three things you can say show the shape.

Bring a paper in and see what it touches

Index <PATH-TO-THE-PDF> into the <SUBJECT> collection, with enrichment, and show me what it links to.

Claude extracts the text, cuts it into chunks, embeds them, registers the paper in the catalog, finds its DOI and authors, and links it to the similar documents already in the store. You see the catalog entry with its links. Lesson 2.

Ask a question that needs several papers

/conexus:query What do the <SUBJECT> papers say about <THE POINT>?

Claude runs a plan over the collection: search, read the passages, extract, and write one answer with a source for each claim. A saved plan is reused when one fits the question. Lesson 5.

Check a proposal against your own code

Have the critic read the proposals on <THE PAPER> with access to the code and the design records. For each one: survives, survives with amendment, or dies, with the artifact that decides it.

The critic agent opens the files you name and returns the issues it found, each with the evidence: a changelog line, a section of a design record, a function. Claude then writes the verdict per proposal. Proposals that rest on a false claim about your system die here, before anything is built. Lesson 7.

Claude, the store, memory, and the web keep doing what they do. The lessons below are what you say to get each document written, linked, and checked, and what you see when it is.

A paper in the store is a catalog entry with the paper's text in chunks, its DOI and authors, and links to the documents that are already similar to it. The entry is what every later step links to.

Index <PATH-TO-THE-PDF> into the <SUBJECT> collection, with bibliographic enrichment, and show me what it links to.

Claude runs nx index pdf with --enrich. The text extractor is chosen from the content, so a paper with many formulas goes to the formula-aware extractor. Enrichment looks the paper up by title and adds the DOI, the authors, the venue, and the citation count to the catalog entry. Then Claude shows the entry.

catalog show  1.12.119
  title:      RAG Deserves an Index: Why Ingest-Time Compilation Beats Query-Time Interpretation
  author:     Kyle Wild, Yusuke Takahashi, Asako Uraki      year: 2026
  collection: knowledge__dt-papers__voyage-context-3__v1    chunk_count: 52
  bib_doi:    10.48550/arxiv.2608.20845    bib_openalex_id: W7204148305
  bib_venue:  arXiv (Cornell University)   index_state: complete
  links_from:
    1.12.119 → 1.14.23  relates  by dt_similar
    1.12.119 → 1.14.4   relates  by dt_similar
    1.12.119 → 1.12.53  relates  by dt_similar

The three relates links were added at index time, to the papers already in the store that the paper most resembles. Open one of them and you are reading the neighbourhood before you have read the paper.

Collections are subjects

A paper is stored in a collection named for its subject, such as distributed-systems or semantic-operators, never for a project or a date. A later question is limited to one subject collection, and "what do the semantic-operator papers say about batching" works because those papers are in one place.

Watch the indexing

Read the index log while it runs. Tell me if any stage did not complete, if no aspects were extracted, or if the citation lookup returned nothing.

Indexing has several stages and each one writes to the log. A paper indexed with no aspects, or a lookup that returned nothing, is a fact about the pipeline and not about the paper, and it costs one minute to find now.

On macOS with DEVONthink, nx dt capture takes a URL or a DOI, stores the PDF in DEVONthink, and indexes it in one step. The catalog keeps the DEVONthink identity, so the same paper is never indexed twice.

Search results are not reading. A paper's chunks and a summary hide what kind of document it is. A six-page position paper whose protocol is in an unpublished second paper looks like a full study when you see only its chunks. Two agents at the same time, one inside the paper and one outside it, give you a reading you can build on.

Two agents on <THE PAPER>, at the same time. One reads the full text and reconstructs the paper: claims, method, numbers, and what the paper does not say. The other researches everything outside the paper: the authors, independent evaluations, earlier work, and the opinion of the field. Both write to memory.

Two agents start. The first reads the full text and writes a technical reconstruction: what is claimed, with what evidence, and what is missing. The second is the research agent, working outward. It marks every claim with a source or with "could not verify". Both write memory entries, and Claude shows you where they disagree.

memory_get  nexus / paper-rag-deserves-an-index-2608.20845-nexus-mapping
Thesis: ingest-time semantic compilation. Compile a corpus's meaning once at write time into
a substrate with two coupled layers, incrementally maintained embeddings plus atomic claims
with byte-exact quote provenance validated at compile time …
Numbers: compiled claims as retrieval payload won all 32 budget-by-model cells on 500 MediaSum
transcripts (85.2% correct at ~2.2k reader tokens vs 72.5% at ~16.3k for best chunking) …
Limitations the paper states: synthetic maintenance pilot; grader and extractor share a model;
the compiled-payload advantage did not survive a tool-using agent layer, which is exactly this
system's consumer shape. That last point is the one to test before deepening aspects …
Companion: arXiv:2608.16621 (maintenance study), Takahashi, Wild, Uraki.

The last two lines are what a summary does not give you. The paper's own stated limitation names the experiment to run before building anything, and the companion paper is where the protocol lives.

Read the full source before you use it

Everything built on a reading inherits the errors of that reading, so the reconstruction is written from the full text and not from the chunks. When a reading says "the protocol is in a second paper", that sentence changes what can be tested later, and no search result contains it.

A link is a typed connection between two catalog documents, and it works in both directions. A question about the design finds the code, and a question about the code finds the design. Most links are created for you at index time. The ones with the most meaning, from a paper to the module or the design record it concerns, are the ones you add.

Link <THE PAPER> to <THE MODULE THAT IMPLEMENTS ITS IDEA> with an "implements" link, and to <THE DESIGN RECORD IT CONCERNS> with "relates".

One link call on the catalog server per link, with the two documents and the type. Claude accepts titles, so you never need the addresses.

See what a paper is connected to

What links to <THE PAPER>, and what does it link to?

$ nx catalog links "RAG Deserves an Index: Why Ingest-Time Compilation Beats Query-Time Interpretation"
1.12.119 → 1.14.23    (relates)   by dt_similar
1.12.119 → 1.12.53    (relates)   by dt_similar
1.12.119 → 1.1.3642   (relates)   by user
1.12.119 → 1.1.838    (relates)   by user
1.11.529 → 1.12.119   (comments)  by user
1.11.530 → 1.12.119   (cites)     by auto-linker
1.11.532 → 1.12.119   (cites)     by auto-linker
1.11.533 → 1.12.119   (cites)     by auto-linker

Every link names who made it. The dt_similar rows came from indexing, the auto-linker rows were added when a document that cites the paper was stored, and the user rows are the ones added by hand. When the answer matters, ask for links by creator: "Only links made by hand."

Follow the links

A research result names documents, and each one is a place to continue. "Start from <THE PAPER>, follow cites links for two steps, and list what you reach" walks the graph with the traverse tool. A document-level query can do the same during a search with follow_links, so the results include documents reached through the graph. The query tool also ranks a document higher when it has an outgoing implements link. The plain search tool does not use links.

Links made from a path-matching heuristic are marked implements-heuristic and ranking gives them no weight. Links suggested by a model are advisory. The links you add by hand are the ones a later reader trusts.

A question over several papers on one subject needs several searches, the passages from each result, an extraction, and a comparison. Claude runs that as a plan and returns one answer with a source for each claim, and a plan that worked is saved for the next question of the same shape.

/conexus:query What do the <SUBJECT> papers say about <THE POINT>?

Claude calls nx_answer with the question and the collection. If a saved plan fits, it runs. If none fits, Claude writes a plan, runs it, and saves it. A comparison across one collection takes one to five minutes.

nx_answer  question: What do the semantic operator papers say about batching to reduce model calls?
           scope: knowledge__semantic-operators…   step_count: 6   cost_usd: 0.31
  step 0  search           sql     3.1s
  step 1  store_get_many   sql     0.4s
  step 2  search           sql     2.9s
  step 3  store_get_many   sql     0.4s
  step 4  extract+generate bundle  67.4s   (steps 4 and 5 in one dispatch)

## Bottom line
The provided passages do not document batching multiple records into a single prompt. …
What the passages do cover is a neighbouring set of call-reduction levers: model cascades,
per-operator model and backend selection, plan-level cost/quality optimization, and semantic caching.

## Call-reduction techniques the passages do name
"Bridge the Last Mile Gap to Semantic Analytics" (published 2026) gives the clearest inventory:
- Palimpzest [12] pioneered the paradigm and explores cost/quality tradeoffs across execution plans.
- LOTUS [14] provides formal accuracy guarantees through model cascades. …

## What would be needed to answer the question as posed
… the LOTUS and Palimpzest papers themselves, the DocETL and Helium papers …

The answer says what the store does not hold as plainly as what it does. "Not in these passages" is a result: it names the papers to add next, and it is what a store you curated can say that an open web search cannot.

Limit the question to one collection

"What do the semantic-operator papers say about batching" searches the papers in that one collection. "What does the literature say about batching" searches everything, takes longer, and mixes subjects.

See the saved plans

List the saved retrieval plans for this project that match "batching".

plan_search  query: batching semantic operators   project: nexus
[365] What do the semantic operator papers say about batching and …
  outcome=success  tags=ad-hoc,grown
  plan: {"steps": [{"args": {"limit": 12, "query": "semantic operators over documents LLM call batching …

If an answer surprises you, ask: "Which plan did that use, and what did each step return?" A plan that searched the wrong collection is visible in its first step.

A mapping says, claim by claim, where a paper touches your own system. Each claim gets one of three answers: this module already does it, this design record rejected it for a reason, or this applies and nothing does it. Only the third kind leads to a proposal, and a proposal is written with the result that would show it is wrong.

The mapping

Map <THE PAPER> onto our system. For each claim: does it apply to us, which module or design record does it touch, and does it agree with what we decided. Link the paper to those modules and records in the catalog.

Claude reads the reconstruction from lesson 3, searches the code and the design records for each claim, writes the mapping to the store, and adds the links from lesson 4.

Mapping onto the system (links created in the catalog):
- RDR-089 aspects at ingest (1.1.3896, implements-heuristic): the document_aspects table is the
  paper's claims layer, but per document, not atomic, and without the byte-exact provenance gate.
  The gap is claim granularity and provenance validation, not the architecture.
- RDR-181 server-side embed-skip (1.1.2822, implements-heuristic): the "cost scales with change"
  half; unchanged chunks are skipped, but there is no low-rank incremental update, because
  pgvector stores raw vectors and needs none.
- RDR-199, RDR-108, RDR-096, RDR-055 (relates): the paper's tombstoning and redo log correspond
  to the catalog manifest, the tombstones, and the aspect queue.

The proposals

Write proposals from the mapping of <THE PAPER>. Give the agent the mapping, the linked design records, the code paths, and a web check. Every proposal states what it changes, the result that would show it is wrong, and a cost. Include a do-nothing option.

The research agent runs with that instruction and returns three to six proposals, each with its falsifier and its cost, plus the do-nothing case. The document goes to the store with a cites link to the paper. A proposal with no way to be wrong is an opinion, and the falsifier is what makes the next experiment obvious.

A mapping usually finds that two of every three claims are already handled or already rejected. The mapping records that too, linked to the record that decided it, so the next reader of the paper finds the decision instead of repeating the argument.

A synthesis alone produces a plausible plan with false premises, and an experiment alone produces a correct number with a wrong explanation. Two checks make both usable: a critique of the plan by a second reader with access to the code, and a recompute of the result from the raw data instead of the report.

Critique, with the artifacts

Have the critic read the proposals on <THE PAPER> with access to the code, the schema changelogs, and the design records. For each proposal: survives, survives with amendment, or dies, with the artifact that decides it.

The critic agent runs with the paths to check. It returns its critique in its own fixed format: the issues it found, each with the evidence, and an outcome of justified, partial, or not justified. Claude then writes a verdict document that says, for each proposal, survives, survives with amendment, or dies, and links it to the proposals and the critique.

## Critical Issues
### Issue: Proposal 3's central premise is false — the run table has no document-read signal
- Evidence: service/…/telemetry-001-baseline.xml (changeset telemetry-001-7); telemetry-007-nx-answer-steps.xml
### Issue: Proposal 4 cites RDR-108 as a template already built, but RDR-108 rejected exactly that pattern
- Evidence: docs/rdr/rdr-108-graph-identity-normalization.md ("Alternatives Considered" / Alternative A)
### Issue: Proposal 2 conflates quote provenance with the paraphrase-only aspect schema
- Evidence: src/nexus/aspect_extractor.py field specs

## Verdict
- outcome: not-justified   confidence: high   critical_count: 3   significant_count: 5

## The ideas, and which survived
1. Replicate the agent-layer experiment before building anything.   Survives.
2. The redo-log idea maps onto a known gap.                          Survives, and the synthesis had missed it.
3. Compile-time provenance validation gate.                          Dies as specified. Amendment: a narrow gate over extractable sub-facts.
4. Break-even instrumentation.                                       Dies as "free". A small schema change survives.
5. Atomic claims layer.                                              Blocked on item 1, and the synthesis cited the wrong precedent.
6. Incremental embedding maintenance.                                Rejected on the merits.
## Recommendation
Run item 1. Fold item 2 into the existing beads. Do not build item 5 on faith.

Proposals die for reasons like these. A changelog shows a table has no document identity. The alternatives section of a design record shows an idea was rejected and not adopted. A field holds a paraphrase and not a quote. None of that is in any paper, and semantic search over prose does not find it. Tell the critic which files to read.

Pre-register the measurement

When a surviving proposal has a falsifier that can be measured, write one paragraph before you spend anything, and have every later check run against it.

Write the pre-registration paragraph for <THE EXPERIMENT>: the arms, the one variable that differs between them, the confounds you know of, the metrics, the statistic, the budget, and the result that would show the hypothesis is wrong. Do not run anything until I have read it.

Build the harness so it can be audited

Build the harness for <THE EXPERIMENT>. Fix the random seed and the model identifiers. Retrieve once per question and cache the result. Save, for each trial, the exact text each arm received, the structured flags, and the cost of every model call. Report McNemar, Wilson intervals, and a cluster-robust paired difference.

A harness that produces only a summary table cannot be audited. A harness that keeps the input text, the reader's flags, and every cost can answer, later, why any trial failed.

Recompute the result

Methodology critique of <THE EXPERIMENT>. Give the critic the raw trial data, not the report. Recompute every number. Classify every outcome as correct, wrong, or no answer. Check that the generated data follows its own generation rules. Validate the grader on a sample labelled by a person.

Verdict: NOT-JUSTIFIED, 3 ship-blockers, confidence high. Do not proceed to an engine change on this evidence.

ARITHMETIC IS CLEAN. Every number in report.md reproduces exactly from retrievals.jsonl by independent
recomputation … The instrument, not the arithmetic, is the problem.

SHIP-BLOCKER 1 — THE HEADLINE IS FORCED BY CONSTRUCTION. On the current leg, 35 of 35 of arm A's stale
top-1 documents ARE the question's own source document. … More than half the A-to-B gap on both metrics
is reproduced by a control that knows nothing about validity.

SHIP-BLOCKER 2 — THE LEG THAT PASSED DOES NOT TEST THE TEMPORAL SIGNAL. …
SHIP-BLOCKER 3 — 7 OF 14 VALIDITY WINDOWS ARE WRONG, AND THE GROUND TRUTH WAS IN THE FILE. …

WHAT A FAIR RERUN NEEDS. (1) Read the dates from frontmatter and fall back to git only when absent …

A report that says "the treated arm mostly answered wrongly" and a raw log that shows most of the failures were no answer at all are two different findings. Only the recompute finds the second. The critique above is from a second experiment, on the temporal validity of design records. It found a clean report over a broken instrument, which no reading of the report could have shown.

The material is already in the store and linked, put there by sessions that may be weeks apart. A rendering is one document written from the current content of those stores for a reader. It can be a report on a question, a briefing for people who did not follow the work, a precis of a paper, or the design of a test. Ask again later and the document is current.

Render everything we did with <THE PAPER> as one document: what the paper claimed, what applied to us, what we proposed, what the critic removed and why, what the experiment showed, and what is still open.

Claude starts at the paper's catalog entry, follows the links to every document produced from it, and writes the report from their current content. The report goes into the store, linked to all of them.

links to 1.12.119 (the paper):
  1.11.529  first-pass mapping                       comments
  1.11.530  research synthesis, five proposals        cites
  1.11.531  critique pattern, recorded for reuse      cites
  1.11.532  verdict after critique                    cites   supersedes 1.11.529, 1.11.530
  1.11.533  the experiment and its result             cites   relates 1.11.532
  1.11.534  findings on the method                    cites   comments 1.11.533

The verdict supersedes the mapping and the synthesis it reduced, so a reader who opens the paper a year from now finds the current state first and the earlier drafts behind it.

Check that the record was kept

What did you write to the stores today, and what does it link to?

If the answer is "nothing", the work exists only in this conversation and the next session starts without it. Ask after each piece of work, not once a day. The test is that a person who was not present can follow the links from the paper through everything done with it.

When there is an idea and no paper

Brainstorm the design space around <THE IDEA>: related designs, what we could merge into existing parts, what would be new. Then write where it sits among systems that do similar things. Store both as exploration, each with a decision line: adopted, parked, or scrapped.

The rendering is the first step when the space is open. An exploration with no decision line is a question that waits for you, and "Which explorations have no decision line?" lists them.

Most of the time you use none of these directly: you say what you want and Claude chooses the tool. These are the surfaces for when you want to see or drive one yourself.

nx doc cite "<A CLAIM>" --against <COLLECTION>
nx catalog links "<TITLE>"
nx taxonomy list --collection <COLLECTION>

The first finds the chunk that grounds a sentence and returns a link to it, or says that nothing in the collection does. The second is the link list from lesson 4. The third shows the topic map of a collection.

$ nx doc cite "compiled claims as the retrieval payload won all 32 cells on MediaSum at 85.2 percent correct" --against knowledge__dt-papers
[to floating-point precision. And on a held-out sample of 500](chash:e97331ff10ab59c8c97537bc440fbd6c4e85cd167579af89fa133b550418bf5d)

$ nx doc cite "compiled claims as the retrieval payload beat chunking" --against knowledge__dt-papers
top candidate distance 0.388 above threshold 0.300 — no cite emitted. Try a narrower claim or broaden the collection.

$ nx taxonomy list --collection knowledge__dt-papers__voyage-context-3__v1
[knowledge__dt-papers__voyage-context-3__v1]  LLM reasoning arXiv papers (2655 docs)
[knowledge__dt-papers__voyage-context-3__v1]  Attention mechanism formulations (1970 docs)
[knowledge__dt-papers__voyage-context-3__v1]  Graph-based RAG with LLMs (576 docs)
[knowledge__dt-papers__voyage-context-3__v1]  Hilbert and Moore curves (449 docs)

The second cite call shows the refusal: a claim too vague to ground returns no link and says so, which is the behaviour you want from a citation tool.

Nothing here is needed to do the lessons. It is here for the reader who wants to know why an answer carries sources, and what the store builds over a collection beyond its chunks.

search_aspect_scoped  query: retrieval payload compiled claims versus chunks
                      field: experimental_datasets   pattern: %MediaSum%
[knowledge__dt-papers__voyage-context-3__v1] 1.12.119 (dist=0.5450)
  … What is new here is compiling the payload the reader consumes, and validating it against
  the span it came from. Proposition-level indexing [3] decomposes passages into standalone
  propositions and indexes those …