# Chapter 144. Reproducible RNA Workflows, FAIR Data Systems, Licensing, and Maintenance

## Scope Note

This chapter treats reproducible RNA computation and data stewardship as scientific operations. Declared inputs, workflow systems, containers, notebooks, provenance records, validation rules, repository standards, licensing choices, citation practice, and maintenance determine whether RNA analyses can be rerun, audited, deposited, reused, and kept current. Scientific nomenclature, identifier meaning, ontology semantics, coordinates, and evidence semantics belong to [Chapter 6](chapter1006.md). The RNA resource landscape, accession models, coverage comparison, and cross-resource record matching belong to [Chapter 19](chapter1018.md). This chapter owns how selected inputs and vocabularies are captured, validated, executed, deposited, licensed, cited, monitored, and maintained.

## Executive Summary

Reproducible RNA analysis begins by declaring inputs as versioned computational objects. Raw reads, count matrices, reference sequences, transcript annotations, sample sheets, barcode whitelists, peak sets, structure files, modification calls, trained models, and controlled terms must be named together with versions, checksums, formats, access conditions, and roles in the workflow. Selecting which biological resource best represents an RNA is the subject of [Chapter 19](chapter1018.md); the operational responsibility here is to freeze or fingerprint the chosen inputs and record how each input enters the analysis.

Interoperable RNA data require controlled metadata and explicit schemas. A schema declares required fields, data types, cardinality, allowed values, relations among tables or objects, and validation constraints. Controlled terms supplied by scientific ontologies can make metadata comparable, but this chapter does not redefine those terms. Instead, it records the term identifier and vocabulary version, validates that required qualifiers are present, and preserves unmapped or uncertain values rather than forcing an invalid term. Deep terminology and ontology meaning hand off to [Chapter 6](chapter1006.md).

Workflow managers, containers, notebooks, and provenance systems make RNA analyses reproducible only when they capture enough of the computational and biological context. A workflow manager records dependencies among analysis steps; a container records software and system libraries; a notebook records interactive exploration; and provenance records connect inputs, parameters, code versions, outputs, and decision points. These tools are especially important for RNA because small differences in annotation version, genome build, strandedness, multimapping policy, duplicate handling, barcode filtering, or modification-calling model can change biological interpretation. A reproducible RNA workflow is not simply a script that can run again; it is an auditable analysis whose inputs, assumptions, versions, and outputs can be understood.

FAIR data principles state that data should be findable, accessible, interoperable, and reusable. In RNA research, FAIR practice means depositing raw and processed data in appropriate repositories, using stable identifiers, providing rich metadata, selecting licenses that allow intended reuse, citing database versions, and documenting analysis workflows. FAIR does not mean that all data are unrestricted or simple to reuse. Human clinical data, pathogen surveillance data, proprietary therapeutic manufacturing data, and rare disease transcriptomes may require controlled access, de-identification, consent-aware reuse, or regulatory limits. FAIR RNA data systems must balance openness with privacy, biosafety, intellectual property, and quality control.

Database maintenance is a continuing scientific responsibility. RNA resources drift as genome assemblies change, transcript models are revised, gene symbols are updated, obsolete records are retired, and new assays redefine what a feature means. Broken identifiers, silent annotation updates, missing version strings, and duplicated records can propagate errors into downstream analyses and knowledge bases. Maintenance therefore requires update monitoring, version pinning, identifier mapping, checksum records, deprecation handling, and periodic revalidation of derived conclusions. The most important misconception is that a database record is a fact. A database record is a curated representation of evidence under a defined schema, version, and curation policy.

## Concept Inventory

