Why English? | Writing a University Shared Research Resource Data Preservation Handoff Note

State who transfers, who receives, what preservation service is involved and when responsibility changes.

A handoff is not merely a copy. It changes who must maintain integrity, monitor risk, control access and answer future questions. Define the effective point of acceptance.

What to check

• Name transferor and receiver
• Record staging and acceptance dates
• Identify preservation service
• Define responsibility boundary

Draw two boxes labelled working custody and preservation custody. Between them, write the exact acceptance event. This reveals whether “sent”, “uploaded”, “received” and “accepted” are being used as if they mean the same thing.

Add a responsibility matrix for integrity, metadata, security, access, monitoring and future contact. Shared responsibility is possible, but it should be explicit.

Boundary: Local policy may retain shared responsibility after deposit; the note should follow the actual agreement.

Learning transfer: Clear role verbs help students understand project handoffs and group work.

Give the package, project, study and dataset stable identifiers that survive folder renaming.

Connect facility job numbers, protocol or award references, investigator identifiers, repository accession or deposit IDs and dataset versions. Avoid using a person’s name as the only key.

What to check

• Assign package ID
• Link project and study
• Record dataset version
• Map facility job numbers

Use identifiers that are unique within the institution and stable across systems. Record mappings instead of forcing one system’s ID to replace every other useful reference.

If the dataset has versions, state whether a new deposit supersedes an earlier one, supplements it or remains independently citable. Version relationships protect reproducibility.

Boundary: Identifiers support traceability; they do not prove scientific validity or permission to access.

Learning transfer: Identity systems teach learners to distinguish a thing from its changing filename.

A manifest lists expected files or logical objects with path, name, size, type and identifier as appropriate.

Choose a level that is operationally useful. Millions of files may require grouped inventories or machine-readable manifests, while a small package may list each file. Keep the manifest itself inside the handoff record.

What to check

• List expected objects
• Record counts and sizes
• Label raw and derived
• Preserve manifest version

Create the manifest mechanically where possible, then review its semantics. Automated inventory reduces transcription error; human review confirms that categories such as raw, derived and documentation are meaningful.

Record excluded temporary files and caches when their absence matters. A preservation package should be deliberate, not merely a compressed copy of a workstation.

Boundary: A manifest proves expectation and structure, not the correctness of content.

Learning transfer: Inventories strengthen evidence control in laboratories and school research.

A checksum can show whether a sequence of bytes changed between generation, transfer and later checking.

Record algorithm, checksum value, generation point, verification point, tool or process and any mismatch. “Checksum passed” without those details is difficult to reproduce.

What to check

• Name algorithm
• Record source values
• Record verification event
• Resolve every mismatch

Keep checksum files read-only and inside the controlled record. Generate them before the risky transfer step and verify them after receipt so the evidence brackets the handoff.

If a mismatch occurs, preserve logs and affected identifiers. Re-copying until the screen turns green can destroy the evidence needed to understand a recurring problem.

Boundary: Checksums detect change under the method; they do not authenticate scientific meaning or eliminate malware and confidentiality risks.

Learning transfer: This is a practical example of evidence that supports a narrow claim rather than every claim.

Future users need to know how data moved from instrument or source through processing to the preserved object.

Record acquisition system, key parameters, software and version, transformation steps, responsible role and links to controlled protocols or code. Keep raw, intermediate and derived states distinct.

What to check

• Identify acquisition source
• List transformation steps
• Record software versions
• Link raw to derived objects

Write provenance as a directed chain. “Processed data” is not enough; name the input, operation, software or code, parameter set, output and responsible role.

Where code or workflows change, capture the version used for this package. Linking only to a live repository branch can make later reconstruction impossible.

Boundary: A handoff note indexes provenance; it may point to detailed workflow records rather than reproduce them.

Learning transfer: Process language helps students explain how an answer was produced, not just what it is.

Files without metadata may remain intact yet become unusable.

Include enough descriptive, structural, technical and administrative metadata to identify content, relationships, format, dates, creators or roles, instruments, units and access rules. Use applicable standards rather than inventing fields casually.

What to check

• Define variables and units
• Describe file relationships
• Record format and version
• Use applicable standards

Test metadata with a stranger-to-the-project exercise. Can a qualified colleague identify the dataset, units, relationships, restrictions and method without asking the original operator? Their questions reveal missing context.

Do not expand metadata by copying confidential identifiers into broader systems. Description must remain consistent with data minimisation and approved access.

Boundary: Metadata completeness is domain-specific; repository and disciplinary requirements control.

Learning transfer: Vocabulary precision turns labels into usable evidence.

Preservation should keep the context needed to understand how the data were produced and what they can support.

Link protocols, data dictionaries, calibration records, quality notes, code, readme files and publication references. State which documents are authoritative and which are convenience copies.

What to check

• Link current protocol
• Include data dictionary
• Preserve quality notes
• Identify authoritative records

