Center for Open Neuroscience

DataLad is a Python-based tool for the joint management of code, data, and their relationship, built on top of a versatile system for data logistics (git-annex) and the most popular distributed version control system (Git). It adapts principles of open-source software development and distribution to address the technical challenges of data management, data sharing, and digital provenance collection across the life cycle of digital objects. DataLad aims to make data management as easy as managing code. It streamlines procedures to consume, publish, and update data, for data of any size or type, and to link them as precisely versioned, lightweight dependencies. DataLad helps to make science more reproducible and FAIR (Wilkinson et al., 2016). It can capture complete and actionable process provenance of data transformations to enable automatic re-computation. The DataLad project (datalad.org) delivers a completely open, pioneering platform for flexible decentralized research data management (RDM) (Hanke, Pestilli, et al., 2021). It features a Python and a command-line interface, an extensible architecture, and does not depend on any centralized services but facilitates interoperability with a plurality of existing tools and services. In order to maximize its utility and target audience, DataLad is available for all major operating systems, and can be integrated into established workflows and environments with minimal friction.

Most work on NiBabel so far has been by Matthew Brett (MB), Chris Markiewicz (CM), Michael Hanke (MH), Marc-Alexandre Côté (MC), Ben Cipollini (BC), Paul McCarthy (PM), Chris Cheng (CC), Yaroslav Halchenko (YOH), Satra Ghosh (SG), Eric Larson (EL), Demian Wassermann, Stephan Gerhard and Ross Markello (RM). References like "pr/298" refer to github pull request numbers. 3.2.1 (Saturday 28 November 2020) Bug fix release in the 3.2.x series. Maintenance Drop references to builtin types in Numpy namespace like np.float (pr/964) (EL, reviewed by CM) Ensure compatibility with Python 3.9 (pr/963) (CM)

The Brain Imaging Data Structure (BIDS) is a community-driven standard for the organization of data and metadata from a growing range of neuroscience modalities. This paper is meant as a history of how the standard has developed and grown over time. We outline the principles behind the project, the mechanisms by which it has been extended, and some of the challenges being addressed as it evolves. We also discuss the lessons learned through the project, with the aim of enabling researchers in other domains to learn from the success of BIDS.

🚀 Enhancement BF: support _ses-DATE as alternative to _ses-{date} for Siemens XA60 #848 (@yarikoptic) Allow for relative, up to 5% differences, while comparing numerics for fieldmap correspondence #842 (@yarikoptic) 🐛 Bug Fix Fix fmap rec dir ordering #855 (@octomike) 🏠 Internal gh-actions: Bump codecov/codecov-action from 5 to 6 #854 (@dependabot[bot]) gh-actions: Bump actions/checkout from 5 to 6 #841 (@dependabot[bot]) Authors: 3 @dependabot[bot] Michael (@octomike) Yaroslav Halchenko (@yarikoptic)

The Brain Imaging Data Structure (BIDS) is a specification for organizing, sharing, and archiving neuroimaging data and metadata in a reusable way. First developed for magnetic resonance imaging (MRI) datasets, the community-led specification evolved rapidly to include other modalities such as magnetoencephalography, positron emission tomography, and quantitative MRI (qMRI). In this work, we present an extension to BIDS for microscopy imaging data, along with example datasets. Microscopy-BIDS supports common imaging methods, including 2D/3D, ex/in vivo, micro-CT, and optical and electron microscopy. Microscopy-BIDS also includes comprehensible metadata definitions for hardware, image acquisition, and sample properties. This extension will facilitate future harmonization efforts in the context of multi-modal, multi-scale imaging such as the characterization of tissue microstructure with qMRI.

: We conclude that information from multiple signaling pathways must be incorporated in future forward models of the BOLD response to prevent erroneous conclusions when using fMRI as a surrogate measure for neural activity. Further, we highlight the potential of direct neuronal stimulation via genetically defined brain networks towards advancing neurophysiological understanding and better estimating effective connectivity.

