User Journey: Import one dataset in isolation

"I have a corrected conventions.xml or curveconfig.xml and I want that one dataset replaced, not the party's whole configuration." The journey is done when the named dataset is stored, a report reads it, and nothing else in the party changed.

The actor is a reference-data maintainer who holds refdata::conventions:write for a conventions file, or the run-document write for a curve file. The trigger is a wrong day count, a moved calendar, a bad curve pillar, or a vendor file that corrects one family. The journey starts with one file and ends when the person has read the affected family and confirmed the rest is untouched.

1. Choose the dataset. The person decides whether the file carries conventions, curves, today's market or pricing engines. The choice is the file, because ORE's run document names each document separately.
2. Prepare a minimal run. The person builds a small input directory with ore.xml naming only that one file, or takes an exported run directory and removes the documents this import must not touch.
3. Import the file. The person runs ore import-run <report_definition_id> <src_dir>. The system parses the run document and the named file, binds the document under the report definition, and saves it.
4. Check the one family. The person opens the conventions screen or the curve screen and reads the rows the file carried.
5. Check that the rest held. The person compares another family or another curve configuration with what it held before.

If the fix is a single convention row rather than a file, the person edits it on the conventions screen and saves it through refdata.v1.<plural>.put. That is the authoring journey, not this one.

The run import prints the stored file. The affected family or curve reads the new values with a new version and a change reason. The other families, curves, market data and trades keep their versions.

A parse error refuses the import before any write. A file the run document names but the directory does not hold is refused. A save that fails after an earlier document stored leaves the earlier document stored. The run import does not undo conventions on a later failure. A conventions save writes each family in its own write, so a failure partway leaves the earlier families written. Nothing in the shell names the family that failed.

• The import must never delete the datasets the file omits. The save adds and replaces, and tenor basis swap leg forms are the one thing it closes when they are omitted.
• The import must never write a family the person did not choose. That is why the run document carries one file.
• The import must never leave another dataset's rows altered by a side effect of the save.
• The import must never store a curve against another party's run.

There is no import screen. The entry points are ore import-run and ore export-run. The conventions screen can save one convention but cannot accept a file. There is no shell verb that stores a lone conventions or curve file.

1. No standalone file import. Every dataset travels in a run directory. The person builds a fake run to import one file.
2. No family scope. The person cannot say "store only the swap family" and let the server take the rest of the file as unchanged context.
3. No per-family result. The shell reports the file, not the family or row counts.
4. No merge preview. The screen cannot show which rows would be replaced before the save.

• Onboard a party with its conventions and portfolio - the same mechanism for a whole party.
• See what a failed family left behind - when the one family refuses.
• Define the conventions for an instrument - the screen path for one row.
• Retry a failed or interrupted import - when the import stops.

• Conventions journeys
• Reference Data

• Data exchange journeys - the group hub.