One Piece of Research, End to End

Open Notebook becomes easier to judge when its notebook relationships and source-processing pipeline are read as one lifecycle rather than as separate features. This checkpoint connects what a source is, where it belongs, how its text is prepared, and how a generated interpretation can emerge from it. The practical judgment is simple but demanding: before trusting an answer, identify which state the research is in and which transition may still be uncertain.

One source has more than one life

Consider a researcher investigating whether a new procurement policy improves delivery reliability. They add a public report to a notebook, perhaps alongside interview transcripts and internal notes. The report now has a place in the research graph, but it does not yet have a single meaning inside the system. It has a storage life, a processing life, a retrieval life, and a research life.

Its storage life begins when the report is associated with the notebook. That relationship says the report is part of this project and may be considered when the notebook's contents are listed or its scope is used. It does not say that every future question should send the report to a language model. It also does not prevent the same public report from being linked to another notebook if it is relevant to another project.

Its processing life begins when Open Notebook extracts readable content. A text-native report may yield paragraphs directly. A scanned report may need OCR. A document with tables or columns may require layout-aware processing. A web version may need a renderer if its body is created by JavaScript. If extraction produces an empty or unusable result, the report has not reached the state in which its contents can support research, even if an initial record exists.

Its indexing life begins after the extracted text is divided into pieces and represented for search. Source chunks and their embeddings support semantic retrieval; notes and insights can receive their own embeddings. This creates a second representation of the report. It is useful because a question can be compared with many manageable pieces rather than with one unbounded document, but it is also a point at which structure and context can be lost.

Its retrieval life begins when a search or question can use those representations. A lexical search may find the exact phrase “delivery reliability.” A vector search may find a passage about late shipments even if it uses different wording. Ask may search for several related terms and combine the resulting answers. Chat may use selected content and conversation history instead. The same report can therefore be present in the notebook while appearing differently—or not at all—depending on scope, index readiness, question, and interaction mode.

Its research life is what happens after a person reads or discusses the result. A transformation may extract the report's method and limitations. A researcher may save a note comparing it with interviews. A conversation may reveal that the report measures a short-term effect while the internal data concerns a longer period. At that point, the system has not merely “answered a question.” It has created a chain from a source to a derived interpretation and perhaps to a new claim.

The chain is useful because each step has a different owner. The notebook relationship determines membership. The extraction path determines what text is available. The indexing job determines what can be found semantically. The search or context builder determines what is presented to a model. The model writes an answer or insight. The researcher decides whether that output is worth preserving and whether it actually follows from the source.

This is also why a failure at one stage can look like a failure at another.