Most work on NiBabel so far has been by Matthew Brett (MB), Chris Markiewicz (CM), Michael Hanke (MH), Marc-Alexandre Côté (MC), Ben Cipollini (BC), Paul McCarthy (PM), Chris Cheng (CC), Yaroslav Halchenko (YOH), Satra Ghosh (SG), Eric Larson (EL), Demian Wassermann, Stephan Gerhard and Ross Markello (RM). References like "pr/298" refer to github pull request numbers. 3.1.1 (Friday 26 June 2020) Bug-fix release in the 3.1.x series. These are small compatibility fixes that support ARM64 architecture and indexed_gzip>=1.3.0. Bug fixes Detect IndexedGzipFile as compressed file type (pr/925) (PM, reviewed by CM) Correctly cast nan when testing array_to_file, fixing ARM64 builds (pr/862) (CM, reviewed by MB)

Most work on NiBabel so far has been by Matthew Brett (MB), Chris Markiewicz (CM), Michael Hanke (MH), Marc-Alexandre Côté (MC), Ben Cipollini (BC), Paul McCarthy (PM), Chris Cheng (CC), Yaroslav Halchenko (YOH), Satra Ghosh (SG), Eric Larson (EL), Demian Wassermann, and Stephan Gerhard. References like "pr/298" refer to github pull request numbers. 3.0.1 (Monday 27 January 2020) Bug fixes Test failed by using array method on tuple. (pr/860) (Ben Darwin, reviewed by CM) Validate ExpiredDeprecationError\s, promoted by 3.0 release from DeprecationWarning\s. (pr/857) (CM) Maintenance Remove logic accommodating numpy without float16 types. (pr/866) (CM) Accommodate new numpy dtype strings. (pr/858) (CM)

The Brain Imaging Data Structure (BIDS) is a widely adopted, community-driven standard to organize neuroimaging data and metadata. Although numerous extensions have been developed to incrementally extend coverage to new modalities and data types, an unambiguous, granular specification for eye-tracking recordings is lacking. Here, we present how BIDS will structure data and metadata produced by eye-tracking devices, including gaze position and pupil data. In addition to prescribing the organization of the unprocessed (raw) recordings and associated metadata as produced by the device, BEP20 also resolves gaps in current BIDS specifications beyond the scope of eye tracking. In particular, it adds a mechanism for including asynchronous model parameters and messages, such as contextual information, statuses, and events, such as triggers, generated by the device. BEP20 includes examples that illustrate its applicability in various experimental settings. This BIDS extension provides a robust standard that supports the development of self-adaptive, open, and automated eye-tracking data structures, thereby bolstering transparency and reliability of results in this field.

Release notes Bug-fix release in the 5.3.x series. Bug fixes Fix frame order for single-frame DICOM files (pr/1387) (Brendan Moloney, reviewed by CM) Replace :class:dict literal with :class:set in test. (pr/1382) (CM) Full Changelog: https://github.com/nipy/nibabel/compare/5.3.2...5.3.3

Most work on NiBabel so far has been by Matthew Brett (MB), Chris Markiewicz (CM), Michael Hanke (MH), Marc-Alexandre Côté (MC), Ben Cipollini (BC), Paul McCarthy (PM), Chris Cheng (CC), Yaroslav Halchenko (YOH), Satra Ghosh (SG), Eric Larson (EL), Demian Wassermann, and Stephan Gerhard. References like "pr/298" refer to github pull request numbers. 3.0.2 (Monday 9 March 2020) Bug fixes Attempt to find versioneer version when building docs (pr/894) (CM) Delay import of h5py until neded (backport of pr/889) (YOH, reviewed by CM) Maintenance Fix typo in documentation (backport of pr/893) (Zvi Baratz, reviewed by CM) Set minimum matplotlib to 1.5.3 to ensure wheels are available on all supported Python versions. (backport of pr/887) (CM) Remove pyproject.toml for now. (issue/859) (CM)

