Stratum← Stratum Journal
← Stratum Journal
ResearchMarch 10, 20269 min read

The First 90 Days

What ResearchOS does in a computational lab — concretely, week by week


Most descriptions of knowledge management tools for research labs are aspirational. They describe a future state where everything is documented, searchable, and magically transferable to new lab members. They do not describe what actually happens in the first three months — the unglamorous, incremental accumulation that makes the future state possible.

This is a concrete walkthrough. What gets indexed first. What becomes queryable when. What the experience looks like for a PI, a postdoc, and a first-year graduate student joining six months in. No futures tense. What actually happens.

The lab in this walkthrough is a computational materials or chemistry lab — 10 to 20 researchers, active HPC usage (VASP, LAMMPS, or similar), high student turnover, several years of accumulated research history that lives mostly in people's heads and scattered directories.

The First Week: Connection, Not Magic

The first thing ResearchOS does is not impressive. It connects to your existing records — email threads where research decisions were discussed, Slack conversations, shared directories on the cluster, existing lab notebooks, paper drafts and their associated supplement files. Nothing gets created. Nothing changes. The system reads what already exists.

In a 12-person lab with five years of history, this initial indexing covers somewhere between 400 and 2,000 documents, depending on how well-organized the lab's records are. Most labs are moderately disorganized — good enough to find things eventually, not good enough to find them when a new student asks a question in their first week.

At the end of week one, the system knows what exists. It does not yet know what it means. That comes from the next layer: the structured memory that accumulates as the lab works.

Weeks Two Through Four: The First Useful Answers

The first queries that return specific, useful answers are usually the historical ones. Not "what should we try?" but "what did we already try?" — the questions where the answer exists in a document somewhere and has just never been surfaced efficiently.

Early queries that typically work well
  • "What exchange-correlation functionals have we used for this material class, and when did we switch?"
  • "Did we ever try this synthesis route? What happened?"
  • "What papers did the lab read on this topic in the last two years?"
  • "Who in the lab has worked with this code before?"
  • "What convergence parameters did Chen use for the perovskite series?"

These queries do not always work perfectly in week two. The indexing is shallow on recently added records. But they are substantially better than the alternative — which is asking the question at group meeting and waiting for someone to remember, or spending two hours in the cluster directory structure trying to find the right job submission script.

Month Two: The System Learns the Lab's Vocabulary

By month two, the memory layer has processed enough new conversations, meeting notes, and experiment records that it begins to understand the lab's specific vocabulary. Your lab has names for things. You call the VASP convergence parameters something specific internally. There is a shorthand for certain material classes or certain instrument configurations. The general-purpose language model does not know these terms. By month two, the memory layer does.

This matters because it changes the quality of answers. A query about "the modified basis set" now returns results about the right modified basis set — the one your lab developed, not the one in a paper from a different group. The system is no longer pattern-matching against general chemistry knowledge. It is pattern-matching against your lab's specific history.

The system does not become smarter between month one and month six. The underlying model is identical. What changes is access — the scope of the lab's knowledge that the model can see and reason over. The compounding is in the data, not the reasoning.

Month Three: A New Postdoc Joins

The clearest demonstration of what the system has accumulated is usually when someone new joins. A postdoc in month three of your ResearchOS deployment has access to a different lab than one who joined three months before the system was set up.

The postdoc who joined before can answer her own questions about lab history — sometimes. She knows to look in the right Slack channels, she has found the cluster directories, she has figured out which of the existing students has the relevant knowledge and can be interrupted. She has done the normal 3-month onboarding: slow, expensive, largely invisible.

The postdoc who joins at month three can ask the memory layer directly. "What KPOINTS mesh did the lab converge on for these materials?" and receive a specific answer with a file path. "Has anyone in the lab tried this computational method?" and get a summary of two students' work from two years ago, with the outcome. The three-month onboarding does not disappear entirely — but the part that was spent locating information that already exists is dramatically compressed.

The Graduation Moment

The original problem — the one that motivates most labs to think about this — is graduation. A PhD student or postdoc with three to five years of accumulated lab knowledge defends, leaves, and the knowledge leaves with them. The next student spends a year recovering ground that was already covered.

By month three, the memory layer has not solved this problem completely. Three months is not enough to capture years of accumulated context. But it has solved it at the margin: every meeting, every decision discussion, every Slack thread, every experiment record from the last ninety days is indexed. When the student who has been working on the carbon nanotube defect characterization defends and leaves, the last three months of her work is not gone. It is indexed and queryable.

What used to happen at graduation: institutional knowledge loss proportional to the student's tenure. What happens at graduation after twelve months of continuous indexing: a defined, bounded gap — the period before indexing started. That gap is fixed and shrinking backward as older records are retroactively processed. The forward edge stops accumulating.

What Stays the Same

The most common question from labs evaluating this kind of system is what changes about the existing workflow. The answer is: almost nothing, and this is by design.

Researchers do not need to log into a new system. They do not need to write in a new format or maintain a new database. The existing channels — email, Slack, shared cluster directories, lab notebooks in whatever format they currently exist — remain unchanged. The memory layer reads them. It does not require them to change.

The only behavioral change is optional: researchers can ask the memory layer questions directly, and they can submit structured records (experiment summaries, decision logs) that index more cleanly than raw Slack threads. Labs that do this consistently get better answers faster. Labs that do nothing but connect their existing records still get a baseline level of searchable history that did not exist before.

What Month Three Looks Like, Honestly

At ninety days, the system is not complete. It is not a comprehensive repository of everything the lab has ever known. The knowledge it has not captured is still in people's heads, in paper notebooks that were never scanned, in files on a cluster partition that was not connected.

What it is, at ninety days, is a working system that is accumulating. Every week it has more than the week before. Every graduation event captures more than the one before it. The gap between "what the lab knows" and "what is findable" is narrowing, week by week, without anyone doing anything differently.

That narrowing is the value. Not a finished product at day one. A system that compounds, reliably, from the day it is connected — and makes the question "did we try that?" easier to answer every month that passes.


Probe — ResearchOS for Research Labs

Probe is the persistent knowledge layer for computational research labs. It connects to your existing workflows — cluster directories, email, Slack, lab notebooks — and makes the lab's accumulated knowledge queryable from day one. Founding lab pricing available through Q2 2026.

Learn more at probe.onstratum.com →