Mark each contextual document as authoritative, derived or informational. A PDF copy may help future reading while the signed agreement or controlled protocol remains the legal or operational source.

For computational work, preserve environment information or dependency records at a level proportionate to the future-use goal. A list of software names without versions may be inadequate.

Boundary: Context supports interpretation but does not guarantee reproducibility or fitness for every future use.

Learning transfer: Readers learn that evidence depends on documentation around the number.

State the received formats, preferred preservation representations and any planned migration, normalisation or emulation approach.

Separate the original bitstream from preservation derivatives and access copies. Record why a transformation was chosen and how equivalence was checked.

What to check

• Inventory formats
• Label originals and derivatives
• Record migration decision
• Define validation criteria

Make the representation relationship readable: original, normalised preservation copy, access derivative and preview. Users should know which one retains the source characteristics and which one trades features for accessibility.

Validate important properties after transformation. A file that opens may still have lost channels, precision, timing, metadata or compression characteristics.

Boundary: No format is permanently future-proof; preservation requires monitoring and review.

Learning transfer: Format literacy helps students understand why compatibility and meaning are separate problems.

Preservation custody does not erase human-subject, contractual, intellectual-property or security obligations.

Record the access class, consent boundaries, de-identification status, data-use agreements, embargoes, repository restrictions and authorised contact. Avoid placing sensitive values in the public note.

What to check

• State access class
• Link consent or authority
• Record agreements and embargo
• Name approval route

Use separate fields for preservation permission and access permission. A repository may lawfully retain material while restricting who can see it, for how long and through which review route.

If consent or an agreement is ambiguous, pause the access decision and escalate. Do not repair uncertainty by writing a more convenient interpretation into the handoff note.

Boundary: Only authorised institutional specialists can interpret legal, ethical and privacy obligations for the dataset.

Learning transfer: Conditional language helps learners distinguish may, must, cannot and only if.

Acceptance testing should confirm that the repository received the expected package and can manage it under the agreed profile.

Possible checks include manifest reconciliation, checksum verification, format identification, package-structure validation, malware scanning, metadata validation and opening or rendering selected objects. Record the actual checks, not a generic claim.

What to check

• Reconcile manifest
• Verify integrity
• Validate required metadata
• Record test results and tool

Record each ingest test with result, date, tool or rule version and evidence location. That permits later teams to distinguish a package that passed an older profile from one tested under a newer requirement.

Sample rendering can reveal obvious corruption, but it should not be described as complete content validation unless the method truly supports that claim.

Boundary: A successful ingest does not validate the research conclusions or every future use case.

Learning transfer: Test results teach students to separate system acceptance from scientific correctness.

A trustworthy handoff names missing files, unsupported formats, unresolved restrictions and validation failures.

For each exception, record affected object, risk, interim state, owner, action, due date and acceptance decision. Avoid hiding problems in a final free-text note.

What to check

• Assign exception ID
• Describe affected scope
• Name owner and deadline
• Record acceptance or remediation

Group exceptions by integrity, metadata, format, rights, security and documentation. Categories make risk visible without mixing technical and ethical issues.

A repository can accept a package conditionally. Conditional acceptance should name what is safe now, what remains blocked and who can authorise full release.

Boundary: Some limitations may be accepted rather than fixed; the authority and rationale still need a record.

Learning transfer: Exception writing turns a problem into a managed decision without pretending it vanished.

Close with receiver acceptance, preservation commitment, monitoring route, contact and any continuing depositor duty.

State what the repository accepted, when custody began, what services are included, how future integrity or format checks occur and how changes to access or ownership are handled.

What to check

• Record acceptance statement
• Name authorised acceptor
• Describe monitoring route
• Keep future contact current

The acceptance paragraph should be short enough to quote accurately: package ID, version, date, custodian, services and linked exceptions. Avoid burying the actual transfer beneath background narrative.

Schedule contact review because staff and project ownership change. A preserved dataset with an obsolete contact can become practically inaccessible even while every file remains intact.

Boundary: The note records an agreement at a point in time; policies, technology and legal conditions may later change.

Learning transfer: A good ending makes the next responsible person and action visible.

Students do not need professional authority to practise the underlying language. They can learn to define scope, annotate conditions, compare versions, rebuild a timeline, match a number to its unit and explain uncertainty without embarrassment. Parents can ask calm questions: What decision is this document supporting? Which sentence carries the strongest claim? What would make that claim false? Which source would you open next?

Use a three-pass routine. First, map the document: title, owner, audience, date, sections and decision. Second, trace one claim from source to conclusion. Third, explain the limit and next action. This routine strengthens comprehension, science, mathematics, humanities and workplace readiness because it turns English into an evidence tool.

A student should never imitate professional authority. The useful goal is to recognise when a text needs a qualified reviewer, current rule or official decision. Knowing when to pause is part of literacy.

A fictional facility prepares package IMG-2026-041-v1.2 containing original instrument files, open-format derivatives, calibration records, a plate map, analysis code, a readme and a machine-readable manifest. The transferor generates checksums before upload and records the instrument and processing versions.