Bug fix release for the 2.4.x series. Most work on NiBabel so far has been by Matthew Brett (MB), Chris Markiewicz (CM), Michael Hanke (MH), Marc-Alexandre Côté (MC), Ben Cipollini (BC), Paul McCarthy (PM), Chris Cheng (CC), Yaroslav Halchenko (YOH), Satra Ghosh (SG), Eric Larson (EL), Demian Wassermann, and Stephan Gerhard. References like "pr/298" refer to github pull request numbers. 2.4.1 (Monday 27 May 2019) Contributions from Egor Pafilov, Jath Palasubramaniam, Richard Nemec, and Dave Allured. Enhancements Enable mmap, keep_file_open options when loading any DataobjImage (pr/759) (CM, reviewed by PM) Bug fixes Ensure loaded GIFTI files expose writable data arrays (pr/750) (CM, reviewed by PM) Safer warning registry manipulation when checking for overflows (pr/753) (CM, reviewed by MB) Correctly write .annot files with duplicate lables (pr/763) (Richard Nemec with CM) Maintenance Fix typo in coordinate systems doc (pr/751) (Egor Panfilov, reviewed by CM) Replace invalid MINC1 test file with fixed file (pr/754) (Dave Allured with CM) Update Sphinx config to support recent Sphinx/numpydoc (pr/749) (CM, reviewed by PM) Pacify FutureWarning and DeprecationWarning from h5py, numpy (pr/760) (CM) Accommodate Python 3.8 deprecation of collections.MutableMapping (pr/762) (Jath Palasubramaniam, reviewed by CM) API changes and deprecations Deprecate keep_file_open == 'auto' (pr/761) (CM, reviewed by PM)

Most work on NiBabel so far has been by Matthew Brett (MB), Chris Markiewicz (CM), Michael Hanke (MH), Marc-Alexandre Côté (MC), Ben Cipollini (BC), Paul McCarthy (PM), Chris Cheng (CC), Yaroslav Halchenko (YOH), Satra Ghosh (SG), Eric Larson (EL), Demian Wassermann, Stephan Gerhard and Ross Markello (RM). References like "pr/298" refer to github pull request numbers. 3.2.0 (Tuesday 20 October 2020) New feature release in the 3.2.x series. New features nib-stats CLI tool to expose new nibabel.imagestats API. Initial implementation of volume calculations, a la fslstats -V. (pr/952) (Julian Klug, reviewed by CM and GitHub user 0rC0) nib-roi CLI tool to crop images and/or flip axes (pr/947) (CM, reviewed by Chris Cheng and Mathias Goncalves) Parser for Siemens "ASCCONV" text format (pr/896) (Brendan Moloney and MB, reviewed by CM) Enhancements Drop confusing mention of img.to_filename() in getting started guide (pr/946) (Fernando Pérez-Garcia, reviewed by MB, CM) Implement to_bytes()/from_bytes() methods for Cifti2Image (pr/938) (CM, reviewed by Mathias Goncalves) Clean up of DICOM documentation (pr/910) (Jonathan Daniel, reviewed by MB) Bug fixes Use canvas manager API to set title in OrthoSlicer3D (pr/958) (EL, reviewed by CM) Record units as seconds parrec2nii; previously set TR to seconds but retained msec units (pr/931) (CM, reviewed by MB) Reflect on-disk dimensions in NIfTI-2 view of CIFTI-2 images (pr/930) (Mathias Goncalves and CM) Fix outdated Python 2 and Sympy code in DICOM derivations (pr/911) (MB, reviewed by CM) Change string with invalid escape to raw string (pr/909) (EL, reviewed by MB) Maintenance Fix typo in docs (pr/955) (Carl Gauthier, reviewed by CM) Purge nose from nisext tests (pr/934) (Markéta Calábková, reviewed by CM) Suppress expected warnings in tests (pr/949) (CM, reviewed by Dorota Jarecka) Various cleanups and modernizations (pr/916, pr/917, pr/918, pr/919) (Jonathan Daniel, reviewed by CM) SVG logo for improved appearance in with zooming (pr/914) (Jonathan Daniel, reviewed by CM) API changes and deprecations Drop support for Numpy < 1.13 (pr/922) (CM) Warn on use of onetime.setattr_on_read, which has been a deprecated alias of auto_attr (pr/948) (CM, reviewed by Ariel Rokem)

