The Notebook Model: Sources In, Notes Out
Open Notebook's notebook model solves a more difficult problem than putting related files in one folder: it decides which research materials belong together, which operations may use them, and how an interpretation can remain connected to the evidence beneath it. This chapter focuses on the relationships among notebooks, sources, insights, notes, and conversations. Once those relationships are clear, a reader can organize a project deliberately and understand why a later answer appears—or does not appear—in a particular research context.
A notebook is a working scope, not a folder
A folder is mainly a storage convenience. It groups files by location, but it does not say much about how those files should be understood. A notebook in Open Notebook is closer to a bounded research workspace. It has a name and description that establish the subject of the work, and it gathers sources, notes, and conversation history around that subject.
That description is not just decoration. If a notebook is called “Supplier risk review” and its description says that the work concerns delivery reliability and contractual exposure, the description gives later interactions a point of orientation. The notebook tells the system—and the researcher—what the collection is for. It becomes the scope in which material is selected, searched, discussed, and turned into further work.
Inside that scope, the main objects have different jobs.
A source is incoming material: a paper, report, web page, transcript, recording, or other content that the researcher wants to examine. It is the closest thing in the workspace to an exhibit in a case. The system may extract its text or metadata and prepare it for retrieval, but the source remains the material from which later claims should be checked.
An insight is derived from a source. It may be a summary, a list of key concepts, a methodological extraction, or another result of applying a transformation. It is useful because it concentrates a large source into a form that is easier to scan or reuse. It is not equivalent to the source. Its wording reflects a processing step, and its accuracy depends on both the source and the model that produced it.
A note is the workspace's editable knowledge layer. The researcher can write one from scratch, save a useful Chat or Ask response, or preserve a generated insight as a note. Notes can include interpretation, questions, next steps, tags, and links back to sources. They can be revised as the research changes. That makes them more flexible than source records, but also more dependent on careful review.
A chat session preserves a conversation about the research. It records a line of questioning that may be valuable in its own right: what the researcher asked, what the model answered, and which issues still needed clarification. It is not a replacement for a note. A conversation records exploration; a note usually records a conclusion or a deliberately retained working idea.
The separation among these objects protects against a common failure in AI-assisted work: treating a fluent summary as if it were the original evidence. Suppose a report says that a pilot produced a modest improvement under narrowly defined conditions. A generated insight might shorten that to “the pilot improved performance.” A note might then carry the shorter statement into a later discussion. Unless the researcher keeps the source relationship visible, the qualifying conditions can disappear one layer at a time.
The layers also make state ownership easier to reason about. The source owns the material that was brought into the workspace. Processing may add extracted text, searchable representations, or a refreshed version, but it does not turn those representations into independent evidence. A transformation owns the act of producing an insight from that material. The insight can be regenerated when the transformation or source changes. The researcher owns the decision to keep a note, edit its wording, mark a question as unresolved, or connect it to another source. The model contributes language and pattern recognition; it does not own the researcher's conclusion.
Consider a literature review. The researcher may preserve five papers as sources, run the same extraction over each, and receive five insights with a comparable shape. A later note might say that three papers share an assumption while two challenge it. That note is more useful than five isolated summaries because it records a relationship across the collection. It is also a new claim. The links to the five sources are what allow the researcher to test whether the comparison is fair, whether one paper was misread, or whether an exception was smoothed away by the summary format. The notebook model supports this movement from evidence to comparison, but it does not make the comparison self-validating.
Open Notebook's structure makes the distinctions available:
- The source preserves what entered the research workspace.
- The insight records what a transformation extracted from it.
- The note captures what the researcher wants to remember, question, or use.
- The conversation records how understanding developed through interaction.
These layers are connected so that work can accumulate, but they should not be collapsed. The source is not made more authoritative because it has an embedding. The note is not made more factual because it is searchable. The conversation is not made complete because it contains a confident answer.
Relationships decide what the workspace can see
The notebook model becomes operational through relationships. A source is linked to a notebook; a note is linked to a notebook; a conversation is associated with the research container it explores; and an insight remains tied to its source. Those links are what the application can use when it lists a notebook's contents, builds context, or applies a notebook scope to search.
The important point is that scope is not inferred from a title. Two documents called “Quarterly Review” may belong to different projects, while one public report may be relevant to several projects. The relationship tells Open Notebook whether an item belongs to the selected research space. When search is restricted to one or more notebooks, the system resolves those links and limits the result set accordingly. Sources, their derived insights, and notes follow their respective parent relationships.
This also explains why a missing result is ambiguous until scope is checked. If a search is limited to a notebook about product research, a source stored only in a separate market-analysis notebook should not appear. That does not mean the source is absent from the database or that the search engine failed. It means the question was asked inside a narrower boundary. When no notebook scope is supplied, search can operate over the wider knowledge base instead.
The same rule applies to notes, but with an extra risk. A note can contain a conclusion that was assembled from several sources, so it may be relevant to a notebook even when no single source contains its exact wording. If the note is included in a later search, it can surface as a useful lead—or as a compressed version of an earlier mistake. A scoped result should therefore answer two questions: “Why is this item in the workspace?” and “What kind of item is it?” The first is answered by the relationship to the notebook. The second requires reading its source, insight, or note status.
Scope is also evaluated at the time an operation runs. Changing a notebook relationship, refreshing a URL source, or editing a note can change what a future search sees without rewriting an old conversation. That makes timestamps, source titles, and links back to the underlying material valuable. A conversation can preserve what was known at the time, while a later search can reflect the current state. The workspace is not a static snapshot unless the researcher deliberately treats it as one.
The current implementation also supports a source being linked to more than one notebook. That matters when a public regulation, benchmark, or technical standard informs several projects. It allows reuse without pretending that the source has been copied into independent worlds. But reuse makes deletion and updating more consequential. Removing one notebook should not destroy a source still used by another, so the application distinguishes sources that are exclusive to the notebook being removed from sources shared elsewhere.
This is one place where the project's conceptual documentation is simpler than its current behavior. An older mental model describes each source as belonging to exactly one notebook and describes sources as never changing after they are added. The present relationship and lifecycle code is less absolute: source metadata can be edited, and a URL or file source can be processed again. The safer interpretation is not that a source is physically immutable. It is that source material and derived interpretation must remain distinguishable, and that reprocessing can change the text on which future retrieval and notes depend.
That qualification is useful in practice. Consider a team researching a product launch. A public industry report may be linked to a “Market context” notebook and to a “Launch planning” notebook. An internal interview transcript may be linked only to the second. A note comparing the two can be saved in the launch notebook. If the public report is later refreshed, the researcher should treat the resulting change as a new point of attention: an old note may still reflect the earlier version, even if the note itself has not changed.
The relationships also establish a clean deletion boundary. Notes connected to a notebook are part of that notebook's working knowledge and can be removed with it. Sources may be unlinked or, when they are not used elsewhere and the operator chooses the stronger deletion option, deleted as well. Chat sessions associated with the notebook are part of its conversational history. These are not abstract database details; they determine whether closing a research project means archiving a view, removing links, or destroying the underlying material.
Evidence, interpretation, and reuse need different lifecycles
The three most important lifecycles are not identical.
Sources are added, extracted, indexed, and used. Their metadata can be corrected, and URL or file content can be reprocessed. Because they are the foundation of later claims, a researcher should regard each processed version as a particular evidentiary state. If the source changes, derived notes may need another look.
Insights are created from a source by a transformation. They can make repeated analysis manageable: the same extraction pattern can be applied to a set of reports so that their findings are easier to compare. But the output is still a model-generated interpretation. It should be checked against the relevant source before it becomes a premise for a decision or a polished report.
Notes evolve as the researcher's understanding evolves. A manual note may begin as a question, acquire evidence from several sources, and eventually become a decision record. An AI-generated note may need correction, qualification, or a link to a passage that the model did not include. The fact that notes are editable is not a weakness. It recognizes that synthesis is a working activity rather than a fixed property of the source.
This is why a strong workflow does not ask one object to do every job. Sources provide the record. Insights reduce repetition. Notes preserve judgment. Conversations expose uncertainty and help the researcher decide what to investigate next. Search makes all of those layers discoverable, but discoverability does not erase their differences.
The distinction becomes especially important when notes are reused as context. A note is smaller and more focused than a long report, so it can be efficient for a later conversation. Yet it may also contain a compressed interpretation. If the later question depends on a number, exception, attribution, or disputed conclusion, the note should point the researcher back to the original source rather than serving as the final authority.
The notebook therefore provides two kinds of control at once. It controls membership—which records belong to a project—and it supports interpretive layering—which records are raw material, derived material, or working understanding. The first helps prevent unrelated projects from blending together. The second helps prevent the system's output from being mistaken for evidence. Both controls are necessary for trustworthy AI-assisted research.
There is a practical limit, however. A relationship only works if it is used deliberately. A source can be linked to the right notebook and still be poorly extracted. A note can have a source link and still overstate what that source says. A global search can return a relevant item that belongs to a different project. The model gives the researcher a structure for making these distinctions; it does not make the distinctions automatically on the researcher's behalf.
The next boundary is procedural rather than organizational. Once a source has a place in the notebook, Open Notebook must turn its contents into something the rest of the system can use. That involves extraction, optional OCR or rendering, chunking, embeddings, and background processing. Understanding those stages will show why a source can be present in the right notebook yet still not be ready for semantic search—and why the quality of every later answer begins before a model is asked a question.