Version the study as a bundle of linked, immutable objects. Every execution, dataset, report and review should identify the exact intent, materials, methods, configurations and criteria it used.
Treat the study as a bundle, not one editable document
An outsourced study is governed by more than its protocol. Its meaning also depends on the research question, material and cell identities, laboratory assignment, method, acquisition settings, analysis plan, supplied criteria, datasets, deviations and review decisions. If those dependencies change independently while one document keeps the same name, a later reviewer cannot know which combination actually governed the work.
NIST's Research Data Framework treats provenance, original authoritative copies, version identification, derivative products and timestamps as connected parts of research-data management. SingularCell turns that general principle into a product rule: release a study-bundle version that points to the exact version of every dependency, and issue a successor bundle whenever a locked dependency changes.
- Give the study bundle a stable identifier and immutable version
- List every locked object version inside the bundle
- Record who released the bundle and when it became effective
- Link the successor bundle to the version it supersedes
- Never silently replace a released dependency
Freeze intent, design and responsibility before execution
Start by versioning the decision the study is intended to inform, its research-use boundary, conditions, controls, timepoints, experimental units, replication declarations and scientist-supplied analysis criteria. Also identify the sponsor owner, receiving laboratory, responsible study contact and any delegated site or phase. A change in purpose or ownership can alter interpretation even when the assay instructions appear unchanged.
FDA and OECD rules for regulated nonclinical studies provide a bounded illustration: a written protocol or study plan identifies purpose, test system, design, measurements, records, responsible parties and dates, while changes are documented rather than absorbed into an unnamed latest copy. Those rules do not automatically govern an ordinary research-use project; SingularCell uses the record pattern without claiming GLP compliance.
- Research question and intended decision
- Permitted use and explicit excluded uses
- Conditions, controls, timepoints and experimental units
- Analysis plan and scientist-supplied criteria
- Sponsor, laboratory and delegated responsibility scopes
Version biological identities and execution context
The protocol version is not enough if the material, cell system or measurement context can move underneath it. Record separate versions for the test material or construct, exact cell line or model, source and state, critical reagents, sample manifest, site-method assignment, instrument, software and acquisition configuration. Each record should carry its source, relevant lot or state, effective time and supporting evidence reference where supplied.
The trigger is not every cosmetic edit. Create a new released version when a changed identity, source, lot, state, preparation, site, method, instrument, software version or setting could affect execution, reconstruction or interpretation. The software may flag the difference for review. It must not decide that two lots, methods, instruments, sites or biological states are equivalent.
- Material ID, declared composition reference and preparation state
- Exact cell model, source, bank or lot, passage or state and identity evidence
- Critical reagent and reference-material identifiers and lots
- Laboratory, subcontractor and accepted method version
- Instrument, software and acquisition-template versions
Separate a planned amendment from an observed deviation
A planned change and an unplanned departure are different events. OECD GLP principles distinguish a study-plan amendment from a deviation: amendments are justified and approved, while deviations are described, explained, acknowledged, dated and maintained with the study records. The distinction is useful outside GLP because it prevents a departure discovered during execution from being rewritten as though it had always been the plan.
For a research-use handoff, record the event type, affected versions, old and new values, requestor or observer, time, reason, proposed disposition and accountable assessment owner. If execution has already occurred, link the deviation to the affected run, samples and returned data. Logging the event makes it inspectable; it does not determine whether the scientific impact is acceptable.
- Classify the event as amendment, deviation, correction or invalidation
- Preserve the prior value and the proposed or observed value
- Record who requested or observed it and when
- Link every affected run, sample, dataset and report
- Leave scientific-impact disposition with a named qualified reviewer
Bind raw data, processing and reports to exact inputs
Raw data, processed data and reports are different objects. A raw-data package should retain source files, hashes, acquisition metadata and sample-to-run mapping. A processing run should identify the exact raw inputs, code or pipeline version, configuration, software environment, executor and generated outputs. A report should point to the precise study bundle, datasets, analysis plan and criteria it used.
W3C PROV provides a useful vocabulary for this graph: an activity can use an entity and generate another; an entity can be derived from or revised from another; agents can be associated with activities or attributed responsibility for entities. These relationships support reconstruction. They do not prove that the source assertion is true, that the transformation is scientifically appropriate or that the conclusion is valid.
- Keep raw and processed files as distinct object types
- Hash and identify each supplied source package
- Record pipeline, code, configuration and environment versions
- Link every output to the activity and exact inputs that generated it
- Bind each report to its governing bundle and review state
Correct reports without deleting their history
A correction should create a linked successor rather than overwrite the released report. OECD GLP principles state, in their regulated scope, that corrections and additions to a final report take the form of amendments that specify the reason and are signed and dated. W3C PROV similarly distinguishes revision and invalidation relationships from an unqualified replacement.
SingularCell should retain the original report, its status, the correction event, the responsible person, the reason, the replacement version and the dependencies affected. A withdrawn or invalidated item remains discoverable in the history but is not presented as current. A review attached to the old version does not automatically transfer to the corrected one; the new scope must be reviewed explicitly.
- Freeze every released report version
- Create a successor for a correction or re-analysis
- State the reason and responsible person
- Mark superseded, withdrawn or invalidated status visibly
- Require a new bounded review when dependencies or conclusions change
Make every change record answer seven questions
A useful change record answers: what object changed, from which version, to which version, why, by whom, when, and which downstream work depends on it. Add the review scope and disposition when someone assesses the change. Store the content hash and schema version so systems can verify byte-level identity and interpret the fields consistently across organisations.
Do not call this record validated, compliant or ready merely because every field is present. A hash can show that bytes match a previously recorded value; it cannot prove that the original entry was accurate. A named review can show who reviewed which version for a stated scope; it cannot support a broader scientific, operational or regulatory conclusion than the reviewer actually made.
- What changed and which object is affected?
- What are the prior and successor version identifiers?
- Why was the change made or observed?
- Who created, assessed and approved the recorded action?
- When did it occur and become effective?
- Which runs, data, analyses, reports and reviews depend on it?
- What remains unresolved or outside the review scope?
Primary sources
Material claims were checked against the organisations responsible for the guidance or measurement work.
- eCFR — 21 CFR 58.120, Protocol ↗United States Government Publishing Office and National Archives · A regulated-context example of protocol content and documented, signed, dated changes with reasons.
- OECD — Good Laboratory Practice: Principles and Guidance ↗Organisation for Economic Co-operation and Development · Regulated-context distinctions among study plans, amendments, deviations, retained raw data and final-report corrections.
- NIST — Research Data Framework, Version 2.0 ↗National Institute of Standards and Technology · Research-data lifecycle, provenance, authoritative copies, version identification, derivatives, timestamps and responsible roles.
- W3C — PROV-O: The PROV Ontology ↗World Wide Web Consortium · Standard relationships for entities, activities, agents, generation, use, derivation, revision, attribution and invalidation.
Limitations
- This article is documentation and provenance guidance, not a biological protocol, change-impact assessment or acceptance decision.
- FDA and OECD examples are bounded to their regulated contexts and do not make an ordinary research-use study GLP, GMP, Part 11 or FDA compliant.
- Versioning and hashes improve reconstruction but do not prove source accuracy, scientific validity, material identity or data authenticity.
- Only qualified reviewers with context-specific evidence can assess protocol suitability, laboratory capability, method or site equivalence and the impact of a change.
See the handoff as a working system.
Explore one synthetic study from research question through capability comparison, returned results and review-required evidence.