3.1.0 (Monday 20 April 2020) New feature release in the 3.1.x series. New features Conformation function (processing.conform) and CLI tool (nib-conform) to apply shape, orientation and zooms (pr/853) (Jakub Kaczmarzyk, reviewed by CM, YOH) Affine rescaling function (affines.rescale_affine) to update dimensions and voxel sizes (pr/853) (CM, reviewed by Jakub Kaczmarzyk) Bug fixes Delay import of h5py until neded (pr/889) (YOH, reviewed by CM) Maintenance Fix typo in documentation (pr/893) (Zvi Baratz, reviewed by CM) Tests converted from nose to pytest (pr/865 + many sub-PRs) (Dorota Jarecka, Krzyzstof Gorgolewski, Roberto Guidotti, Anibal Solon, Or Duek, CM) API changes and deprecations kw_only_meth/kw_only_func decorators are deprecated (pr/848) (RM, reviewed by CM)

Most work on NiBabel so far has been by Matthew Brett (MB), Chris Markiewicz (CM), Michael Hanke (MH), Marc-Alexandre Côté (MC), Ben Cipollini (BC), Paul McCarthy (PM), Chris Cheng (CC), Yaroslav Halchenko (YOH), Satra Ghosh (SG), Eric Larson (EL), Demian Wassermann, and Stephan Gerhard. References like "pr/298" refer to github pull request numbers. 3.0.0rc1 (Saturday 16 November 2019) Release candidate for NiBabel 3.0, initiating a minimum one-month testing window. Downstream projects are requested to test against the release candidate by installing with pip install --pre nibabel. New features ArrayProxy method get_scaled() scales data with a dtype of a specified precision, promoting as necessary to avoid overflow. This is to used in img.get_fdata() to control memory usage. (pr/833) (CM, reviewed by Ross Markello) GiftiImage method agg_data() to return usable data arrays (pr/793) (Hao-Ting Wang, reviewed by CM) Accept os.PathLike objects in place of filenames (pr/610) (Cameron Riddell, reviewed by MB, CM) Function to calculate obliquity of affines (pr/815) (Oscar Esteban, reviewed by MB) Enhancements get_fdata(dtype=np.float32) will attempt to avoid casting data to np.float64 when scaling parameters would otherwise promote the data type unnecessarily. (pr/833) (CM, reviewed by Ross Markello) ArraySequence now supports a large set of Python operators to combine or update in-place. (pr/811) (MC, reviewed by Serge Koudoro, Philippe Poulin, CM, MB) Warn, rather than fail, on DICOMs with unreadable Siemens CSA tags (pr/818) (Henry Braun, reviewed by CM) Improve clarity of coordinate system tutorial (pr/823) (Egor Panfilov, reviewed by MB) Bug fixes Sliced Tractograms no longer apply_affine to the original Tractogram's streamlines. (pr/811) (MC, reviewed by Serge Koudoro, Philippe Poulin, CM, MB) Re-import externals/netcdf.py from scipy to resolve numpy deprecation (pr/821) (CM) Maintenance Support Python >=3.5.1, including Python 3.8.0 (pr/787) (CM) Manage versioning with slightly customized Versioneer (pr/786) (CM) Reference Nipy Community Code and Nibabel Developer Guidelines in GitHub community documents (pr/778) (CM, reviewed by MB) API changes and deprecations Deprecate ArraySequence.data in favor of ArraySequence.get_data(), which will return a copy. ArraySequence.data now returns a read-only view. (pr/811) (MC, reviewed by Serge Koudoro, Philippe Poulin, CM, MB) Deprecate DataobjImage.get_data() API, to be removed in nibabel 5.0 (pr/794, pr/809) (CM, reviewed by MB)