- **Workflow input manifest:** a machine-readable list of files, records, parameters, references, models, and vocabularies entering an analysis, including versions, checksums, formats, access conditions, and declared roles.
- **Metadata schema:** a formal specification of fields, types, required values, cardinalities, relationships, and validation rules used to describe RNA samples, assays, files, and processing outputs.
- **FAIR data:** findable, accessible, interoperable, and reusable. Findability requires stable identifiers and searchable metadata. Accessibility requires clear retrieval mechanisms and access rules. Interoperability requires machine-readable formats, shared vocabularies, and compatible schemas. Reusability requires provenance, license clarity, quality indicators, and enough context to interpret the data.
- **Provenance:** the record of where data came from, how data were transformed, who or what performed the transformation, which software and parameters were used, and which outputs resulted. In RNA analysis, provenance often includes sample metadata, library construction, sequencing instrument and chemistry, reference genome and annotation versions, aligner or quantifier versions, filtering thresholds, statistical models, and manual curation decisions.
- **Database drift:** the change in a resource over time. Drift can be beneficial when errors are corrected and new evidence is added, but drift can also break reproducibility when a record, identifier, coordinate, or annotation changes without being pinned to a version. Drift is common in transcript annotations, gene symbols, RNA family models, modification catalogs, and interaction databases.

## What to Know Before Reading This Chapter

The reader should know that an RNA molecule can be represented in many ways. The same transcript may be a nucleotide sequence in a FASTA file, a genomic interval in a browser track, a transcript model in a GTF file, an expression row in a matrix, a family member in a covariance model, a structure in a three-dimensional coordinate file, a set of modification calls, a therapeutic ingredient, or a claim in a curated knowledge base. These representations are connected but not identical. The central task of RNA data infrastructure is to preserve enough information for a user to know which representation is being used and what evidence supports it.

The reader should also distinguish three layers of evidence. Raw or minimally processed data are measurements, such as sequencing reads, mass spectra, microscopy images, or crosslink-derived fragments. Derived features are computationally or experimentally interpreted outputs, such as transcript abundance, splice junction support, modification probability, CLIP peak, RNA-RNA chimeric read, or predicted secondary structure. Biological claims are interpretations, such as "this lncRNA regulates this gene," "this modification changes translation," or "this guide RNA is therapeutically active." Databases may contain any of these layers, and the appropriate reuse depends on knowing which layer a record represents.

Finally, the reader should distinguish identifier meaning from identifier use. [Chapter 6](chapter1006.md) explains what an identifier, version, coordinate, or ontology term means, and [Chapter 19](chapter1018.md) explains how records from different resources relate. This chapter assumes those semantic decisions have been made and asks whether the selected identifiers and terms are pinned, validated, cited, and monitored as workflow inputs.

## 144.1. Workflow inputs, data models, and reproducible computational operations

A reproducible RNA workflow begins with an explicit input contract. The contract states which files and records enter the analysis, what role each input plays, which versions or releases define them, how integrity is checked, and which access or reuse conditions apply. Typical inputs include raw reads, sample sheets, reference FASTA files, transcript annotations, barcode whitelists, peak or contact sets, structure coordinates, modification models, phenotype tables, controlled terms, and configuration parameters. A filename alone is not an input contract because the same filename can conceal changed content.

Input integrity is usually established with content fingerprints such as cryptographic checksums, file sizes, archived release identifiers, and immutable object locations. Fingerprints do not establish biological suitability; they establish that the workflow used the intended bytes. Biological suitability still depends on experimental design and on selecting an appropriate RNA record or resource. Identifier and ontology meaning hand off to [Chapter 6](chapter1006.md), while resource choice and cross-resource matching hand off to [Chapter 19](chapter1018.md).

Data models determine how workflow objects connect. A bulk RNA-seq model may relate participants, biospecimens, libraries, lanes, read files, count matrices, reference releases, contrasts, and result tables. A single-cell model adds cell barcodes, feature identifiers, filtering decisions, batch structure, embeddings, and cell annotations. A structure-probing model adds reagent, reaction condition, mutation or cleavage observable, reference sequence, normalization, and structure-inference output. The model should preserve one-to-many and many-to-many relations rather than flattening several libraries, samples, or reference objects into ambiguous columns.

Reproducible operations are deterministic where possible and explicit where judgment is unavoidable. Each step declares inputs, outputs, parameters, software environment, resource requirements, and failure conditions. Manual exclusions, interactive parameter choices, and curation decisions should be recorded as structured events or reviewed configuration changes. Randomized algorithms need seeds or documented nondeterminism. Parallel execution needs stable aggregation rules when task order could change floating-point or tie-breaking results.

