Export for repository

This is stage 7 of the pipeline, the final write. It takes the human-finalized metadata records in the institution's output/ directory and produces, for each one, a record in the target repository's native format plus a provenance sidecar. It is the only stage that leaves the toolkit's internal record shape and speaks the receiving platform's own language.

Export derives; it does not mutate. The canonical record in output/ (conforming to ../../schemas/metadata-record.schema.json) stays as the source of truth. The native file and the sidecar are derivations of it. If an export looks wrong, you fix the canonical record (or the adapter) and re-derive, rather than editing the exported file in place.

Where it sits in the pipeline

Stage 6 is what feeds this one. A record arrives here only after a cataloguer has reviewed it and the disclosure note's human half is filled. Export reads that state and refuses anything that has not cleared review. See the export gate below.

Inputs

• The finalized records. One JSON file per work in the adjacent workspace's output/, each conforming to ../../schemas/metadata-record.schema.json. Export reads fields, collection_context, provenance, disclosure_note, and record_review.
• The application profile (../../schemas/application-profile.schema.json), from the adjacent workspace. target_schema tells you which descriptive standard the values are expressed in (for example Dublin Core, Dublin Core + VRA Core, PBCore). The platform and its export format are an operator choice at run time, named in the user's prompt or the run config, since one descriptive schema can target more than one platform.
• The run manifest(s) (../../schemas/run-manifest.schema.json) that produced the records, joined by provenance.run_id. The sidecar pulls the models-per-role, prompt versions, and pass-rate outcome from here.

The export gate

A record is eligible for export when both hold:

1. It is human-finalized. record_review.status is accepted or edited. Both are finalized: an accepted record needed no change, an edited record was corrected by the cataloguer and is equally ready for the catalog. A record with status pending is still awaiting review and is not exported; a record with status rejected is not exported. Do not gate on record_review.passed: passed is the improvement loop's needs-no-modification metric, computed for the pass rate, and an edited record has passed false while being fully ready to ship. Gating on passed would silently drop every record a cataloguer carefully corrected.
2. Its disclosure note is complete. The disclosure_note names both the AI assistance that drafted the description and the human who finalized it, with no remaining [cataloguer] or [date] placeholders. The completion happens at stage 6; export verifies it and refuses a record whose human half is still unfilled, because the disclosure note is part of the record's trustworthiness. See ../../docs/provenance-and-disclosure.md.

Records that fail either condition are not exported and are counted as awaiting review in the summary. Export never completes a disclosure note itself and never flips review state; if a record is not ready, it returns to stage 6 for the cataloguer to finish.

What every export carries

Two things travel into every target format, whatever the platform:

• The disclosure note, written into the field the target platform uses for a source-of-description or general note. This is the PCC-MARC-588-style statement that AI assisted the description and a human finalized it. Placing it in the record itself, beyond its presence in the sidecar, is what keeps the institution's catalog standards-aligned on AI disclosure from the first record. The exact destination field is named per platform below.
• The collection context. collection_context.is_part_of, collection, and series are written into the target schema's relation structure so the receiving repository understands the work as a member of its collection rather than a free-standing item. In Dublin Core targets the immediate parent maps to dcterms:isPartOf, with collection and series expressed through the corresponding relation and collection elements. For archival and hierarchical-bibliographic targets the arrangement is expressed through the finding-aid or relation structures those schemas already model. Carrying the membership that intake captured into the exported record, rather than collapsing it out, is the export half of hard rule 7. See ../../docs/collection-context.md. [verify] Confirm the MODS and EAD relation element names against the chosen target profiles before relying on them.

Per-value evidence (confidence, basis, authority_status) is internal review state and is not written into the descriptive record by default; the authority_uri confirmed at stage 5 is, since a resolved URI is descriptive metadata the repository wants. An institution that wants confidence carried into a local field declares that mapping in its profile.

Target formats by platform

