Our AIPOCH Open-Science preprint, AIPOCH Open-Science: An Open-Source AI Research Workbench with Reproducible .science Packages, is now available on arXiv. Submitted on October 12, 2026, the paper examines a practical question: when AI-assisted research changes hands, what should travel with the result?
The answer we explore is a portable .science package: selected conversation branches, file versions, Notebook records, and verification evidence, with their recorded relationships retained for inspection. Someone receiving the work can examine the task, the computation, the version being discussed, and the checks associated with it.
This article introduces the research question and the contribution of the paper. For a practical companion, our earlier guide, AIPOCH Open-Science .science: Share Research with Context, explains the handoff workflow and what a recipient should inspect. Read the preprint for the methods, results, and limitations. The manuscript is a preprint, and we do not present it as a peer-reviewed publication.
Why should the work behind a result travel with it?
A research output becomes easier to evaluate when its history is available. A table might have been generated from an uploaded dataset, corrected after a review, and edited again before delivery. A recipient needs enough context to tell those stages apart.
Consider a colleague opening summary.csv. The filename alone cannot explain which instruction produced it, which earlier version contained an error, whether the latest edit was checked, or whether the required input is included. Those questions can change how the colleague interprets and reuses the result.
AI-assisted work makes this especially visible because instructions, execution records, and files can sit in different parts of the workflow. A conversation records a requested analysis. A Notebook records a calculation. A review records a judgment about a particular scope. A useful handoff connects these materials so the next researcher can inspect what happened.
The paper's introduction treats the research session as an object of sharing. Its focus is the exchange of recorded work: how context, versions, and assessments retain their meaning when selected materials move into another workspace.
What does AIPOCH Open-Science contribute?
AIPOCH Open-Science is an open-source AI research workbench that organizes conversations, computations, files, and available provenance in a persistent workspace. Researchers can inspect outputs, choose compatible models and tools, and direct follow-up work. Our guide to the AIPOCH Open-Science research workbench introduces that broader project-and-execution model.
The .science capability extends that workspace into a handoff. Researchers choose which supported session materials to export, transfer the resulting file, and import it into another project or computer. The package documentation describes the current scope and content-selection controls.
The paper's central contribution is an implemented exchange contract: rules for what recorded relationships must still mean after transfer. A check of version 2 should still point to version 2 after import, even if the receiving workspace assigns it a new internal ID. An omitted file's identity should remain distinguishable from its available contents. Historical records should remain separate from subsequent writable work.
This framing gives researchers concrete questions to ask of a handoff. Can I locate the relevant task? Which activity produced this version? What was assessed? Which materials can I actually inspect? These questions help define an acceptance check before someone relies on a shared output.
Which relationships need to survive a handoff?
The methods section describes several distinctions that the exchange contract preserves. Each addresses a different source of ambiguity in shared research.
| Question at handoff | What the retained record helps distinguish |
|---|---|
| Which output am I looking at? | A particular artifact version and its revision history. |
| What produced it? | The recorded producing activity and available task context. |
| What was checked? | The assessment's target version and recorded scope. |
| Is a described step complete? | An instruction or plan versus recorded execution. |
| Can I access this input? | A known file identity versus included or explicitly omitted contents. |
| Where can new work begin? | Read-only imported history versus a separate writable context. |
Version-specific review is particularly important. A failed assessment of an early output, a later checked correction, and a new unreviewed revision can all exist in the same history. A recipient needs to see which judgment belongs to which version. For background on the underlying output records, see our explanation of artifact versions and provenance in AIPOCH Open-Science.
Partial sharing introduces another practical requirement. If eligible file contents are left out, the package should make that absence visible. The paper also describes consistency checks that can refuse an exclusion when the same bytes remain inseparable from retained evidence. Content selection therefore requires inspection; a smaller package is not always a valid selection.
Editorial schematic based on the paper's controlled example.
What did the study examine?
Using Open-Science 0.37.1 on macOS, the controlled study followed a deliberately constructed sequence: an incorrect first output, a reviewed correction, a later unreviewed revision, and a planned step that was never executed. Complete and partial exports were compared with separately extracted source records, then imported into different projects in the same installation. The examined version and review associations were retained, while excluded contents remained identifiable as unavailable.
A separate public-registry case connected a table to its task, execution, and review records. Running its saved script offline with fixed input regenerated two retained CSV tables byte for byte. A well-documented ordinary directory also supplied evidence for all seven static inspection questions.
The results concern the specified records and operations; they do not establish complete capture, cross-installation performance, or recipient efficiency, or constitute comprehensive testing of the later 1.0 release.
How can researchers use this approach?
The current package guide supports a practical starting point: export a completed session, inspect the selected contents, and import it into a destination project. Before handing over a package, identify the result you want someone to examine and the materials they will need.
A useful review can start with three questions:
- Can the recipient understand the task? Leave essential context in the exported conversation or an included report. Side Chat conversations and private reading bookmarks are excluded.
- Can the recipient identify the right version? Name the output and point to the revision and available checks that matter to the handoff.
- Does the package contain enough material for the intended next step? Review the actual export selection. A package sufficient for reading may still lack inputs or runtime requirements needed for re-execution.
Editorial schematic of the documented handoff.
What does a .science package let a recipient inspect?
According to the product documentation, included materials depend on the export selection. A package can carry selected conversation branches, file versions, Notebook records, and verification evidence. The recipient can inspect the recorded process and available files in the receiving workspace.
Imported sessions remain read-only. Import does not execute code or restore credentials. Follow-up discussion or continued research uses an associated writable context and receiving-side permissions. Any subsequent computation still needs the necessary inputs, software, and runtime.
Received verification records describe checks carried out on the sender's side. They do not show that the receiving computer has rerun those checks. Researchers should keep three questions separate: what the historical record says, what is available now, and what has actually been executed in the receiving environment.
What comes next?
The discussion identifies further work on exchange across installations, failure paths, and how recipients understand the evidence. Those questions matter because preserved records and useful human understanding are related outcomes that need separate evaluation.
The paper also outlines a future evidence-linked reading layer: a human-readable account of the task, executed and unexecuted steps, revisions, assessments, and known omissions. This remains planned work.
For the broader product context, read the AIPOCH Open-Science 1.0 announcement.
Read the preprint and inspect the work
We invite researchers and research-software teams to read the AIPOCH Open-Science preprint and consider what they need from a research handoff. Two resources provide a direct route into the supporting materials:
- The versioned validation release cited by the paper contains the study's public audit materials and identifies the evaluated registry-case snapshot. Its README explains how the de-identified publication copies relate to the original application observations.
- The public research-case collection offers a broader set of examples. It is separate from the complete evidence for this controlled study; use the fixed release above for the evaluated snapshot.
To try the approach, explore AIPOCH Open-Science and choose one completed session to share. Use the practical handoff checklist in our .science guide to prepare the materials, and consult the current package documentation for export controls. Start with a concrete recipient question: can someone else understand which result this is, how it was produced, and what was checked?
About the collaboration
As the author-contributions statement explains, AIPOCH contributors developed the workbench and its infrastructure, while collaborating institutional authors used the product, supplied feedback and revision suggestions, and supported supplementary product validation.
FAQ
What is the AIPOCH Open-Science preprint about?
The preprint studies research-session exchange through .science packages. It examines how recorded versions, assessments, and content availability retain their meaning during the tested export-and-import operations.
Where can I read and cite the paper?
Use the arXiv record, or the version-specific record when citing the version discussed here.
Does importing a .science package rerun the research?
No. For the receiving-side workflow and the requirements for a new execution, see the package guide.
Can a .science package support scientific review?
It can provide recorded context and available evidence for researcher review. The paper's discussion explains how to interpret those records and the questions that need further evaluation.
Disclaimer
This article summarizes arXiv:2610.17110v1. The reported observations apply to the implementation, records, and operations examined in that version. The schematics explain the paper and documented handoff; they are not additional experimental results.