Validation begins before computation. File formats, compression, checksums, read pairing, sample identifiers, organism and reference compatibility, annotation syntax, strandedness, barcode structure, and expected feature namespaces can be checked automatically. A failed preflight check should stop the workflow rather than produce a plausible but misassigned result. During execution, logs, exit codes, resource use, software versions, and intermediate quality metrics reveal whether the intended operations occurred.

The output contract is as important as the input contract. Outputs should state whether they are raw transformations, normalized values, statistical estimates, predictions, visual summaries, or final claims. A count matrix without feature namespace and annotation release is incomplete; a splice-junction table without coordinate convention is ambiguous; a modification probability without caller and model version cannot be compared safely. This chapter owns the capture and validation of these operational fields, not the scientific definition of the entities themselves.

## 144.2. Controlled metadata, schemas, and validation for interoperable RNA data

Metadata are operational descriptions of samples, assays, files, processing steps, and access conditions. A FASTQ file may be syntactically valid yet scientifically unusable if the sample, organism, library strategy, strand protocol, replicate structure, or consent status is missing. A count matrix may be readable yet uninterpretable if feature identifiers, annotation release, normalization, and sample labels are absent. Interoperability therefore begins with a schema that states which fields are required for the assay and downstream use.

A schema should express types and relationships, not merely supply column headings. Dates, units, controlled identifiers, Boolean values, enumerated states, arrays, missing-value reasons, and foreign-key relations should be distinguishable. Required fields can depend on context: a human clinical sample needs consent and controlled-access fields; a direct RNA run needs pore chemistry and basecalling model; a CLIP experiment needs antibody, crosslinking, digestion, and control information; a spatial dataset needs image, coordinate, tissue, and segmentation relations.

Controlled vocabularies make schemas interoperable when they are recorded with stable term identifiers and vocabulary versions. This chapter validates their use but does not define their scientific meaning. If a library-strategy term is too broad, the schema should require protocol qualifiers. If no valid term exists, the deposit should preserve an explicit unmapped value and definition rather than coerce it into a misleading class. Naming and ontology semantics belong to [Chapter 6](chapter1006.md).

Validation occurs at several levels. Syntactic validation checks file structure, field types, required values, identifiers, and referential integrity. Semantic validation checks whether combinations are plausible: paired-end files should form pairs, organism and assembly should agree, declared strandedness should match diagnostic read patterns, coordinates should fall within the reference, and cell-barcode formats should match the assay. Scientific validation checks study logic, such as whether biological replicates are independent, controls are present, batches are represented, and derived outputs use the declared inputs.

Validation results should be retained as provenance. A passing schema does not prove biological validity, and a failing optional recommendation does not always invalidate a dataset. Reports should distinguish errors that block execution, warnings that limit interpretation, and informational checks. Machine-readable reports allow repository curators, workflow engines, and downstream users to determine which constraints were tested and which exceptions were accepted.

Schema evolution is unavoidable. New RNA assays introduce fields, vocabulary terms are deprecated, privacy rules change, and old records lack information required by newer standards. Versioned schemas should document additions, removals, migrations, and backward-compatibility rules. A migration must not silently invent values for missing historical fields. Resource-specific record models and matching belong to [Chapter 19](chapter1018.md); the operational concern here is how schema versions and validation outcomes are captured and maintained.

## 144.3. Workflow Managers, Containers, Notebooks, and Provenance

A computational workflow is the ordered set of steps that transforms inputs into outputs. In RNA analysis, a workflow may trim reads, assess quality, align or pseudoalign reads, assign reads to genes or transcripts, call splice junctions, quantify isoforms, detect modifications, infer structures, call peaks, normalize matrices, fit statistical models, and produce tables or figures. A workflow manager records this dependency graph and executes steps in a controlled way. Examples of workflow-manager concepts include explicit inputs and outputs, task-level parameters, software environments, resource requirements, conditional steps, logging, and restart behavior. The scientific value is that the analysis becomes inspectable and rerunnable.

