Story: Implement the synthetic market data journeys in ores.web

1. Goal
2. Status
3. Acceptance
4. Tasks
5. Decisions
6. Out of scope

This page documents a story in Sprint 27. It captures the goal, current status, acceptance criteria, and the tasks that compose it.

1. Goal

A person authors an FX price feed and an IR curve feed in ores.web, on the subjects the journeys name.

2. Status

Field	Value
State	DONE
Parent sprint	Sprint 27
Now	Nothing.
Waiting on	Nothing.
Next	Nothing.
Last touched	2026-10-13

3. Acceptance

The synthetic protocol has its TypeScript twin, and the BFF serves every synthetic entity, preview and feed operation the FX and IR curve journeys name.
The FX price feed screen authors the pair, the process, the GMM mixture and the sample paths on the record-screen framework.
The IR curve feed screen authors the identity, the short-rate process and its parameter values, the template ladder, and the shape and path previews.
A feed names its datum by its oresmd identity and derives the ORE key only for export.
The mixture has a simple mode with sliders for drift, volatility and jump frequency.

4. Tasks

Task	State	Start	End	Description
Scaffold the synthetic implementation story	DONE	2026-10-09	2026-10-09	Story scaffolding rides this task: documents, sprint wiring, and the scaffold PR.
Close M06, the synthetic TypeScript twin	DONE	2026-10-09	2026-10-09	Synthetic had no committed TypeScript protocol, so ores.web could not speak it. The twins are generated, the four operation surfaces are modelled so both sides generate, and the twin gate covers the component.
Give the BFF the synthetic routes	DONE	2026-10-10	2026-10-10	The BFF has no route for any synthetic subject, and the web reaches the bus only through the BFF.
Build the FX price feed screen	DONE	2026-10-10	2026-10-11	Journey 1: the pair, the process, the GMM mixture and the sample paths, on the record-screen framework.
Build the IR curve feed screen	DONE	2026-10-09	2026-10-12	Journey 2: the identity, the short-rate process and its parameter values, the template ladder, and the shape and path previews.
Name a feed by its oresmd URI	DONE	2026-10-11	2026-10-12	An FX feed names its datum by ORE key; it should hold the oresmd identity and derive the ORE key only for export.
Give the mixture a simple mode	DONE	2026-10-11	2026-10-12	The Qt FX editor has a simple mode, sliders for drift, volatility and jump frequency that write the mixture; the web edits only the raw table.

5. Decisions

The remainder is carried in Build the synthetic collection and model catalogue journeys.

One table, generic routes. The BFF serves the synthetic resources from one table (bff/src/synthetic.ts) over /api/synthetic/:resource, not a route set per screen. The nine generated resources share one CRUD shape, so a screen adds no BFF code to read or write them.
A save is one put_many. The server checks every row's version and writes the set in one statement, so a mixture or a ladder lands whole or not at all. A batch removal is unconditional, because delete_many refuses versions.
Read one row by its one-of filter, not by get. A definition's get takes parameter_name, which several process types share.
Shared catalogues are written from the system tenant only. The process types and the definitions live in the system tenant. The definitions are read only until their key names the process type, and the process types are writable from a system session alone.
Feed screens follow one standard. The FX price feed screen is the shape of every feed screen, recorded in the Feed screen standard: the list is the run dashboard; the process is edited as one set in a list with a dialog per part, with marked unsaved changes and one Save that asks the reason and offers a restart.
The engine sits with the process, and the server converts. The engine decides what a part's numbers mean, so it is chosen on the process tab, and a change asks the synthetic service to convert the draft (convert_fx_mixture). Quant logic that decides a written value lives on the server.
A running feed keeps its process. A feed reads its parts when it starts, so a save tells the person and offers to restart the feed.
The shared record parts take a store. RecordStore gives the record list, dialogs and history their routes, so a synthetic screen reuses the refdata parts.