New feature release for the 2.4.x series. Most work on NiBabel so far has been by Matthew Brett (MB), Chris Markiewicz (CM), Michael Hanke (MH), Marc-Alexandre Côté (MC), Ben Cipollini (BC), Paul McCarthy (PM), Chris Cheng (CC), Yaroslav Halchenko (YOH), Satra Ghosh (SG), Eric Larson (EL), Demien Wasserman, and Stephan Gerhard. 2.4.0 (Monday 1 April 2019) New features Alternative Axis-based interface for manipulating CIFTI-2 headers (#641) (Michiel Cottaar, reviewed by Demien Wasserman, CM, SG) Enhancements Accept TCK files produced by tools with other delimiter/EOF defaults (#720) (Soichi Hayashi, reviewed by CM, MB, MC) Allow BrainModels or Parcels to contain a single vertex in CIFTI (#739) (Michiel Cottaar, reviewed by CM) Support for NIFTI_XFORM_TEMPLATE_OTHER xform code (#743) (CM) Bug fixes Skip refcheck in ArraySequence construction/extension (#719) (Ariel Rokem, reviewed by CM, MC) Use safe resizing for ArraySequence extension (#724) (CM, reviewed by MC) Fix typo in error message (#726) (Jon Haitz Legarreta Gorroño, reviewed by CM) Support DICOM slice sorting in Python 3 (#728) (Samir Reddigari, reviewed by CM) Correctly reorient dim_info when reorienting NIfTI images (#744) (Konstantinos Raktivan, CM, reviewed by CM) Maintenance Import updates to reduce upstream deprecation warnings (#711, #705, #738) (EL, YOH, reviewed by CM) Delay import of nibabel.testing, nose and mock to speed up import (#699) (CM) Increase coverage testing, drop coveralls (#722, #732) (CM) Add Zenodo metadata, sorted by commits (#732) (CM + others) Update author listing and copyrights (#742) (MB, reviewed by CM)

Agent-friendly Provenance Capture with con-duct Presenters Austin Macdonald , ORCID 0000-0002-8124-807X Cody C. Baker , ORCID 0000-0002-0829-4790 John A. Lee , ORCID 0000-0001-5884-4247 Yaroslav O. Halchenko , ORCID 0000-0003-3456-2493 All: Center for Open Neuroscience, Department of Psychological and Brain Sciences, Dartmouth College Keywords agentic workflows, provenance, reproducibility, resource monitoring, HPC Abstract Whether trying out a new tool, testing pipelines, or meticulously analyzing data for research, the daily work of RSEs and their agents depends on keeping context lean but relevant. The terminal outputs of tools and scripts frequently hold the necessary information, but they are often either bloating an agent’s context window, or forgotten after a human’s terminal scrolls past the buffer. con-duct is a lightweight, Python-based command line tool with no third-party dependencies: just use duct instead of to run a command. A wrapped run leaves a trail: full stdout and stderr streamed to disk (or skipped, for sensitive output); resource usage sampled across the command’s process tree; and a record of the invocation, wall clock time, peak memory, exit code, and system and environment details. Workflow managers and experiment trackers produce richer records (the poster compares them); con-duct collects basic provenance with so little effort it can be used on everything, producing uniform records. In daily work, humans and agents now execute commands side by side. Using con-duct, the full record stays out of the context window until it is needed. Even better, multiple runs can be filtered and grepped, ready for the questions nobody knew to ask. When did our tests start having that warning? Did this run take longer? con-duct ls makes the answers discoverable, filtering on any captured field with a Python expression: con-duct ls -e "message==' '" retrieves runs tagged at capture time with duct -m " ". con-duct ls -e "exit_code != 0" lists failures. con-duct ls -e "peak_rss > 8e9" finds runs that exceeded a memory budget. At the tool level, projects can adopt con-duct internally rather than reinventing per-tool monitoring: ReproNim’s containers [5] and ReproStim [6] both offer it already, and the same con-duct ls queries read their records. For research, the record stops being a convenience, and starts being a part of the provenance chain [4]. Pairing con-duct with datalad (git-based version control for data)[2] is an easy win for rigor. datalad run "duct ..." completes the execution and then commits the diff (including the duct logs). On HPC, last month’s measured wall time and peak memory are already recorded, and can help inform tomorrow’s SLURM request. When an expensive job fails, the bug-report evidence is already on disk, no re-run necessary to file an issue. con-duct is on PyPI (pip install con-duct), conda-forge, registered as RRID:SCR_025436, and developed openly [1]. The poster shows three real cases: an fMRIPrep run on a SLURM cluster, its five hours of CPU and memory plotted from the record; a Kubernetes upgrade worked deploy by deploy, with every attempt’s command, exit code, and wall time kept by con-duct; and duct wrapped around duct to measure its own overhead. Keeping agents’ work auditable will take more than one tool; con-duct is one small piece: a wrapper that makes the agent’s work, like the human’s, leave a trace. Acknowledgments We thank the broader ReproNim and OpenNeuro communities for ongoing feedback on con-duct’s design and use. con-duct’s resource-monitoring approach is based on brainlife’s smon [3]. AI disclosure (per IEEE policy): Prose in the Abstract and Connection-to-Mission sections was drafted with assistance from Anthropic’s Claude; the authors specified the content, edited the text, and verified all technical claims, commands, and references. The con-duct software itself is developed with AI assistance, and with human review of all merged code. References con-duct. Center for Open Neuroscience. https://github.com/con/duct. RRID:SCR_025436. DataLad. https://www.datalad.org/. RRID:SCR_003931. brainlife smon. https://github.com/brainlife/abcd-spec/blob/master/hooks/smon Hoffstaedter, F. ds000007-mriqc (duct logs in logs/duct/). https://cerebra.fz-juelich.de/f.hoffstaedter/ds000007-mriqc/src/branch/base/logs/duct/ ReproNim/containers. https://github.com/ReproNim/containers. RRID:SCR_018467. ReproStim. https://github.com/ReproNim/reprostim. https://doi.org/10.5281/zenodo.4416842 Connection to Mission, Goals, & Interests of US-RSE Community con-duct was built by RSEs at the Center for Open Neuroscience to record provenance for neuroimaging pipelines. The dev-side payoff (reaching back into outputs that would otherwise be gone) was an unexpected bonus. As LLM agents take on more of the executing (writing throwaway pipelines, exploring datasets, calling tools), the volume of unrecorded work explodes: more commands, more parallel streams, results produced faster than anyone reads them. RSEs are the people who decide whether that work remains auditable: who preserve the context, make it discoverable, and keep capture cheap enough that nobody skips the step. Integrating at the tool level saves each project from building its own monitoring and logging, and keeps the records uniform across tools, so the collection stays queryable as a whole.

Agent-friendly Provenance Capture with con-duct Presenters Austin Macdonald , ORCID 0000-0002-8124-807X Cody C. Baker , ORCID 0000-0002-0829-4790 John A. Lee , ORCID 0000-0001-5884-4247 Yaroslav O. Halchenko , ORCID 0000-0003-3456-2493 All: Center for Open Neuroscience, Department of Psychological and Brain Sciences, Dartmouth College Keywords agentic workflows, provenance, reproducibility, resource monitoring, HPC Abstract Whether trying out a new tool, testing pipelines, or meticulously analyzing data for research, the daily work of RSEs and their agents depends on keeping context lean but relevant. The terminal outputs of tools and scripts frequently hold the necessary information, but they are often either bloating an agent’s context window, or forgotten after a human’s terminal scrolls past the buffer. con-duct is a lightweight, Python-based command line tool with no third-party dependencies: just use duct instead of to run a command. A wrapped run leaves a trail: full stdout and stderr streamed to disk (or skipped, for sensitive output); resource usage sampled across the command’s process tree; and a record of the invocation, wall clock time, peak memory, exit code, and system and environment details. Workflow managers and experiment trackers produce richer records (the poster compares them); con-duct collects basic provenance with so little effort it can be used on everything, producing uniform records. In daily work, humans and agents now execute commands side by side. Using con-duct, the full record stays out of the context window until it is needed. Even better, multiple runs can be filtered and grepped, ready for the questions nobody knew to ask. When did our tests start having that warning? Did this run take longer? con-duct ls makes the answers discoverable, filtering on any captured field with a Python expression: con-duct ls -e "message==' '" retrieves runs tagged at capture time with duct -m " ". con-duct ls -e "exit_code != 0" lists failures. con-duct ls -e "peak_rss > 8e9" finds runs that exceeded a memory budget. At the tool level, projects can adopt con-duct internally rather than reinventing per-tool monitoring: ReproNim’s containers [5] and ReproStim [6] both offer it already, and the same con-duct ls queries read their records. For research, the record stops being a convenience, and starts being a part of the provenance chain [4]. Pairing con-duct with datalad (git-based version control for data)[2] is an easy win for rigor. datalad run "duct ..." completes the execution and then commits the diff (including the duct logs). On HPC, last month’s measured wall time and peak memory are already recorded, and can help inform tomorrow’s SLURM request. When an expensive job fails, the bug-report evidence is already on disk, no re-run necessary to file an issue. con-duct is on PyPI (pip install con-duct), conda-forge, registered as RRID:SCR_025436, and developed openly [1]. The poster shows three real cases: an fMRIPrep run on a SLURM cluster, its five hours of CPU and memory plotted from the record; a Kubernetes upgrade worked deploy by deploy, with every attempt’s command, exit code, and wall time kept by con-duct; and duct wrapped around duct to measure its own overhead. Keeping agents’ work auditable will take more than one tool; con-duct is one small piece: a wrapper that makes the agent’s work, like the human’s, leave a trace. Acknowledgments We thank the broader ReproNim and OpenNeuro communities for ongoing feedback on con-duct’s design and use. con-duct’s resource-monitoring approach is based on brainlife’s smon [3]. AI disclosure (per IEEE policy): Prose in the Abstract and Connection-to-Mission sections was drafted with assistance from Anthropic’s Claude; the authors specified the content, edited the text, and verified all technical claims, commands, and references. The con-duct software itself is developed with AI assistance, and with human review of all merged code. References con-duct. Center for Open Neuroscience. https://github.com/con/duct. RRID:SCR_025436. DataLad. https://www.datalad.org/. RRID:SCR_003931. brainlife smon. https://github.com/brainlife/abcd-spec/blob/master/hooks/smon Hoffstaedter, F. ds000007-mriqc (duct logs in logs/duct/). https://cerebra.fz-juelich.de/f.hoffstaedter/ds000007-mriqc/src/branch/base/logs/duct/ ReproNim/containers. https://github.com/ReproNim/containers. RRID:SCR_018467. ReproStim. https://github.com/ReproNim/reprostim. https://doi.org/10.5281/zenodo.4416842 Connection to Mission, Goals, & Interests of US-RSE Community con-duct was built by RSEs at the Center for Open Neuroscience to record provenance for neuroimaging pipelines. The dev-side payoff (reaching back into outputs that would otherwise be gone) was an unexpected bonus. As LLM agents take on more of the executing (writing throwaway pipelines, exploring datasets, calling tools), the volume of unrecorded work explodes: more commands, more parallel streams, results produced faster than anyone reads them. RSEs are the people who decide whether that work remains auditable: who preserve the context, make it discoverable, and keep capture cheap enough that nobody skips the step. Integrating at the tool level saves each project from building its own monitoring and logging, and keeps the records uniform across tools, so the collection stays queryable as a whole.

🐛 Bug Fix Aggregate events.tsv for invalid entities (and rec) (resubmitted fixed #864) #873 (@octomike @yarikoptic @claude) chore: boost flake8 and black in pre-commit for compatible to python 3.14 versions #874 (@yarikoptic) Update dcm2niix bundled in the Docker image to v1.0.20260724 #870 (@wojzwo) BF: populate SeqInfo date/time from any available DICOM date/time tags #867 (@claude @yarikoptic-gitmate) Merge branch 'bf-633' #634 (@yarikoptic) 🏠 Internal CI: run lint/typing/test once per commit, not twice #871 (@claude @yarikoptic) Migrate packaging metadata to pyproject.toml; improve metadata for container (version); convert relative links to images for pypi #868 (@claude @yarikoptic-gitmate) 📝 Documentation DOC: add minimal CLAUDE.md pointing at CONTRIBUTING.rst, and refresh CONTRIBUTING #866 (@claude @yarikoptic-gitmate) Authors: 5 @wojzwo Claude (@claude) GitMate for @yarikoptic (@yarikoptic-gitmate) Michael (@octomike) Yaroslav Halchenko (@yarikoptic)

Research software engineers routinely encounter computational analyses whose code is available but whose data, parameters, software environments, execution context, and provenance are difficult to reconstruct. This missing context makes analyses harder to review, maintain, transfer, and extend. AI-assisted tools can accelerate development, testing, and documentation, but their high output volume and nondeterministic behavior further complicate these tasks and heighten the need for explicit context and reviewable intermediate states. STAMPED (https://stamped-principles.org) defines seven properties for organizing these materials as a durable and more useful research object [1]. The framework complements the established FAIR (Findable, Accessible, Interoperable, and Reusable) principles by focusing on the organization and execution of computational research objects [7]. This poster presents our application of STAMPED to an existing analysis presented at OHBM 2025 on age-dependent bias in cortical morphometry tools using Adolescent Brain Cognitive Development (ABCD) Studydata [3]. We apply STAMPED, developed in our prior work [1] and introduced in a companion poster, to guide improvements to the research object surrounding the analysis [2]. We use AI extensively in development, testing, and documentation, making the reconstruction a practical test of the STAMPED vision for AI-assisted research. Following a review of the original analysis, we use a coordinated set of tools to improve the research object across the seven properties: Property Implementation and tools Self-containment Explicit research-object boundaries using DataLadand git-annex [4] Tracking Versioned state and provenance using Git, DataLad run records, con-duct, NIDM, and PROV [4,6] Actionability Executable interfaces using tested BIDS Apps and Pixi tasks [5] Modularity Independently versioned components composed using DataLad [4] Portability Explicit execution environments using Apptainercontainers [5] Ephemerality Fresh execution using Apptainer, BABS, and Slurm[5] Distributability Persistent git-annex remotes with separate access boundaries [4] We show how these tools work in concert to make the data, environments, operations, and results more FAIR and STAMPED. ABCD access restrictions introduce a practical tension between distributability and controlled access that we examine in applying the principles. Collectively, the decisions on how to implement the principles provide a worked example of how to use STAMPED to guide choices about research-object boundaries, provenance, execution, validation, and distribution. We report the practical details of this process: the effort and judgment required, problems encountered, tradeoffs made, evidence produced, interactions among principles and tools, and cases where satisfying one property complicates another. Although we demonstrate the approach through a scientific reproduction, it is easier and more scientifically valuable when integrated from the start of the analysis [8]. The poster invites RSEs to consider which parts apply to their own shared or domain-specific challenges.