Workflow managers matter for RNA because RNA analyses are sensitive to small choices. A bulk RNA-seq workflow changes when the reference annotation changes, when multimapping reads are handled differently, when strandedness is misdeclared, when ribosomal RNA depletion changes coverage, or when low-count filtering differs. A single-cell workflow changes when empty droplets, ambient RNA, doublets, barcode correction, mitochondrial fraction, normalization, integration, and cell-type labeling are handled differently. A CLIP workflow changes when duplicates, crosslink-induced mutations, peak width, input normalization, and motif background are handled differently. A modification-calling workflow changes when basecalling models, controls, and calibration standards change. A workflow manager cannot decide which choices are biologically correct, but it can make choices visible.

![Figure 144.3. Provenance Graph for a Reproducible RNA Workflow](../assets/figures/chapter1131_figure3.png)

**Figure 144.3. Provenance Graph for a Reproducible RNA Workflow.** Reproducibility depends on preserving both biological provenance and computational lineage; rerunning the graph does not by itself establish biological validity.

Containers address the software-environment part of reproducibility. A container packages operating-system libraries, command-line tools, language runtimes, and software dependencies so that a workflow step runs in a defined environment. Containers are useful because RNA tools often have complex dependencies: aligners, quantifiers, transcript assemblers, statistical packages, basecallers, structure-prediction tools, peak callers, and visualization libraries may require specific versions. A container should not be treated as a complete provenance record. It records the environment, but the analysis also needs input checksums, parameter settings, reference files, workflow code, output versions, and curation decisions. A container can faithfully rerun a flawed analysis if the biological metadata or annotation choice is wrong.

![Figure 144.7. Execution Stack for a Reproducible RNA Analysis](../assets/figures/chapter1131_figure7.png)

**Figure 144.7. Execution Stack for a Reproducible RNA Analysis.** A reproducible RNA analysis binds immutable inputs to a declared workflow, pinned references, parameters, and software environment; runtime logs, intermediates, tests, and output checksums make execution auditable without establishing biological validity.

Computational notebooks serve a different role. A notebook combines code, text, outputs, and figures in an interactive document. Notebooks are useful for exploratory analysis, data inspection, teaching, and figure generation. They are risky as the sole analysis record because cells can be executed out of order, hidden state can persist, outputs can be stale, and manual edits can be hard to audit. A robust RNA analysis often uses workflow managers for primary data processing and notebooks for downstream exploration, with notebooks reading versioned workflow outputs rather than raw mutable files. When a notebook is used for final results, it should be executable from a clean state and should state package versions, input file checksums, and random seeds when relevant.

Provenance is the conceptual spine connecting workflows, containers, and notebooks. A provenance record answers a chain of questions: which biological sample was measured; which library preparation was used; which instrument and chemistry generated the data; which files were downloaded; which reference genome, transcriptome, or database release was used; which software and parameters processed the data; which outputs were produced; which manual decisions were made; and which claims were derived. Provenance is not only computational. For RNA biology, upstream biological provenance such as tissue ischemia time, RNA integrity, cell sorting, subcellular fractionation, crosslinking conditions, spike-ins, and storage conditions may be as important as software version.

**Table 144.3. Minimum Provenance Fields for RNA Analyses.** Reproducible RNA analysis requires provenance linking sample and assay identity, references, software, parameters, execution, outputs, and manual decisions; a result file without this lineage cannot be independently audited.

| Provenance layer | Required fields | Example validation |
|---|---|---|
| **Sample and assay** | Sample identity, specimen context, library protocol, replicate role | Reconcile manifest, raw files, and assay design |
| **Reference and software** | Release, checksum or digest, parameters, workflow revision | Resolve immutable versions and compare fingerprints |
| **Outputs and decisions** | Output role, quality checks, manual decisions, claim links | Rerun validation and inspect the lineage graph |

The evidence basis of workflow reproducibility is pragmatic rather than absolute. A rerunnable workflow demonstrates that the same inputs and software can produce the same outputs under a defined environment. It does not demonstrate that the outputs are biologically correct. Biological validity requires controls, appropriate experimental design, independent validation, and correct interpretation. For example, a perfectly reproducible single-cell workflow can still assign a spurious cell type if ambient RNA dominates a cluster. A reproducible modification-calling workflow can still overcall a mark if the training data did not include the relevant sequence context or modification chemistry. Reproducibility is necessary for auditability, but it is not sufficient for truth.

