Preflight checklist
What problem does this solve?
Open Science captures the richest provenance in this product category — src/main/artifacts/provenance-repository.ts is 3,891 lines holding, per immutable artifact version: checksummed content, producer code, execution history, exact input references, environment inventory, producing message-branch context, and version-scoped reviewer evidence.
All of it is locked inside a private SQLite shape that only Open Science can read.
That undercuts the point. A collaborator cannot open it, a journal cannot archive it, a repository cannot index it, and a reviewer two years from now cannot inspect it without installing this application. Provenance that only one program can read is a log, not a research record.
There is currently no export path of any kind — no RO-Crate, DataCite, or comparable serialization anywhere in src/main.
Proposed solution
Export an artifact version, a session, or a project as an RO-Crate — the established standard for packaging research data with machine-readable provenance, already used by workflow and repository ecosystems.
A serializer over the existing provenance repository. No change to how provenance is captured; this is purely a read-side projection:
| Already captured |
RO-Crate expression |
| artifact version + sha256 |
File entity with contentSize, checksum |
| producer code |
SoftwareSourceCode |
| execution history |
CreateAction with start/end, agent, instrument |
| exact input references |
CreateAction.object |
| environment inventory + lock |
SoftwareApplication / attached lock file |
| message-branch context |
CreateAction provenance annotation |
| reviewer evidence |
AssessAction |
Two profiles are worth supporting: a lightweight crate (metadata + provenance, referencing data by checksum) and a complete crate (data included), because scientific datasets frequently exceed what is sensible to move.
The environment lock from the lock export/restore issue should be included when present — that pairing is what turns a describable result into a rebuildable one.
Alternatives considered
- A custom JSON export. Faster, and nobody else can read it. The entire value here is interoperability.
- Wait for deterministic reproduction. Backwards: a crate is useful the moment it exists, and every increment in reproduction quality improves it in place.
Additional context
#340 argued provenance should be a derived view over existing stores rather than a parallel capture log. This issue is the natural continuation on the read side: given the join exists, serialize it into a standard other tools already consume.
Prerequisite for DOI-minted deposit; also the correct shared substrate for any future Nextflow/Galaxy workflow export.
Part of #917 (preserve-the-backend blend plan). This proposal is additive: it does not change the ACP runtime, artifact/provenance store, notebook execution semantics, or the Prisma schema.
Preflight checklist
What problem does this solve?
Open Science captures the richest provenance in this product category —
src/main/artifacts/provenance-repository.tsis 3,891 lines holding, per immutable artifact version: checksummed content, producer code, execution history, exact input references, environment inventory, producing message-branch context, and version-scoped reviewer evidence.All of it is locked inside a private SQLite shape that only Open Science can read.
That undercuts the point. A collaborator cannot open it, a journal cannot archive it, a repository cannot index it, and a reviewer two years from now cannot inspect it without installing this application. Provenance that only one program can read is a log, not a research record.
There is currently no export path of any kind — no RO-Crate, DataCite, or comparable serialization anywhere in
src/main.Proposed solution
Export an artifact version, a session, or a project as an RO-Crate — the established standard for packaging research data with machine-readable provenance, already used by workflow and repository ecosystems.
A serializer over the existing provenance repository. No change to how provenance is captured; this is purely a read-side projection:
Fileentity withcontentSize, checksumSoftwareSourceCodeCreateActionwith start/end, agent, instrumentCreateAction.objectSoftwareApplication/ attached lock fileCreateActionprovenance annotationAssessActionTwo profiles are worth supporting: a lightweight crate (metadata + provenance, referencing data by checksum) and a complete crate (data included), because scientific datasets frequently exceed what is sensible to move.
The environment lock from the lock export/restore issue should be included when present — that pairing is what turns a describable result into a rebuildable one.
Alternatives considered
Additional context
#340 argued provenance should be a derived view over existing stores rather than a parallel capture log. This issue is the natural continuation on the read side: given the join exists, serialize it into a standard other tools already consume.
Prerequisite for DOI-minted deposit; also the correct shared substrate for any future Nextflow/Galaxy workflow export.
Part of #917 (preserve-the-backend blend plan). This proposal is additive: it does not change the ACP runtime, artifact/provenance store, notebook execution semantics, or the Prisma schema.