User Journey: Import market data from an external feed

"I have a file of quotes and fixings from our data vendor. I want it in the platform, tagged with where it came from, and I want to know which rows were refused." The journey is done when the observations and fixings read in the market data screens and the person has read the counts and the warnings.

The actor is a market-data maintainer who holds marketdata::import:write, which in the seeded roles only the tenant administrator and super administrator hold. The trigger is a new vendor file, a daily fixing load, or a backfill after a gap. The journey starts with two files on disk and ends when the person has confirmed the stored counts.

The file must be in ORE's text shape: market.txt holds DATE<TAB>KEY<TAB>VALUE and fixings.txt holds DATE<TAB>INDEX<TAB>VALUE. A vendor that writes CSV or JSON needs a conversion outside the platform. No CSV, JSON or HTTP API feed import exists today. The ORE import writes to the source ore-import of the provider ore, with the kind replay. No live adapter consumes a vendor feed from a file.

1. Convert the feed to the ORE shape. The person, or a script the person runs, writes the two tab-separated files. The person checks the date format and the series keys.
2. Import the files. The person runs marketdata import --file market.txt --fixings fixings.txt --source <tag>. The system resolves each series, stores the observations and the fixings, and tags them with the source.
3. Read the counts. The shell prints the series, observation and fixing counts, the message, and any warnings.
4. Read a series. The person opens Market data, then the series or the evolution screen, and reads the imported points with their source.
5. Handle duplicates. If the file may repeat rows, the person passes --duplicates-are-errors. The system refuses the duplicate rows as errors and keeps the sections that had none.

The shell prints the counts and any warnings. The series and observations read with the source tag. The fixings read against their index. A curve that depends on the points can be bootstrapped.

A file that cannot be opened is refused before the import. A duplicate row is an error only when --duplicates-are-errors is passed, and the errors are listed per row. The reply may report success=false after some sections were already stored, and the shell still prints the counts it stored. A series that cannot be resolved is reported as a warning or an error, depending on the section. A refused write names the missing permission.

• A duplicate in one section must never discard a section that had no duplicate. The service keeps the clean sections, and the shell says so.
• A fixing must never be stored under the wrong index. The index is the key.
• A partial load must never be reported as a complete one. The counts are printed even when the reply is a failure.
• A quote must never be written into another party's series.
• The import must never invent a source tag. The person names it, or it stays empty.

The entry points are marketdata import, marketdata export and the market data screens that read the result. There is no upload screen and no vendor connector. The market watch screen shows the raw points and the exceptions, but it does not import.

1. No native CSV or JSON import. Every vendor file is converted to ORE text first. The conversion is outside the platform and outside its audit.
2. No vendor connector. No adapter consumes a vendor URL or a drop folder. A file adapter would announce itself as a source like any other.
3. No per-section result. The counts are totals and the errors are strings. Nothing says which series or fixing was refused and why.
4. No dry run. The person cannot see what would be stored before the write.
5. No import record. Nothing lists who loaded which file and when, beyond the source tag on the rows.

• Watch the market and clear its exceptions - what the person does with the loaded points.
• See what a failed family left behind - the same question for an ORE import.
• Retry a failed or interrupted import - after a duplicate refusal.
• Trade journeys - the trades a fixing prices.

• ores.marketdata.market_observation
• Document types

• Data exchange journeys - the group hub.