The repository reconciles counts and sizes, verifies checksums, identifies formats and validates required metadata. One proprietary format is recognised but not renderable in the current environment. The object is retained as an original, paired with an open derivative and entered as an exception with a future characterisation action.

Access remains controlled under the study’s consent and data-use agreement. The repository accepts custody on the validation date, not the upload date. The note names the preservation package, accepted services, two representations, linked rights record, exception owner and future contact. A later reader can tell what exists, what passed, what did not, and who must act.

Bit-level integrity is necessary but not sufficient. A checksum can show that a file did not change, yet the file may remain unintelligible without software, units, code, permissions or a map to related objects. Preservation therefore operates at several layers: bits, file format, package structure, provenance, interpretation, rights and stewardship.

A strong handoff note does not claim to solve every layer forever. It records the current strategy, evidence and responsibilities so future custodians can continue the work.

A transfer finishes with no receipt

Treat the package as staged until authorised acceptance is recorded.

All checksums match

State the integrity conclusion narrowly; scientific and rights review remain separate.

Metadata names the investigator but not variables

Add domain description, units and relationships without exposing unnecessary personal data.

One format is unsupported

Preserve the original, document risk, create validated representations where approved and assign remediation.

The dataset is preserved but restricted

Record the access route and authority; do not call it unavailable or public.

The project ends

Update custodial contacts and continuing responsibilities so preservation survives organisational change.

Can every preserved object be connected to a research event?

Start from a sampled file and walk backwards to the acquisition event, instrument or source, participant or specimen code where authorised, protocol, parameter set and responsible role. Then walk forward to derived outputs and publications. If the chain breaks, decide whether metadata, provenance or an identifier map is missing. Do not fill the gap with memory that only one staff member holds.

Can a qualified future user distinguish observation from interpretation?

Raw signals, corrected values, normalised tables, classifications and final figures should not share ambiguous labels. The handoff should preserve the transformation path and show which artefacts are observations, quality-control products, analysis intermediates or presentation outputs. This distinction protects later reanalysis and helps reviewers avoid treating a processed conclusion as if it were an original measurement.

What happens if the current software disappears?

Record the original format, software and version, then consider approved open representations, export validation, environment information and documentation. Preservation strategy may keep both original and transformed forms because neither alone carries every property. The note should name known dependencies and monitoring rather than promising indefinite readability from one conversion.

Are access decisions separable from storage administration?

Repository administrators may maintain the package without being authorised to approve research reuse. Record the data steward, access committee or other authorised route; keep technical privileges narrower than policy authority. Where a request needs consent interpretation or agreement review, the handoff should direct the question to the correct body instead of allowing convenience to become permission.

Could the package be reconstructed after a disaster?

Check preservation copies, geographic or administrative separation, recovery responsibilities, encryption-key governance and documentation availability under institutional policy. A backup can support recovery but is not the entire preservation programme. The handoff should state the service actually accepted and avoid implying guarantees that the repository has not made.

What evidence will the repository produce later?

Plan future fixity results, format-risk reviews, migration records, access decisions and contact changes. A preservation package remains trustworthy when later actions extend the evidence trail. If monitoring discovers change or obsolescence, the repository should be able to identify affected objects, the governing decision and the new representation without overwriting the history.

Is a preservation handoff note required by NIH?

NIH requires compliant Data Management and Sharing Plans for applicable research, but this article describes a practical institutional record, not a universal NIH form.

Is uploading data to cloud storage preservation?

Not by itself. Preservation also needs governed identity, integrity checking, metadata, context, rights, monitoring and responsibility.

Why keep checksums?

They support a narrow, valuable claim that bytes have or have not changed under the named algorithm and comparison process.

Should raw and derived data be preserved together?

That depends on policy, agreements, scientific value and repository capacity. Their relationship should be documented even if custody differs.

Does preservation mean public access?

No. Data may be preserved under restricted, embargoed or controlled access.

Who accepts the handoff?

An authorised repository or institutional role under the approved process—not simply whoever receives an email or link.

• NIH Data Management and Sharing Policy
• NIH Writing a Data Management and Sharing Plan
• NIDDK Central Repository Data Preservation and Access Practices
• Why English? Writing a University Shared Research Resource Data Delivery Note
• Why English? Writing a University Shared Research Resource Data Disposition Record

Cycle-sensitive facts were checked against current official pages on 9 October 2026. Always reopen the authority’s live page before a real decision.

Ask an authorised data steward to verify rights and access, a repository specialist to verify integrity and preservation evidence, and a qualified future researcher to explain the data, method and relationships. Each viewpoint may reveal a different missing field. The exercise should use controlled copies and approved access, especially when human-subject or confidential data are involved.

Then record what remains dependent on living knowledge. If only one operator can interpret a parameter, locate a sample, explain a code or contact the appropriate authority, the package is not yet resilient to staff change. Capture the explanation in approved documentation, assign an owner and repeat validation before acceptance.