\documentclass{article}
\usepackage[margin=1in]{geometry}
\usepackage{datetime}
\usepackage{flafter}
\usepackage{graphicx} % Required for inserting images
\usepackage{enumitem} % Required for itemize options in normative table
\usepackage{amssymb} % Required for \square symbol
\usepackage[super,sort&compress]{natbib}
\usepackage{url}  % handles special chars in URLs/DOIs in bibliography

\usepackage{xcolor} % superset of `color`; required because orcidlink pulls in tikz/xcolor
\definecolor{darkblue}{rgb}{0,0.08,0.35}
\definecolor{darkgreen}{rgb}{0,0.35,0.08}
\usepackage[backref=false,breaklinks,colorlinks,citecolor=darkblue,linkcolor=darkgreen,urlcolor=darkblue,hyperindex,plainpages=false,pdftex]{hyperref} % Hyper-references
\usepackage{orcidlink} % green ORCID iD logo next to each author (used by authors.tex)

% no hyphenation (not using microtype since issues a warning)
\tolerance=1
\emergencystretch=\maxdimen
\hyphenpenalty=10000
\hbadness=10000

% Headings with a named PDF destination. Usage:
%   \anchoredsection{intro}{Introduction}
%   \anchoredsubsection{self-containment}{Self-containment}
%   \anchoredsubsubsection{nested}{Nested thing}
% Link via file.pdf#anchor (browsers) or file.pdf#nameddest=anchor (Acrobat).
%
% \hyanchor{name} places an invisible PDF anchor at the top of the current line.
% Each wrapper forwards plain title to the heading.
% \texorpdfstring inside \hyanchor hides the anchor when building pdf strings to avoid build errors in the PDF outline.
\makeatletter
\newcommand{\hyanchor}[1]{\texorpdfstring{\Hy@raisedlink{\hypertarget{#1}{}}}{}}
\makeatother

\newcommand{\httpsurl}[1]{\href{https://#1}{#1}}
\newcommand{\ghurl}[1]{\httpsurl{github.com/#1}}

\newcommand{\anchoredsection}[2]{\section[#2]{\hyanchor{#1}#2}}
\newcommand{\anchoredsubsection}[2]{\subsection[#2]{\hyanchor{#1}#2}}
\newcommand{\anchoredsubsubsection}[2]{\subsubsection[#2]{\hyanchor{#1}#2}}

% Scientific Data: max 110 chars, no colons or parentheses, capitalize only first word + proper nouns
\title{STAMPED principles for reproducible research objects}
% Byline + affiliations are rendered from .tributors + .tributors.credit.yaml.
% Regenerate via `make authors` (renderer: code/render_authors.py).
\input{authors}
\newdateformat{monthyeardate}{\monthname[\THEMONTH] \THEYEAR}
\date{\monthyeardate\today}

\begin{document}

\maketitle

\anchoredsection{abstract}{Abstract}

Scientific claims increasingly rely upon the interplay of code, data, and computational environments.
Yet the record of how they are used together is often incomplete, scattered, or lost.
This undermines rigor, reproducibility, reusability, and efficiency.
Previous approaches have improved the governance of digital objects but do not specify how research objects ought to be structured and managed so they can be re-executed and extended.
The community is missing a shared vocabulary for this operational layer.
Building on recurrent practices and convergent patterns across disciplines, we formalize seven principles: Self-containment, Tracking, Actionability, Modularity, Portability, Ephemerality, and Distributability (STAMPED).
Together they give researchers guidelines for building and assessing research objects that others can trust, rerun, and build upon.
We frame each principle as a spectrum so that adoption is incremental and starts from existing practice.
We support each principle with normative requirements, an interactive checklist, and a map of enabling tools.
As conventions mature, tooling improves, and AI agents become increasingly involved in research workflows, the goals of rigor, reproducibility, reusability, and efficiency are becoming more attainable.
STAMPED gives researchers, collaborators, reviewers, and agents a common language, concrete goals, and an aligned direction for making computational research more durable.

\anchoredsection{introduction}{Introduction}

Data-driven research depends on specific versions of datasets, software, and computational environments, together with a record of how they were used to produce results.
We adopt the term \textbf{research object}\cite{bechhofer_why_2013,peroni_packaging_2022} to denote a collection of data, code, and metadata that together represent the research as a complete unit.
It is common for the components of a research object to be organized independently with code in one repository, data on a shared drive, environment setup in a wiki page, and provenance in a lab notebook.
This separation undermines rigor, reproducibility, reusability, and efficiency.
Even when its components are gathered in one place, a research object is often tightly coupled to specific software versions and environments which may be opaque to outside collaborators, making it difficult to reuse or redistribute.

The FAIR principles\cite{wilkinson_fair_2016} and FAIR4RS guidelines\cite{barker_introducing_2022} provide structured guidance for making digital objects ``Findable, Accessible, Interoperable, and Reusable''.
The Workflow Community Initiative (WCI-FW)\cite{wilkinson_applying_2025} mapped these principles onto computational workflows but explicitly chose not to define new ones, instead treating workflows as hybrid data \& software objects.
STAMPED addresses a complementary layer: the day-to-day practices that underpin re-execution, extension, and redistribution of a research object.
Both the FAIR and STAMPED frameworks cover overlapping concerns.
For example, persistent identifiers serve both Findability and Tracking but accent different aspects.
FAIR emphasizes discovery and interoperability across repositories, while STAMPED emphasizes improving the operational maturity of scientific workflows in day-to-day research practice.

Many researchers already employ practices that address these operational properties, such as version control, containerized environments, structured project directories, and documented analysis steps.
Yet the community lacks a shared vocabulary for referring to these ideas, evaluating how thoroughly they are applied, and communicating that evaluation to collaborators and reviewers.
Here we provide that vocabulary~(Figure~\ref{fig:stamped}) by introducing seven principles which articulate how Self-contained, Tracked, Actionable, Modular, Portable, Ephemeral, and Distributable (STAMPED) a research object is, thus describing its operational maturity.
These originate from both the YODA principles\cite{hanke_yoda_2018} and VAMP\cite{hanke_what_2023}.
Rather than a compliance threshold, each STAMPED principle is a spectrum from a practical minimum---often what researchers are already doing---to an aspirational ideal.
A researcher who stores everything under one project directory, version-controls analysis scripts, and documents how to run them is already meeting the practical minimum for Self-containment, Tracking, and Actionability.
As complexity grows, such as for multi-institutional collaborations with heterogeneous workflows spanning platforms enforcing long-term reproducibility, these same principles guide researchers toward more rigorous practices without requiring wholesale adoption of new tools.
STAMPED provides a descriptive vocabulary and a framework for evaluation that can incrementally improve the operational properties of research objects towards enhanced rigor, reproducibility, reusability, transparency, and efficiency.


\begin{figure}[htbp]
\centering
\includegraphics[width=\textwidth]{figures/fig1.pdf}
\caption{Illustration of the STAMPED principles.}
\label{fig:stamped}
\end{figure}



\anchoredsection{principles}{The STAMPED principles}

\begin{table}[htbp]
\centering
\caption{The STAMPED principles where each one addresses a distinct property of research object organization that contributes to reproducibility. Together, they provide a framework for evaluating and improving the reproducibility of computational research.}
\label{tab:stamped}
\begin{tabular}{c l p{0.65\textwidth}}
\hline
\textbf{Letter} & \textbf{Principle} & \textbf{Description} \\
\hline
S & Self-containment & A research object is a complete unit that can be obtained and understood in its intended scope; components are included directly or by persistent references that are themselves part of the object. \\
T & Tracking & The state and provenance of all components is recorded. \\
A & Actionability & A research object contains sufficient instructions to obtain or reproduce its content, ideally as executable specifications. \\
M & Modularity & All modules are independent and composable. \\
P & Portability & A research object could be moved to different environments while retaining its STAMPED properties. \\
E & Ephemerality & Procedural execution is performed within a throwaway environment. \\
D & Distributability & All modules and procedures are shareable externally in a persistent state. \\
\hline
\end{tabular}
\end{table}

The formal requirements use the graded keywords of RFC~2119\cite{bradner_key_1997}: MUST defines the practical minimum, while SHOULD and MAY indicate progressively more aspirational practices.



\anchoredsubsection{self-containment}{Self-containment}

\begin{itemize}
    \item \textbf{S.1}: All modules and components essential to replicate computational execution MUST be reachable within a single top-level research object.
    \item \textbf{S.2}: License declarations for all components are themselves part of the research object and MUST be retrievable alongside the content they govern.
\end{itemize}

Reproducibility fails when a research object depends on resources that are not part of it; an undocumented library, a dataset referenced by a broken URL, a script that assumes tools are installed on the host system.
We call this the ``don't look up'' rule: a research object must never rely on any implicit external state.
Instead, it must be a complete unit, where all modules and components essential to reproduce its results are contained within a single top-level boundary (S.1, Table~1).

Components may be included literally (e.g., files committed directly) or by reference (e.g., as subdatasets, registered data URLs).
Both approaches satisfy self-containment, provided the references are explicit and part of the research object.
At a minimum, everything needed is gathered under one root and any external dependency is explicitly documented.
This ensures that nothing is implicitly assumed about the host system, a concern further addressed by Portability~(P).
At the ideal end, every reference is precise enough that retrieval is unambiguous; how to achieve that precision is the concern of Tracking~(T) and Distributability~(D).

Self-containment is the foundation upon which the remaining STAMPED principles are built.
Tracking~(T), Modularity~(M), Portability~(P), and Distributability~(D) each address a different aspect of how that boundary is organized, versioned, and shared---but none are meaningful without first establishing what is inside it.



\anchoredsubsection{tracking}{Tracking}

\begin{itemize}
    \item \textbf{T.1}: Persistent content identification MUST be recorded for all components.
    \item \textbf{T.2}: All components SHOULD be tracked using the same content-addressed version control system.
    \item \textbf{T.3}: Provenance of all modifications MUST be recorded.
    \item \textbf{T.4}: Code-driven provenance SHOULD be recorded programmatically and MUST include the versions of all components involved.
\end{itemize}

Research data and code change constantly during a project, and each change compounds the difficulty of reconstructing any previous state, such as which version of a dataset was used for a particular analysis, what parameters were set, and what code produced a given figure.
A Self-contained~(S) research object gathers everything needed in one place, but without a record of how each component arrived at its current state, reproducing a prior result becomes guesswork.
Tracking addresses two concerns: 1) the identity of each component and its exact state at a point in time, and 2) \textbf{provenance}, the recorded history of the actions by which identities produced or modified it.
These are often managed separately, which makes validating past work harder.

The spectrum of tracking begins with content-addressed version control.
Rather than relying on semantic version labels, content-addressed systems identify each state by a checksum of its contents.
This distinction matters; two datasets labeled ``version 1.0'' by different labs are ambiguous whereas two datasets with identical content hashes are provably identical.
Version control commits also capture basic provenance of who made the change, when, and a description of why.
Cryptographic signatures (e.g., signed git commits and tags, sigstore-signed releases) strengthen these records from self-reported to verifiable, allowing recipients to confirm that components and changes originate from the claimed identities.
This unifies identity and provenance in a single system and also provides a safety net since any change can be reverted and any prior state restored, making it easier to modify and experiment.
For tracking to be effective, all components of the research object must be under version control: code, data, environment definitions, and configuration.

Traditional version control is designed for code and other text files, but research objects often include large binary datasets, container images, and other assets that do not fit this model.
Compatible tools such as git-annex, DataLad\cite{halchenko_datalad_2021}, or DVC\cite{ruslan_kuprieiev_dvc_2026} extend content-addressed tracking to these components, ensuring that all parts of the research object are managed under the same system.

Toward the ideal end, provenance is captured programmatically by tooling rather than by manual annotation.
Each computational step should record exactly what command was executed and what inputs were consumed, producing richer and more reliable records than a human would typically write.
When modules are independently tracked under compatible systems, the version of every module at the time of each commit is also discoverable, providing a complete picture of the state that produced a given result.
This enables inspection and provides a foundation for re-execution.
Beyond the research object itself, knowing the state of data and code at each hand-off between experimental, analytical, and engineering stages is what allows a team to coordinate updates without losing the provenance chain---an operational view of tracking developed by the SciOps framework\cite{johnson_sciops_2024}.
Across communities, multiple ontologies and packaging standards have emerged to make these provenance records portable across tools, including cross-domain models such as W3C~PROV\cite{w3c_provenance_working_group_prov-overview_2013}, packaging formats such as RO-Crate\cite{peroni_packaging_2022}, and domain-specific specifications such as BIDS-Prov (BEP028)\cite{bids_community_bep028_2025}.
The relationships among such provenance, assertion, and evidence ontologies have been surveyed recently\cite{chhetri_bridging_2025}, highlighting a rich existing ecosystem that deserves promotion and wider adoption to improve tracking of scientific processes.


\anchoredsubsection{actionability}{Actionability}

\begin{itemize}
    \item \textbf{A.1}: Research object MUST contain sufficient instructions to reproduce all computational results.
    \item \textbf{A.2}: Procedures SHOULD be expressed as executable specifications.
\end{itemize}

A research object may be Self-contained~(S) and fully Tracked~(T), yet having all ingredients and a record of what was done is insufficient without a recipe that can be followed.
Requirement A.1 is what makes a research object operationally useful by bridging the gap between having the components and being able to use them.

At a minimum, a research object must contain documentation thorough enough for another researcher to follow every step to reproduce results.
Actionability applies to every other STAMPED principle.
At the ideal end, each principle is enacted not through documentation alone but through executable specifications (A.2):
\begin{itemize}
  \item \textbf{Self-containment} is more actionable when retrieval of all components is specified and executable (e.g., \texttt{git clone}, \texttt{datalad install}), not just listed in a manifest.
  \item \textbf{Tracking} is more actionable when provenance records are re-executable (e.g., \texttt{datalad rerun}), not just inspectable.
  \item \textbf{Modularity} is more actionable when components can be composed, updated, and replaced via tooling (e.g., \texttt{git submodule}), not just organized into directories.
  \item \textbf{Portability} is more actionable when environment specifications are machine-readable and can be resolved on different hosts (e.g., \texttt{conda env create}, Nix flakes), not just documented in a README.
  \item \textbf{Ephemerality} is more actionable when computation can be programmatically orchestrated in disposable environments (e.g., \texttt{docker compose}, Slurm), not just instructed to ``run in a clean environment.''
  \item \textbf{Distributability} is more actionable when a frozen state can be produced and retrieved by others (e.g., containers, \texttt{npm ci}), not just described with pinning instructions.
\end{itemize}
The principle is tool-agnostic; any system that moves a property from documented to executable moves the research object further along the actionability spectrum.
Actionability also extends from tooling to the operational layer of a research group.
A SciOps-style workflow makes hand-offs between experimental, analytical, and engineering stages explicit so that artifacts move from one step to the next with unambiguous state transition\cite{johnson_sciops_2024}, an organizational counterpart to the per-component actionability described above.



\anchoredsubsection{modularity}{Modularity}

\begin{itemize}
    \item \textbf{M.1}: Components SHOULD be organized in a modular structure.
    \item \textbf{M.2}: Components MAY be included directly or linked as subdatasets.
    \item \textbf{M.3}: Each module's license SHOULD be declared independently and checked for compatibility at the boundaries where modules are combined.
    \item \textbf{M.4}: Components governed by different access requirements SHOULD be isolated in separate modules where practical.
\end{itemize}

A research object may be Self-contained~(S) and Tracked~(T), yet when all components are interleaved in a single monolithic directory, it can be fragile and difficult to navigate.
Separation of concerns is a foundational engineering practice; clear boundaries keep the system navigable and maintainable.
We define a \textbf{module} as a separable unit of a research object.
This can include a subdataset, a collection of analysis scripts, or the definition for some computational environment.
In practice, module boundaries often align with repository boundaries, but a module may also be a published container, a registered dataset, or any independently versioned unit.
Modularity applies this principle to research objects, structuring them as assemblies with clear module boundaries.
Module boundaries are also where license compatibility must be checked, since combining modules with incompatible terms can prevent the assembled research object from being lawfully redistributed.
In addition to licenses, data use agreements and other legal, ethical, institutional, or technical constraints may impose different conditions on access and redistribution across a research object.
For example, the U.S. Census Bureau releases disclosure-protected public-use data while reserving detailed microdata for secure research environments \citep{united_states_census_bureau_dissemination_2025}; GBIF guidance similarly recommends publishing generalized species locations while providing precise coordinates only under agreement \citep{chapman_current_2020}.
These conditions can be managed through separate modules, including privacy-preserving derivatives.
Accounting for them during design is consistent with FAIR Accessibility, which accommodates controlled access.

At a minimum, a research object should separate analysis code, input datasets, computational environments, licenses, configuration settings, and results into distinct directories.
Beyond this, independent versioning of modules enables reuse; a dataset or environment can be updated to a newer version, or swapped for an alternative, without disrupting the rest of the research object.
This is possible through manual management but becomes practical when handled by tooling that automates module installation, versioning, and composition.
Toward the ideal end, the full research object can be reassembled from its specification through automated, recursive installation of its modules.



\anchoredsubsection{portability}{Portability}

\begin{itemize}
    \item \textbf{P.1}: Procedures MUST NOT depend on any undocumented host environment state.
    \item \textbf{P.2}: Computational environments MUST be explicitly specified.
    \item \textbf{P.3}: Environment definitions MUST be version controlled.
\end{itemize}

A research object that is Self-contained~(S), Tracked~(T), and Modular~(M) may still fail to run on a different machine if it is silently affected by any inherited host state.
Common examples of such states include untracked package dependencies, hardcoded system paths, or assumed OS configurations (e.g., path character limits).
This coupling is often invisible on the original system and only surfaces when someone else attempts to reproduce the work.
Portability requires making all host dependencies explicit, so that the research object can be adapted to a new environment.

Some degree of coupling to the host is often unavoidable, such as path naming restrictions (``C:/'' vs. ``/mnt''), resource limits (minimum CPU/RAM requirements), or platform-specific flags.
The spectrum of portability begins with isolating this host-specific configuration from the rest of the research object, so that adapting to a new environment, however involved that may be, requires only changing the configuration.
Beyond this, several complementary approaches reduce host coupling.
Virtual machines provide full system-level isolation; container-based tools (Docker, Singularity/Apptainer) bundle OS-level environments; declarative package managers (Nix\cite{kowalewski_sustainable_2022}, Guix\cite{courtes_reproducible_2015}) specify environments that can be reconstructed from a definition.
Toward the ideal end, the computational environment is fully specified and version-controlled within the research object, enabling it to be instantiated on any compatible system.



\anchoredsubsection{ephemerality}{Ephemerality}

\begin{itemize}
    \item \textbf{E.1}: Computational results SHOULD be produced in ephemeral environments.
\end{itemize}

A research object may satisfy Self-containment~(S), Tracking~(T), and Portability~(P) while its computational environment has only ever been assembled once, incrementally, on the original researcher's machine.
During development, researchers routinely modify their environment by installing packages, adjusting configurations, and setting variables.
Each change is individually small but collectively difficult to document manually.
The result is environment drift, where an environment works but may not be reconstructable from its specification alone.
When this occurs, undocumented steps can go unnoticed when internalized knowledge silently fills the gaps.
Ephemerality eliminates this problem by construction; a disposable environment built from Tracked~(T) specifications cannot carry any undocumented state, so that successful execution exercises Self-containment~(S), Actionability~(A), and specification completeness.

The spectrum of ephemerality ranges from manually setting up a fresh environment from the project's specification (which is usually sufficient to catch environment drift) to fully automated disposable environments created and destroyed per execution.
At the ideal end, ephemeral computation also enables testing across different host systems, where same-host execution validates specification completeness and different-host execution validates that specifications are not coupled to a specific system.
The FAIRly big workflow\cite{wagner_fairly_2022} and other approaches to using distributed computing platforms such as Slurm or Code Ocean\cite{cheifet_promoting_2021} operationalize this ideal, treating each computation as an ephemeral work unit.
This approach easily enables horizontal scaling, as independent disposable instances can be parallelized across subjects, parameters, or datasets.

Yet ephemeral computation does not validate everything.
For instance, an ephemeral environment with network access may fail to notice unpinned dependencies fetched at build time, a Self-containment~(S) gap that only surfaces when those resources move or disappear.
Nonetheless, the principle substantially raises confidence that the research object is Self-contained~(S), Portable~(P), and Actionable~(A).



\anchoredsubsection{distributability}{Distributability}

\begin{itemize}
    \item \textbf{D.1}: All referenced modules and components MUST be persistently retrievable by others.
    \item \textbf{D.2}: Environment specifications SHOULD support reproducible builds.
    \item \textbf{D.3}: Each module SHOULD carry an explicit license with a resolvable identifier.
\end{itemize}

A research object that is Self-contained~(S) on the author's machine but cannot be obtained by others in the same state is effectively unreproducible beyond its origin.
Self-containment~(S) establishes that everything needed is within the boundary and Tracking~(T) records the state of each component.
Distributability ensures that others can obtain the research object in that same state.

The distinction mirrors the concept of a software distribution: a curated, versioned bundle in which all components are resolved to specific versions and packaged for consumption.
Simply sharing a research object by uploading scripts to a repository with loose dependencies, or posting files on a website with no version or other persistence guarantees, does not constitute distribution in this sense.
A distributable research object is packaged so that it can be retrieved in the same state as intended.

Distributability also bootstraps new research objects; researchers frequently begin by Modularly~(M) composing the distributions of others into their own Self-contained~(S) research objects, downloading containers, fetching published datasets, and installing released software.
Persistent retrievability alone does not make a research object redistributable: each module should also carry an easily identifiable license or set of licenses for any bundled assets (e.g., via SPDX identifiers\cite{stewart_software_2010} or the REUSE specification\cite{free_software_foundation_europe_reuse_2024}) so that downstream researchers can compose, modify, and re-share components without legal ambiguity.

Distributability~(D) intersects with FAIR Accessibility, which establishes that an identified component can be retrieved through a documented protocol, including authentication or authorization where required.
Distributability extends this concern to the research object as a whole: its referenced components remain obtainable in their intended versions as a coherent distribution.
Toward the ideal end, several complementary strategies reduce the risk that external changes will break a research object's reproducibility.
Bundling dependencies into containers or archives reduces the surface area of components that can independently change or disappear; hosting on archival infrastructure (Zenodo, DANDI, Software Heritage) with content-addressed identifiers allows recipients to verify integrity regardless of source; mirroring across multiple platforms protects against the failure of any single registry.
Where downstream consumers must verify not only integrity but also origin and build process, signed releases and supply-chain attestations (e.g., sigstore, in-toto, SLSA) provide cryptographic evidence that an artifact was produced by the claimed identity from the claimed sources.
This becomes important when distributed artifacts will execute in environments enforcing code-signing policies, such as notarization or signed container admission.

\begin{table}[htbp]
\centering
\caption{Normative statements about STAMPED principles as they apply to research objects.}
\begin{tabular}{|l|p{0.7\textwidth}|}
\hline
\textbf{Principle} & \textbf{Requirements} \\
\hline
\textbf{To be Self-contained:} &
\begin{itemize}[noitemsep,topsep=0pt,leftmargin=*]
  \item all modules and components needed to understand and execute the Research Object are retrievable as a single unit
  \item external dependencies are explicitly documented with retrieval instructions
  \item there are no implicit references to undocumented external resources
\end{itemize} \\
\hline
\textbf{To be Tracked:} &
\begin{itemize}[noitemsep,topsep=0pt,leftmargin=*]
  \item every component has version information (commit hash, tag, or identifier)
  \item changes to components are recorded with timestamps and authorship
  \item provenance records capture the computational history, context, and transformations
\end{itemize} \\
\hline
\textbf{To be Actionable:} &
\begin{itemize}[noitemsep,topsep=0pt,leftmargin=*]
  \item instructions for executing procedures are present and unambiguous
  \item execution paths can be followed manually or automated programmatically
  \item the Research Object transitions from documentation to operational capability
\end{itemize} \\
\hline
\textbf{To be Modular:} &
\begin{itemize}[noitemsep,topsep=0pt,leftmargin=*]
  \item modules can be independently Tracked~(T), modified, and Distributed~(D)
  \item components are organized in logical, separable units
  \item modules can be composed together or used in isolation
\end{itemize} \\
\hline
\textbf{To be Portable:} &
\begin{itemize}[noitemsep,topsep=0pt,leftmargin=*]
  \item system requirements and dependencies are explicitly documented
  \item the Research Object executes on different host environments without modification beyond its host-specific configuration
  \item environment specifications are machine-readable where possible
\end{itemize} \\
\hline
\textbf{To be Ephemeral:} &
\begin{itemize}[noitemsep,topsep=0pt,leftmargin=*]
  \item computation can occur in temporary, disposable environments
  \item results are reproducible without knowledge of previous runs
  \item the environment is rebuilt from its specification before each execution, ensuring no reliance on undocumented state
\end{itemize} \\
\hline
\textbf{To be Distributable:} &
\begin{itemize}[noitemsep,topsep=0pt,leftmargin=*]
  \item all modules and components can be shared in a persistent, retrievable state
  \item dependencies are frozen or pinned to specific versions across systems
  \item the Research Object can be obtained by others in the same state as intended
\end{itemize} \\
\hline
\end{tabular}
\label{tab:stamped-principles}
\end{table}





\anchoredsubsection{checklist}{Checklist for compliance to principles}

We hope that the preceding sections have provided a clear understanding of the STAMPED principles and their rationale.
While this understanding is essential, researchers may also benefit from a practical checklist to assess their research objects against these principles.
Similar to the living examples repository, an interactive checklist has been provided at the \httpsurl{checklist.stamped-principles.org} webpage (see~Figure~\ref{fig:stamped-checklist-screenshot}) to guide assessments of compliance with STAMPED principles, ordered by the strength of the requirement (MUST, SHOULD, MAY).
The schema for this checklist is itself a living, version-tracked entity\cite{cody_baker_stamped-principlesstamped-checklist-schema_2026} that is likely to grow over time as more common violations of the principles are discovered in practice.

\begin{figure}[htbp]
\centering
\includegraphics[width=\textwidth]{figures/checklist-figure.pdf}
\caption{Screenshot of the interactive checklist for helping guide a workflow developer through common cases.}
\label{fig:stamped-checklist-screenshot}
\end{figure}





\anchoredsubsection{enabling-tools}{Enabling tools}

No single tool addresses all the dimensions of scientific rigor described above, though many tools contribute to one or several properties simultaneously.
For example, container technologies such as Docker or Singularity serve Portability~(P) by providing OS-level isolation from explicit environment specifications, enable Ephemerality~(E) by disposing per-execution environments, and facilitate Distributability~(D) by producing frozen, shareable artifacts.
Similarly, version control systems such as Git underpin both Tracking (content-addressed identification and change history) and Self-containment (gathering all components under a single root).

In practice, Self-containing~(S) all data by storing it directly within the research object may be undesired or prohibitive due to size, licensing, or privacy concerns.
This creates a tension with Tracking~(T), which requires that every component be identified and versioned.
Tools such as git-annex, DataLad, DVC, and Git LFS strike the balance between the two principles by tracking metadata that identifies specific data versions and obtainability information instead, e.g., content checksums and URLs of remote servers that act as a source, and providing Actionable~(A) interfaces to obtain the data when necessary.

This overlap is not incidental --- it reflects the interdependence of the STAMPED principles themselves.
Achieving Ephemerality~(E), for instance, inherently exercises Portability~(P) and Actionability~(A); a disposable environment must be reconstituted from explicit specifications, encouraging end-to-end automation.
Likewise, Distributability~(D) builds on Self-containment~(S) and Tracking~(T); a research object can only be shared in a consistent, retrievable state if its boundary is well-defined and all components are precisely identified.
The tools that enhance multiple properties of a research object do so precisely because they operationalize these connections.
Table~\ref{tab:stamped-tools} maps some commonly used tools and technologies to each STAMPED principle.

STAMPED principles are tool-agnostic.
A well-chosen tool can improve several properties at once, and a thoughtfully assembled toolchain can cover all of them.
Researchers should select tools based on their domain, infrastructure, and team familiarity, recognizing that the tools listed here are illustrative rather than prescriptive.
What matters is that the underlying property is satisfied, regardless of which tool achieves it.
Where multiple tools enhance the same STAMPED property of an object, the choice between them often involves trade-offs between flexibility and simplicity.

A representative example is the choice between git-annex and Git LFS for large-file tracking.
Both appear under Self-containment~(S) and Tracking~(T) in Table~\ref{tab:stamped-tools}, but they occupy different points on a complexity-flexibility spectrum.
git-annex supports many remote types (e.g., other git repositories over SSH or HTTP, or simple cloud data stores such as S3, local drives, offline USB archives), making it well-suited to multi-institutional collaboration, long-term archival where data sovereignty or offline access is required, as well as local content tracking.
Git LFS offers a simpler alternative; it is transparent to users, natively supported by GitHub and GitLab, and broadly adopted.
But it is centralized (requiring an LFS server), lacks offline capability, and provides less flexible remote configurations.
Lightweight STAMPED implementations using Git LFS are entirely feasible for easier onboarding, trading flexibility for reduced operational overhead.
The same pattern of flexibility versus simplicity recurs across other tool choices in Table~\ref{tab:stamped-tools}: container-based versus package-based environment management, workflow engines versus shell scripts, and distributed archives versus centralized platforms.

\begin{table}[htbp]
\centering
\caption{Sample tools to improve scientific practice for each STAMPED principle.}
\label{tab:stamped-tools}
\begin{tabular}{|l|p{0.3\textwidth}|p{0.35\textwidth}|}
\hline
\textbf{Principle} & \textbf{Tools / Technologies} & \textbf{Role} \\
\hline
\textbf{Self-containment~(S)} &
Git submodules, DataLad, git-annex, DVC, Git LFS &
Gather all components (code, data, environments) under a single root via direct inclusion or explicit references (e.g., subdatasets, registered URLs) \\
\hline
\textbf{Tracking~(T)} &
Git, git-annex, DataLad, DVC, Docker and other containers, Kedro, Git LFS, OSF.io, Zenodo and other data archives providing DOIs &
Version control for code and data; content-addressed identification; provenance recording (e.g., \texttt{datalad run} for programmatic provenance capture); persistent identifiers for content (DOIs) \\
\hline
\textbf{Actionability~(A)} &
Make, Snakemake, Nextflow, CWL, \texttt{datalad run}, \texttt{git annex addcomputed} &
Define executable specifications for workflows; provide clear entry points for reproducing results \\
\hline
\textbf{Modularity~(M)} &
Git submodules, DataLad subdatasets, Kedro &
Organize components into independently versioned, composable modules; provide project templates with logical directory separation \\
\hline
\textbf{Portability~(P)} &
Docker, Singularity, Nix, \texttt{conda}, \texttt{pip} (\texttt{pyproject.toml}, \texttt{requirements.txt}), \texttt{npm} &
Explicitly specify and isolate computational environments; container-based (OS-level isolation) or package-based (declarative, reproducible builds) \\
\hline
\textbf{Ephemerality~(E)} &
Docker, Singularity, Docker Compose, Slurm, cloud deployments (e.g., AWS, GCP, Azure, GitHub Actions) &
Spawn disposable, temporary environments per execution; validate that specifications are complete by reconstituting from scratch \\
\hline
\textbf{Distributability~(D)} &
Zenodo, PyPI, conda-forge, GitHub Release CDN, DockerHub/GHCR, RO-Crate, \texttt{npm ci}, \texttt{pip freeze}, executable compilers &
Archive and persistently host frozen, versioned research objects and their components; enable retrieval by others in the intended state \\
\hline
\end{tabular}
\end{table}



\anchoredsubsection{examples}{Examples and case studies}

\anchoredsubsubsection{pedagogical-examples}{Pedagogical examples}

A comprehensive up-to-date review of existing tools is out of scope for this formalization paper and would quickly become outdated.
To fill that niche, we initiated a satellite project \texttt{stamped-examples}\citep{yaroslav_halchenko_stamped-principlesstamped-examples_2026} with a website to describe tools and examples, and characterize them in terms of STAMPED and FAIR principles at the \httpsurl{examples.stamped-principles.org} website.
These complement the formal definitions and walk a reader through the STAMPED properties using concrete examples.
The pages tagged ``STAMPED-intro'' (\httpsurl{examples.stamped-principles.org/tags/stamped-intro/}) trace how each property applies to the same simple research object, providing a gentle on-ramp before the real-world adoptions below.

\anchoredsubsubsection{real-world-adoptions}{Real-world adoptions}

Several research projects have already adopted and documented the YODA principles (the predecessor to STAMPED), demonstrating practical utility across domains.

\textbf{BIDS Standard Evolution}: A significant validation of the ``don't look up'' rule occurred within the Brain Imaging Data Structure (BIDS)\cite{gorgolewski_brain_2016} community.
Originally, the BIDS specification nested derived data under \texttt{derivatives/} within the original raw dataset, creating upward dependencies that violated Self-containment~(S) and Modularity~(M), which broke Portability~(P).
Following YODA principles, the BIDS community reversed this relationship so that derivative datasets now exist independently and reference raw data as subdatasets, not vice versa.

This architectural shift influenced major neuroimaging tools:
\begin{itemize}
    \item \textbf{fMRIPrep}\cite{esteban_analysis_2020}: Switched default output layout to follow YODA structure
    % TODO: add GitHub issue reference for "yoda" layout proposal
    \item \textbf{OpenNeuroDerivatives}\cite{markiewicz_openneuro_2021}: Entire derivative dataset collection now follows YODA organization, separating processed outputs from raw data dependencies
    \item \textbf{BIDS specification}: Updated to accommodate and recommend YODA-compliant layouts for derivative datasets
\end{itemize}

\textbf{Workflow Platforms}: Infrastructure projects implementing YODA at scale:
\begin{itemize}
    \item \textbf{BABS}\cite{zhao_reproducible_2024}: Platform implementing the ``FAIRly big workflow'' approach, demonstrating YODA principles for large-scale neuroimaging analyses with containerized pipelines and modular dataset composition
    \item \textbf{CRCNS.org}: Neuroscience data sharing platform providing YODA-structured templates and validation tools
\end{itemize}

These adoptions demonstrate that STAMPED principles solve practical organizational challenges across scales, from individual studies to community-wide infrastructure.

\anchoredsubsection{convergent-evolution}{Convergent evolution of data-driven scientific practices}

The challenges that motivate STAMPED are not unique to any single domain.

Fragmented provenance, irreproducible computations, and ad-hoc project layouts have plagued communities across geophysics, genomics, neuroimaging, statistics, and machine learning for three decades.
Independently, each converged on strikingly similar organizational responses.
What follows is not a comprehensive review but a tracing of that convergence, organized chronologically, to show that the principles STAMPED formalizes reflect durable responses to recurring challenges.

The earliest calls for reproducibility-as-organization appeared in the 1990s.
Claerbout and Karrenbach\cite{claerbout_electronic_1992} demonstrated that coupling electronic documents with Makefiles could make geophysical analyses self-contained, tracked, and re-executable---anticipating Self-containment~(S), Tracking~(T), and Actionability~(A).
Buckheit and Donoho\cite{bickel_wavelab_1995} extended this idea with WaveLab, a compendium packaging code, data, and figures so that ``an article \ldots{} is not the scholarship itself, \ldots{} the actual scholarship is the complete software development environment and the complete set of instructions which generated the figures''---touching Self-containment~(S), Actionability~(A), Portability~(P), and Distributability~(D).
Gentleman and Temple~Lang\cite{gentleman_statistical_2007} formalized the research compendium concept, emphasizing modular packaging for reuse and redistribution---Self-containment~(S), Modularity~(M), Actionability~(A), and Distributability~(D).
Noble\cite{noble_quick_2009} provided the first widely adopted project-organization guide for computational biology, offering concrete directory-structure conventions that addressed Self-containment~(S) and Modularity~(M).

A wave of normative frameworks followed in the 2010s.
Stodden\cite{stodden_scientific_2010} articulated legal and social dimensions of sharing computational research, raising concerns central to Distributability~(D) and Tracking~(T).
Sandve et~al.\cite{sandve_ten_2013} distilled ten rules for reproducible computation (track versions, record workflows, archive environments)---spanning Tracking~(T), Actionability~(A), and Self-containment~(S).
The FAIR principles\cite{wilkinson_fair_2016} established findability, accessibility, interoperability, and reusability as community norms for digital objects, later extended to research software by FAIR4RS\cite{barker_introducing_2022} and to workflows by the Workflow Community Initiative\cite{wilkinson_applying_2025}.
Wilson et~al.\cite{wilson_good_2017} codified ``Good Enough Practices'' that operationalized many of these ideals for working scientists---Actionability~(A), Tracking~(T), and Self-containment~(S).
The YODA principles\cite{hanke_yoda_2018} combined these insights into organizational practices for research data management.
De~Smedt et~al.\cite{de_smedt_fair_2020} articulated the notion of FAIR Digital Objects as ``actionable knowledge units,'' foregrounding Actionability~(A) as a first-class concern complementary to FAIR.
Building on YODA and this emphasis on actionability, the VAMP formulation\cite{hanke_what_2023} (Versioned, Actionable, Modular, Portable) made Actionability~(A), Portability~(P), and Modularity~(M) explicit organizational requirements, and introduced Ephemerality~(E) as validation for Portability~(P)---directly prefiguring STAMPED.
Notably, the WCI-FW framework\cite{wilkinson_applying_2025} extended FAIR to computational workflows but explicitly declined to define new principles, leaving the operational gap  that STAMPED fills (how a research object should be structured and managed).

Independent of these normative efforts, a parallel ``Git for data'' convergence occurred in tooling.
git-annex (2010), Git~LFS (2015), DVC (2017), Pachyderm (2014), and Icechunk\cite{abernathey_icechunk_2024} (2024) all independently arrived at content-addressed identification of large files, logical separation of metadata from bulk storage, and derivation records linking inputs to outputs.
These systems vary widely in architecture, ranging from cloud-native to local-first and from centralized to distributed.
Despite these differences, each converged on the same core insight, that version-control semantics proven for code could and should extend to data.
This convergence is evidence not of influence but of shared need, and maps most directly onto Tracking~(T).

A complementary convergence emerged in platforms and metadata standards.
Though not an exhaustive list: Galaxy\cite{afgan_galaxy_2018} (first released 2005), Code~Ocean\cite{cheifet_promoting_2021} (2017), and brainlife.io\cite{hayashi_brainlifeio_2024} each provided turnkey reproducibility services, each implementing separation of code, data, and environment as a first-class abstraction---reflecting Self-containment~(S), Actionability~(A), and Portability~(P).
On the standards side, the W3C~PROV data model (2013), Frictionless Data\cite{fowler_frictionless_2018} (2007), RO-Crate\cite{peroni_packaging_2022}, and BioComputeObject\cite{ferrer_biocompute_2017} (IEEE~2791-2020, \httpsurl{biocomputeobject.org}) each addressed interoperable packaging and provenance recording.
The facts that FAIR required elaboration to accommodate software\cite{barker_introducing_2022} and workflows\cite{goble_fair_2020,wilkinson_applying_2025}, and that independent standards converged on provenance and packaging, confirm that these dimensions are recurrently demanded by research practice.

Preregistration is the practice of committing to a study plan before outcomes are observed, which extends Tracking~(T) to the intent behind a study.
It was established in clinical trials by the early 2000s and gradually expanded into behavioral, social, and computational research\cite{nosek_preregistration_2018}.
The Open Science Framework\cite{foster_open_2017} (2013) combined that practice with a ``hub'' for collaboration and storage, producing read-only snapshots of a study's plan, data, code, and manuscripts under a single DOI, reflecting Self-containment~(S) and Distributability~(D).
In some cases, pre-registration can also be considered a precursor to the Ephemerality~(E) of the actual scientific pipeline where work is concentrated on formulating hypotheses, planning, and potentially simulations, thus making actual later implementation of it replaceable.

Framework tooling and domain standards reveal the same pattern at the project-layout level.
Cookiecutter Data Science (2016), BIDS\cite{gorgolewski_brain_2016} (2016), Kedro (2019), nipoppy\cite{wang_open_2026} (2023), and others, all imposed opinionated directory structures and modular separation (independently motivated by the costs of ad-hoc layouts)---reflecting Modularity~(M) and Self-containment~(S).
Each framework constrains where code and documentation reside, how raw data inputs and derived outputs are handled, which makes such projects navigable by \emph{convention}.

Viewed together, these independent lines of development map onto every STAMPED principle.
Self-containment~(S) appears wherever projects bundle their dependencies into a single rooted structure;
Tracking~(T) wherever content-addressed storage or version control records the history of changes or acquisition of every component;
Actionability~(A) wherever Makefiles, workflow managers, or platform APIs make re-execution or acquisition a single command;
Modularity~(M) wherever directory conventions or subproject composition enforce a separation of concerns;
Portability~(P) wherever good coding practice, containers or environment specifications decouple a research object from a particular machine;
Ephemerality~(E) wherever computational environments are treated as disposable and regenerable from specification;
and Distributability~(D) wherever licensing, packaging standards, or data logistic mechanisms enable sharing.

The formalization presented here provides a shared vocabulary for what these practices have in common, enabling researchers to evaluate and incrementally improve their workflows regardless of the specific tools they employ.
Figure~\ref{fig:convergent-evolution} summarizes these parallel timelines and their mapping to STAMPED principles.

\begin{figure}[htbp]
\centering
\includegraphics[width=\textwidth]{figures/convergent-evolution-gantt.pdf}
\caption{Convergent evolution of empirical scientific practice toward STAMPED.
Five independent lines of development are shown on a shared timeline from 1992 to 2025.
These comprise foundational ideas, normative frameworks, data version-control tools, platforms and metadata standards, and framework tooling.
Each milestone is annotated with the STAMPED principles it anticipates.
Despite independent origins, all five tracks converged on the same organizational patterns that STAMPED formalizes.
The milestones shown are illustrative rather than exhaustive; many other influential projects and communities contributed to this convergence but are omitted here for brevity.}
\label{fig:convergent-evolution}
\end{figure}



\anchoredsubsection{future-directions}{Future directions}

STAMPED principles provide a vocabulary rather than a closed specification, which is rooted in practices that continue to evolve with tooling, policy, and scientific convention.
The directions below identify open fronts where the framework's vocabulary will need to stretch, and where complementary work by adjacent communities will shape how STAMPED assists researchers in the coming decade.
We begin with directions that apply broadly across computational science, including generalizing Ephemerality~(E) to workflow specifications, aligning provenance standards, building adoption incentives, and seeding training pipelines.
The remainder of the section then addresses the more specific and fast-moving challenges introduced by AI, where several STAMPED principles need explicit extensions and where the stakes for transparent, reproducible research are most immediate.

\anchoredsubsubsection{spec-centric}{Specification-centric research objects as the reproducibility ideal}

Ephemerality~(E), as formulated here, treats the compute environment as disposable while the code and data it runs on remain durable.
A complementary view is emerging in which workflow implementations themselves become regenerable from a durable specification.
Declarative workflow languages such as CWL\cite{crusoe_methods_2022}, Snakemake\cite{molder_sustainable_2021}, and Nextflow\cite{di_tommaso_nextflow_2017}, together with fully-declarative environment managers such as Nix\cite{kowalewski_sustainable_2022} and Guix\cite{courtes_reproducible_2015}, already operate this way.
The specification accumulates the domain knowledge, including inputs, constraints, expected outputs, and validation criteria, while any given implementation can be rebuilt or replaced without loss.
Under this view, STAMPED principles apply to the specification first and the generated implementation second.
The specification is what must be Self-contained~(S), Tracked~(T), Actionable~(A), and Distributable~(D), while the running code is Ephemeral~(E) in the same sense as a container.
The connection to pre-registration is direct and generalizes Ephemerality~(E) even further\cite{nosek_preregistration_2018}.
A well-formulated study specification is a commitment that survives any particular implementation, and what is Ephemeral~(E) expands from the compute environment to the full ``scientific middleware'' (data acquisition,
harmonization, preprocessing, analytics), with each stage reduced to a specification from which implementations can be derived.
OSF Registrations\cite{foster_open_2017} already operate this way for preregistered plans, fixing a study's specification under a DOI before any implementation begins.
The target for STAMPED principles thus shifts to the study specification itself: once formalized and standardized, its middleware steps can run automatically in an Ephemeral~(E) fashion, even exploring alternative implementations.
The cost of under-specified middleware is already visible in practice; the NARPS study showed that 70 independent teams analyzing the same fMRI dataset with nominally similar hypotheses produced substantially divergent results\cite{botvinik-nezer_variability_2020}, precisely because the study specification left most of the middleware up to each team.

\anchoredsubsubsection{provenance-standards}{Provenance standards convergence}

As FAIR leaves specific protocols and standards open, STAMPED likewise does not prescribe a serialization for provenance records, and in practice researchers rely on whatever their tooling emits.
Convergence among existing approaches would let STAMPED research objects carry Portable~(P) provenance across toolchains without lock-in.
Relevant efforts include cross-domain standards such as W3C PROV\cite{w3c_provenance_working_group_prov-overview_2013} and RO-Crate\cite{peroni_packaging_2022}, tool-level records such as DataLad's\cite{halchenko_datalad_2021} \texttt{datalad run} provenance, and domain-specific specifications such as BIDS-Prov (BEP028)\cite{bids_community_bep028_2025}.
This is less a change to STAMPED itself than a call on these communities: Tracking (T) becomes substantially more useful when provenance records follow shared standards and can be exported, compared, and re-interpreted by tools other than the one that generated them.


\anchoredsubsubsection{adoption-incentives}{Adoption incentives and tool certification}

STAMPED compliance today is self-assessed against the checklist fulfilling a simple LinkML model\cite{cody_baker_stamped-principlesstamped-checklist-schema_2026} presented in this paper, and exposed to users in a convenient Web UI at the \httpsurl{checklist.stamped-principles.org} webpage.
That Web UI provides Self-contained~(S) stateful permalinks to render any particular state of the filled out checklist, so they could be shared easily.
Broader adoption will depend on promotion and external incentives, including funder mandates (e.g.,\ NIH Data Management and Sharing policies), journal reproducibility badges\cite{center_for_open_science_open_2023}, and venue-level review checklists that converge toward automated scoring. 
Such a trajectory would parallel that of FAIR, which has moved from principles to machine-assessable indicators with tools such as F-UJI\cite{devaraju_automated_2021}.
No currently available automated tool certifies STAMPED compliance.
A community-maintained benchmark suite, seeded by the satellite examples project associated with this paper (\httpsurl{examples.stamped-principles.org}), is a natural precursor.


\anchoredsubsubsection{teaching}{Teaching and onboarding}

Uptake through formal training is slow but compounding.
As the ``train the trainer'' model used by the ReproNim program has demonstrated, students and researchers who encounter these practices early in their career become some of the most effective propagators of open science, even if that propagation takes years to surface.
Existing resources already teach most of what STAMPED asks for, without using the term.
These include EduWrench\cite{casanova_eduwrench_2023}, the Reproducible Research MOOC which teaches \texttt{git-annex} and related tools\cite{legrand_reproducible_2022}, and RDMkit data analysis best practices\cite{elixir_rdmkit_community_data_2024}.
Curricular integration with open-science and neuroimaging training programs such as Brainhack would close the gap between practitioners who apply these practices by habit and those who can name what they are doing and evaluate it against a shared checklist.
YODA principles have already entered the curricula of several such programs, and we expect their references to migrate toward the more formally articulated STAMPED vocabulary.
Continued community outreach, including a recent introduction to STAMPED\cite{baker_guidelines_2026} delivered to the BRAIN BBQS program, supports that transition.


\anchoredsubsubsection{ai-era}{Research in an AI era}

AI agents are now generating analysis code, selecting methods, and in some systems running entire research cycles end-to-end as ``AI scientists''\cite{boiko_autonomous_2023, lu_ai_2024, mitchener_kosmos_2025}.
Without explicit structure, this automation can produce results whose provenance and reasoning are irrecoverable\cite{messeri_artificial_2024}.
The STAMPED principles already carry most of what is needed.
Self-contained~(S) workspaces alone give agents a well-defined boundary; Tracked~(T) histories make agent contributions auditable and contribute to their ``memory''; Actionable~(A) documentation serves humans and machines alike.
As with any new methodology or instrumentation entering science, several of these principles need AI-era extensions.
Because the agentic-AI ecosystem is evolving rapidly, the directions below are indicative rather than exhaustive.

\paragraph{Self-contained models.}
Machine learning models are becoming standard components of research workflows, yet they are often fetched at runtime from external repositories with no guarantee of long-term availability or version stability.
Users frequently interact with models through platforms without knowing which model version produced their results.
Even where models are nominally versioned, the degree of control varies widely, with Hugging Face providing commit-level pinning while commercial APIs may silently update the model behind a fixed endpoint.
Self-containment~(S) extends naturally to this case: models are Tracked~(T) components of the research object, just as data and code are today.
Practical mechanisms exist for open models, such as pinned revisions on Hugging Face or, for durable Self-containment~(S), archival copies managed via \texttt{git-annex}.
Tracking what training data and procedures produced a given model remains an open problem that intersects copyright, benchmarking, and provenance, and is mostly beyond what STAMPED can prescribe.
Community artifacts such as Model Cards\cite{mitchell_model_2019} and Datasheets for Datasets\cite{gebru_datasheets_2021} nonetheless point toward the shape of an answer.

\paragraph{Provenance for AI-driven changes.}
When an AI agent modifies code, generates analysis scripts, or makes architectural decisions, those actions become part of the research record.
Tracking (T) naturally extends to cover agent actions by wrapping an agent invocation in a provenance-capturing command such as \texttt{datalad run} to record the model, prompt, and resulting changes alongside the output.
Some of this provenance is already captured organically through git commits authored by agents, session transcripts, and co-authorship metadata.
Emerging tools such as Entire CLI\cite{entire_entire_2026} go further, automating capture of the entire AI session alongside the commit.
A practical tension follows wherein agent sessions can produce enormous transcripts, and including them wholesale may dilute the value of more targeted provenance records, so what to capture and at what granularity remain open questions.
Bitwise reproducibility is not the target and rarely is the goal even for human-driven steps.
Instead, what the record must preserve is the hypothesis, the method specification, and enough of the decision trail to support introspection.
Self-contained~(S) models (above) strengthen this chain---when the model itself is Tracked~(T), the provenance record is more complete.

\paragraph{Machine-actionable instructions.}
Actionability~(A) was defined with human operators in mind, including entry-point commands documented in READMEs that are frequently incomplete or out of sync with the underlying workflow.
AI agents are a second consumer of the same prose, one that can parse, follow, and correct instructions on the fly, and plain Markdown has effectively become the interface language: \texttt{AGENTS.md} files, README-driven agent workflows, and spec-kit\cite{github_spec_2025} collections now function as machine-actionable interfaces, making Self-contained~(S) and Tracked~(T) research objects more Actionable~(A).
Where prose instructions fail, the failure is legible (an audit mechanism that did not exist before) even if agent-driven execution remains less reliable than deterministic tooling.

\paragraph{AI-accelerated specification-to-implementation.}
Specification-centric research objects (above) depend on the cost of regenerating an implementation from a specification being low enough to be routine.
AI coding assistants and specification-driven toolkits such as spec-kit move this cost toward zero, making the spec-centric view practical rather than aspirational.
This holds provided the preceding extensions for models, provenance, and machine-actionable instructions are in place.
Such acceleration is what the end-to-end ``AI scientist'' systems that opened this section already attempt at full scale.
As soon as an agentic pipeline takes a study specification and returns data, code, figures, and a draft manuscript, the specification and every downstream artifact must together satisfy STAMPED, not only to keep such pipelines efficient to re-run at lower cost but to make their outputs introspectable.
Tracked~(T) and Self-contained~(S) research objects let a researcher inspect which model, prompt, and decision led to a particular result, implement ``hand-off'' between humans and agents alike, and let subsequent actors re-enter any prior state and continue from it without rediscovering context.
At the end, human scientists authoring and iterating over the specification of a STAMPED research object would see how their edits propagate through the generated implementation.
Without the STAMPED principles, the acceleration might be real but the accountability would be lost.
Instead, spec-driven agentic research becomes a collaborative, transparent artifact between scientists and the AI systems that support them.


\anchoredsection{data-availability}{Data availability}

All materials, data and code alike, are shared as part of the \ghurl{stamped-principles} GitHub organization, and released under open licenses (OSI-approved licenses for code, CC BY 4.0 for text and figures), with per-file licensing metadata maintained via the REUSE specification.

The STAMPED principles\cite{cody_baker_stamped-principlesstamped-principles-schema_2026} (\ghurl{stamped-principles/stamped-principles-schema}) and their accompanying compliance checklist\cite{cody_baker_stamped-principlesstamped-checklist-schema_2026} (\ghurl{stamped-principles/stamped-checklist-schema}) are formally encoded as LinkML schemas with corresponding JSON instances, separating the data model from the principle content so that each can evolve independently.
All sources for this manuscript (e.g., LaTeX file, figures; \ghurl{stamped-principles/stamped-paper}) have a rendered version at \httpsurl{paper.stamped-principles.org}.
Examples illustrating the principles are published as a Hugo-built static website and collected in \ghurl{stamped-principles/stamped-examples}, open for submissions from the community.
Examples in that repository are metadata-tagged to allow classification and filtering by principle, domain, and tooling as presented at \httpsurl{examples.stamped-principles.org}.
Visual identity materials (e.g., logos, favicons, etc) are maintained at \ghurl{stamped-principles/stamped-branding}, and organization-level landing content is served from \ghurl{stamped-principles/.github} at \httpsurl{stamped-principles.org}.
The bibliography for this work is curated in the Center for Open Neuroscience public Zotero group library at \httpsurl{www.zotero.org/groups/6197458/centerforopenneuroscience/library}, which is openly reusable.

\anchoredsection{code-availability}{Code availability}

This work is a documentation and formalization project, and the production of scientific software is not its primary aim.
The auxiliary code that supports it is distributed across the organization's repositories and includes tooling around the LinkML schemas in \texttt{stamped-principles-schema} and \texttt{stamped-checklist-schema}; the front-end JavaScript that powers the interactive compliance checklist deployed at \httpsurl{checklist.stamped-principles.org}; the Hugo-based site that renders worked examples in \texttt{stamped-examples}; and continuous-integration workflows in \texttt{stamped-paper} that build the manuscript PDF and post diff previews on pull requests.


\bibliographystyle{unsrtnat}
\bibliography{references}

\anchoredsection{author-contributions}{Author contributions}

% Contributions follow the CRediT taxonomy (https://credit.niso.org/,
% ANSI/NISO Z39.104-2022). Single source of truth: .tributors.credit.yaml
% (CRediT overlay) + .tributors (identity, con/tributors JSON cache).
% Regenerate via `make author-contributions` (renderer: code/render_credit.py).
\input{author-contributions}

\anchoredsection{competing-interests}{Competing interests}
The authors declare no competing interests.

\anchoredsection{acknowledgments}{Acknowledgments}

STAMPED builds directly on prior community efforts to articulate principles for reproducible research data management.
We are grateful to Michael Hanke and Adina S.\ Wagner for the conceptual development of VAMP\cite{hanke_what_2023}, and to the authors of the original YODA poster\cite{hanke_yoda_2018}---Michael Hanke, Matteo Visconti di Oleggio Castello, Kyle Meyer, and Benjamin Poldrack---whose work laid the foundations on which this formalization rests.
We thank Jiameng Wu for filing issues and contributing editorial improvements to the manuscript.

This manuscript and companion materials in the \ghurl{stamped-principles} organization were prepared with the assistance of agentic AI coding tools and large language models (primarily Claude Opus).
All final text, figures, and specifications were edited and/or confirmed by the human authors, who are responsible for the content.
Where AI tools notably contributed to a change, we have strived to annotate the corresponding commits with a \texttt{Co-Authored-By} trailer, or analogous comments, to identify the tool and potentially the model version, so that the provenance of individual contributions is inspectable in the public git history of the \texttt{stamped-*} repositories.

\anchoredsection{funding}{Funding}
This work was supported by the National Institutes of Health:
ReproNim --- Center for Reproducible Neuroimaging Computation (NIBIB P41~EB019936),
OpenNeuro --- An Open Archive for Analysis and Sharing of BRAIN Initiative Data (NIMH R24~MH117179),
DANDI --- Distributed Archives for Neurophysiology Data Integration (NIMH R24~MH117295),
and EMBER --- Ecosystem for Multi-modal Brain-behavior Experimentation and Research (NIMH R24~MH136632).

\end{document}

% LocalWords:  agentic