Workflow systems also support scalability and collaboration. Large RNA projects may process hundreds or thousands of samples, multiple organisms, or repeated releases of a reference database. Manual execution becomes error-prone when every sample must pass through the same steps. Workflow managers reduce accidental divergence, while parameter files and sample sheets make batch-level differences explicit. In collaborative projects, a well-specified workflow allows a computational biologist, experimentalist, statistician, and curator to discuss the same processing path. This is especially important when RNA data move from exploratory research to clinical assay validation, regulatory submission, or public resource construction.

The boundary case is exploratory science. Early RNA discovery often involves changing assumptions, trying alternative annotations, inspecting unusual reads, or testing multiple models. Exploratory work should not be forced into a rigid production workflow too early. Instead, the transition from exploration to evidence should be explicit. Exploratory notebooks and ad hoc scripts can generate hypotheses; production workflows and archived provenance should generate results that support claims. A mature RNA data system keeps both layers, labeling which outputs are exploratory and which are release-quality.

## 144.4. FAIR metadata, repository deposition, licensing, reuse, and citation

Metadata are data about data. In RNA research, metadata describe the biological source, experimental design, molecular assay, sequencing or measurement platform, computational processing, file formats, quality metrics, access rules, and citation information. Metadata make the difference between a reusable RNA dataset and an uninterpretable file. A FASTQ file without sample metadata may be technically readable but scientifically weak. A count matrix without annotation version, normalization method, and sample identities may be unusable for comparison. A modification call set without controls and chemical identity may be misleading.

Minimum RNA metadata depend on assay type. For bulk RNA-seq, essential metadata include organism, strain or genotype, tissue or cell type, condition, replicate structure, RNA extraction method, RNA selection or depletion strategy, library strandedness, read layout, sequencing platform, reference genome, transcript annotation, quantification method, and quality-control metrics. For single-cell RNA-seq, additional metadata include capture platform, cell or nucleus protocol, barcode and UMI handling, filtering, doublet detection, ambient RNA correction, batch structure, and cell annotation method. For CLIP-family data, metadata include antibody, crosslinking conditions, nuclease digestion, size selection, controls, replicate structure, peak-calling method, and input or size-matched controls. For structure probing, metadata include reagent, reaction conditions, controls, reverse-transcription readout, normalization, and transcript coverage. For therapeutic RNA records, metadata include chemistry, target, delivery system, dose context, indication, manufacturing process class, analytical release tests, and regulatory status.

Repository submission is the act of depositing data and metadata into an archive designed for durable preservation and reuse. Repository choice and comparative resource coverage belong to [Chapter 19](chapter1018.md). Once suitable targets have been selected, this chapter owns the operational deposit: package each data type with its required metadata, validate the package before transfer, reconcile identifiers across linked deposits, declare release and embargo conditions, and preserve the final submission manifest. Good repository submission is planned before or alongside publication, not reconstructed after a reader requests files.

![Figure 144.4. From RNA Experiment to FAIR Repository Deposit](../assets/figures/chapter1131_figure4.png)

**Figure 144.4. From RNA Experiment to FAIR Repository Deposit.** A FAIR deposit aligns files, metadata, provenance, access conditions, reuse rights, and persistent identifiers before release.

FAIR accessibility does not mean every file is open to everyone. Human transcriptomic data may require controlled access to protect participant privacy, especially when genotype, rare disease, clinical phenotype, infection status, or geographic information could identify individuals. Pathogen or environmental RNA surveillance data may raise biosafety, biosecurity, or sovereignty concerns. Therapeutic manufacturing and clinical data may include proprietary information or regulated patient records. A FAIR system states access conditions, application procedures, data-use limits, and contact points. The key is that access rules are explicit and durable rather than hidden or improvised.