Read target_schema from the profile, take the platform from the run config or the operator's prompt, and write through the matching adapter. The descriptive values are already expressed in the target schema by the time they reach this stage; the adapter's job is to serialize them into the platform's ingest format and route the disclosure note and the relation fields to the right place.

A platform whose adapter does not yet exist is a contribution opportunity. A new platform adapter that any institution could use is a generalizable improvement and contributes upstream; a local column-mapping quirk specific to one institution's work types stays in the adjacent overrides/. The same generalizable-versus- domain test that governs every other change governs adapters. See ../../docs/architecture.md for the repository-agnostic export design.

The provenance sidecar

For each export run, write a provenance sidecar alongside the native files. It is an operator artifact in JSON (matching the repo's record format), not a separately schema-validated record, and it is how the export stays auditable after the native file has been ingested into a platform that may flatten or drop the toolkit's provenance. It assembles fields that already exist on the canonical record and the run manifest; it invents nothing.

Per exported record, carry:

• item_id and the path of the native file written for it.
• The provenance envelope from the record: generated_by, model_role, prompt_version, generated_date, run_id, local_only, human_reviewed. local_only: true carried here is what proves a sensitive-collection export was generated by a local model with nothing sent to an external API.
• The completed disclosure_note, with the reviewer and review date from record_review.
• The target_schema, the platform, and the export format the record was written in.

Per run, carry an export manifest header: the source output/ directory, the count exported and the count still awaiting review, the target schema and platform, and a timestamp. Where run_id joins to a run manifest (../../schemas/run-manifest.schema.json), the sidecar references it so a reader can trace each exported record back through the run to the models per role, the prompt versions, and the pass-rate outcome of the run that produced it.

Procedure

1. Resolve the target. Read target_schema from the profile and the platform and format from the run config or the operator's prompt. Select the matching adapter.
2. Load and filter. Read the records in output/. Partition them by the export gate above: eligible (finalized and disclosure-complete) and awaiting review (pending, rejected, or with an incomplete disclosure note). Export only the eligible set.
3. Serialize each eligible record through the adapter: map the descriptive fields to the target schema's elements, route the disclosure note to the platform's note field, and write the collection context into the relation structure.
4. Write the native files to the export destination (for example export/bulkrax/, export/dc/), without altering the canonical records in output/.
5. Write the provenance sidecar for the run.
6. Summarize: how many records were exported, to which platform and format, and how many are still awaiting review, naming the latter so the cataloguer can finish them.

Usage example

This is sample user prompt #8 from the initiative's operator curriculum, the standards-conformant export with provenance:

Take all human-reviewed records in ./output/telegrams/ and export them as a Bulkrax
CSV for our Hyku instance, including the PCC 588 disclosure note in the appropriate
field. Also write a Dublin Core XML copy to ./export/dc/ for our records. Summarize
how many items were exported and how many are still awaiting review.

How the skill handles it:

• Reads ./output/telegrams/, and the application profile for target_schema.
• Applies the export gate: records with record_review.status of accepted or edited and a complete disclosure note are eligible; pending and rejected records are held back and counted as awaiting review.
• Writes a Bulkrax CSV for the Hyku instance, mapping each field to the work type's properties, the disclosure note to the note field, and collection_context.is_part_of to the parent or collection relationship.
• Writes a Dublin Core XML copy to ./export/dc/, with the disclosure note in a dc:description note and the parent in dcterms:isPartOf.
• Writes the provenance sidecar for the run.
• Reports the count exported (per format) and the count still awaiting review, naming the records held back.

Related

• ../../docs/architecture.md: stage 7 and the repository-agnostic export design.
• ../../docs/collection-context.md: preserving the hierarchy through export.
• ../../docs/provenance-and-disclosure.md: the disclosure note and the provenance envelope.
• ../../schemas/metadata-record.schema.json: the input record.
• ../../schemas/application-profile.schema.json: the target schema and required fields.
• ../../schemas/run-manifest.schema.json: the run the sidecar references by run_id.