Licensing determines what others may do with data, metadata, figures, code, and derived resources. Open licenses can permit reuse, redistribution, and derivative work, sometimes with attribution or share-alike requirements. More restrictive licenses may allow academic use but not commercial use, or may forbid redistribution. Public-domain dedication may be appropriate for some metadata but not for all datasets. RNA resources need license clarity because downstream users may build databases, machine-learning benchmarks, therapeutic design tools, or clinical decision-support systems. A dataset that is visible on a website is not automatically legally reusable. License ambiguity can block integration even when the scientific data are otherwise valuable.

Reuse requires more than legal permission. A reusable RNA dataset must include enough context for another scientist to interpret the measurement. For expression data, this means raw reads or images when possible, processed matrices, sample metadata, quality metrics, and scripts or workflows. For interaction data, it means controls, peak or contact calls, normalization choices, replicate concordance, and evidence of assay specificity. For RNA structures, it means coordinates or constraints, model-quality metrics, construct boundaries, ligand or protein context, and experimental conditions. For therapeutic or regulatory data, reuse may require careful distinction between public label information, clinical-trial records, patent disclosures, manufacturing summaries, and peer-reviewed publications.

> **Box 144.3. A FAIR Reuse Check Before Downloading**
>
> - Checklist: verify stable identifier and version; inspect sample and assay metadata; confirm access conditions and consent constraints; identify licenses for each component; obtain workflow and provenance records; record citation purpose; preserve validation results.

**Table 144.4. FAIR Deposition, Licensing, and Citation Requirements.** FAIR deposition joins identifiers, searchable metadata, access procedures, interoperable formats, provenance, rights, and citation; public visibility alone does not guarantee interpretability or legal reusability.

| FAIR dimension | Operational requirement | Common failure mode |
|---|---|---|
| **Findable and accessible** | Persistent identifier, searchable metadata, explicit access procedure | Files exist but cannot be discovered or requested |
| **Interoperable** | Declared formats, schema version, controlled values, validation report | Parseable files lack sufficient scientific context |
| **Reusable** | Provenance, quality indicators, rights statement, precise citation | Visible data have ambiguous permission or origin |

Data and resource citation is an operational evidence practice. A citation should identify the data object or resource, release or version, stable record or accession, coordinate reference when relevant, download or access date, and purpose in the analysis. In fast-moving areas, an access date is not a substitute for a version; both may be needed. [Chapter 6](chapter1006.md) owns the semantics of identifiers and citation-purpose relations, while [Chapter 19](chapter1018.md) owns record matching across resources. This chapter owns preserving those resolved objects in manifests, methods, deposits, and maintenance logs.

Metadata standards should be treated as community agreements, not bureaucratic obstacles. They encode lessons learned from failed reuse. If a repository requires library selection, strandedness, organism, tissue, and replicate fields, it is because missing values make downstream interpretation unreliable. However, standards can lag behind new methods. Direct RNA modification detection, spatial transcriptomics, multimodal single-cell assays, RNA editing therapeutics, circular RNA platforms, and RNA-guided transposase systems may generate metadata that older schemas do not capture well. In such cases, submitters should use the closest controlled fields while adding structured free-text or supplemental metadata that preserve the new assay-specific details.

Common metadata artifacts include sample-label swaps, inconsistent naming, missing negative controls, unrecorded pooling, ambiguous replicate definitions, incomplete clinical covariates, and unpinned reference files. These artifacts can survive publication and enter databases. A curator should not assume that deposited metadata are correct simply because a repository accepted them. Quality checks should compare sample names across raw files, metadata sheets, processed matrices, and figures; test whether organism and genome build match the sequences; confirm that library type matches strandedness patterns; and verify that biological replicates correspond to independent biological units rather than technical subsamples.

The cross-chapter handoff is direct. [Chapter 139](chapter1126.md) discusses experimental design and reproducibility for RNA methods; this section extends that logic to public data systems. Chapters [122](chapter1115.md) through [138](chapter1125.md) discuss assay-specific metadata needs. Chapters [158](chapter1141.md) and [159](chapter1142.md) discuss regulatory and manufacturing records for RNA drugs. These metadata also keep dataset availability separate from evidence strength in downstream integrative analyses.

## 144.5. Update Monitoring, Versioning, Database Drift, Broken Identifiers, and Knowledge-Base Maintenance

RNA databases are living resources. They change because new data are added, errors are corrected, genome assemblies improve, transcript models are revised, taxonomies are updated, nomenclature committees rename genes, disease classifications change, and curation policies evolve. These changes are scientifically valuable, but they create database drift. Database drift is any change in resource content or interpretation over time. Drift is harmless when a user only needs the latest view; it is dangerous when a result must be reproducible, audited, or compared across time.

Versioning is the primary defense against drift. A versioned resource labels releases so that records can be tied to a specific state of the database. Versioning may occur at several levels: database release, genome assembly, annotation release, record version, file checksum, software version, model version, and ontology term version. RNA analyses often need several of these simultaneously. A splice analysis may require genome assembly, transcript annotation release, aligner version, junction-calling parameters, and gene-symbol mapping date. An RNA structure analysis may require structure database entry, coordinate version, construct sequence, and annotation of modified nucleotides. A therapeutic knowledge record may require product label date, regulatory jurisdiction, and trial registry update date.

![Figure 144.5. Resource Drift and Revalidation Over Time](../assets/figures/chapter1131_figure5.png)

**Figure 144.5. Resource Drift and Revalidation Over Time.** Update monitoring detects change, but promotion requires an explicit impact assessment and a traceable replacement decision.

Broken identifiers occur when a link no longer resolves, a record is retired, a namespace changes, or a cross-reference no longer denotes the expected object. Silent changes are worse than obvious failures because they can produce plausible but wrong inputs. A maintenance system should record the deprecated identifier, date, reason, proposed replacement, mapping confidence, and cases where no safe replacement exists. Determining whether two biological records are equivalent belongs to [Chapter 19](chapter1018.md); this chapter records and executes the resulting maintenance decision.

Update monitoring is the practice of tracking database changes that could affect conclusions. Monitoring can be manual, automated, or both. Automated checks can detect new releases, changed file checksums, deleted records, ontology deprecations, and cross-reference failures. Manual review is needed when a change affects biological interpretation, such as a lncRNA being reclassified as protein-coding, a modification site being withdrawn, a viral lineage being renamed, a cell type being split, or a therapeutic status changing after new safety data. The output of update monitoring should be a change log that states whether downstream analyses or claims need revision.

Maintenance of a long-lived RNA analysis differs from one-time computation. Historical results must remain interpretable under their original inputs while corrected or updated outputs are released. A result that was reasonable under an older annotation may become obsolete when a transcript model changes. The maintenance record should not simply delete the old output; it should mark the output as superseded, explain why, link to the replacement, and state whether the change reflects corrected data, altered interpretation, or a newly preferred reference.

Database drift can create apparent biological discoveries. A researcher may compare two expression analyses and conclude that a transcript differs between studies, when the difference actually comes from annotation releases. A machine-learning benchmark may improve because duplicate records were removed or family labels changed. A therapeutic landscape review may list a discontinued product as active because an old database snapshot was used. A genome-browser screenshot may show a feature that moved or disappeared in a newer assembly. These are not rare edge cases. They are routine consequences of living resources.

Maintenance requires triage because not every database update matters equally. Critical updates include changes to identifiers used in claims, reference files used in analyses, disease or therapeutic status, evidence withdrawals, major ontology deprecations, and security or privacy changes affecting access. Moderate updates include new records that expand coverage but do not alter existing conclusions. Low-priority updates include cosmetic display changes or added cross-references that do not affect interpretation. A good maintenance policy defines which updates trigger reanalysis, curator review, user notification, or claim revision.

The strongest maintenance practice is to store both references and fingerprints. A reference names the resource, such as a URL, accession, or release. A fingerprint verifies the exact content, such as a checksum, file size, timestamp, or archived snapshot. For computational workflows, fingerprints should cover reference FASTA files, GTF or GFF annotations, index files, ontology releases, workflow code, containers, and key input data. For database-derived claims, fingerprints may include downloaded files, record exports, or archived pages when licensing permits. Fingerprints cannot solve every problem, but they make silent changes detectable.

Boundary cases include resources that do not provide versioned downloads, databases that update continuously, web interfaces that generate dynamic views, and proprietary or controlled-access systems that cannot be archived locally. In these cases, users should record access date, query parameters, exported records, screenshots only when appropriate, and any available release notes. If a database lacks versioning for a claim-critical use, that limitation should be stated in the methods or knowledge record. The absence of versioning is itself an evidence caveat.

![Figure 144.6. Maintenance Decision Ladder](../assets/figures/chapter1131_figure6.png)

**Figure 144.6. Maintenance Decision Ladder.** Maintenance effort should be proportional to the scientific consequences of an upstream change, not merely to release frequency.

Common misconceptions about maintenance should be named explicitly. The latest annotation is not always the correct annotation for reproducing an older analysis. A stable identifier does not guarantee unchanged content. A resource withdrawal does not always mean the original observation was false; it may mean the evidence no longer meets the resource's threshold. Conversely, persistence does not guarantee correctness. A mature RNA data system treats external records as versioned, provenance-bearing inputs that require periodic audit.

## Recent Consensus

The current consensus is that RNA workflow and data stewardship are part of the evidence chain, not clerical afterthoughts. A workflow has scientific value when inputs, transformations, environments, parameters, outputs, and decisions are auditable. Metadata have scientific value when they preserve the biological and technical context needed to interpret a measurement. A repository deposit has scientific value when files, metadata, access rules, rights, and persistent identifiers remain aligned.

A second consensus is that interoperability requires both syntax and declared scientific context. File formats allow software to parse data, while schemas and versioned controlled terms allow validation of what samples, assays, conditions, and outputs the data describe. Conformance remains only one evidence layer: a syntactically and semantically valid record can still reflect a mislabeled sample or unsuitable experiment. This chapter therefore couples validation reports to provenance rather than treating successful parsing as quality assurance.

A third consensus is that versioning, identifiers, metadata, and licensing are not optional administrative details. They determine whether another reader can recover the same RNA sequence, transcript model, ontology term, workflow result, therapeutic record, or regulatory status that supported a claim. FAIR practice therefore requires explicit access rules and reuse terms, not only public visibility. A resource can be valuable but unsuitable for unrestricted redistribution, and a dataset can be downloadable but legally or scientifically unsafe to reuse without license, consent, provenance, or quality checks.

## Open Questions, Controversies, Deprecated Models, and Common Misconceptions

Open questions:

- How should workflow systems represent changing cloud services, hardware accelerators, stochastic algorithms, and external models whose behavior cannot be captured completely by a container image?
- Which minimum machine-readable rights statements can reliably cover compound deposits containing data, metadata, code, images, and controlled-access components under different terms?
- How should maintenance policies quantify whether an upstream update requires documentation, partial rerunning, full rerunning, or reinterpretation of biological conclusions?
- Continuously updated resources may support current surveillance but remain weak for reproducing an old analysis unless snapshots or exports are preserved. Proprietary therapeutic and regulatory records may be authoritative for product status but incomplete for mechanistic inference because chemistry, manufacturing, or safety details can be confidential. A resource withdrawal, identifier deprecation, or license change should therefore trigger review rather than automatic deletion or substitution.

Common misconceptions:

- "FAIR means open without restriction." FAIR means that data and metadata are findable, accessible under defined conditions, interoperable, and reusable with clear provenance and license. Controlled-access human data can be FAIR when access procedures and reuse conditions are explicit.
- "Reproducible computation means correct biology." A workflow can reproduce an artifact.
- "Database curation removes uncertainty." Curation organizes evidence; it does not eliminate conflicting results, assay limitations, or changing nomenclature.

Deprecated or weakened claims:

- Weak practices should be retired. It is no longer adequate to describe a computational analysis as "standard RNA-seq analysis" without versions, parameters, references, and metadata. It is no longer adequate to cite only a resource homepage for a record-specific input. It is no longer adequate to treat a repository accession as proof that data are reusable. These practices are not sufficient for modern RNA biology.
- For readers moving into [Chapter 145](chapter1153.md), the key handoff is that RNA variant and molecular-QTL analysis depends on stable identifiers, transcript versions, evidence types, release information, and provenance. QTL or variant records that omit those fields can turn annotation drift or coordinate mismatch into apparent biological disagreement.