Story: Rework the market data feeds into a market data service with adapters — the remaining work

ores.marketdata owns the catalogue, the mapping, the ingest path, routing and metering. Adapters, including the simulator, publish vendor-id ticks over NATS and answer a demand set. Every simulated feed belongs to the system tenant and the system party, a party takes a provider by subscription, and no part of the system behaves differently because a source is simulated.

The story closes on the tasks it finished:

• Add the demo approvers and document the market data setup.
• Add a provisioning to ticks smoke check.
• Address the blueprint review.
• Audit the market data documents for the service.
• Bind a report to the published curve.
• Build the cut screens.
• Build the cut take and its authorisation.
• Build the cut data model.
• Build the published curve screens.
• Build the market data sources board and the subscriptions screen.
• Close the approval model gaps.
• Complete the publish policies.
• Give the cut families and values system labels, and fix the history.
• Decide a cut's authorisation and apply it.
• Decide the binding's place in the route architecture.
• Decide whether ticks are stored once for each source.
• Design the published curve screens and decide the publish model gaps.
• Design the bootstrapping screens.
• Design the cut's journeys and screens.
• Document the market data path.
• Fix the post-merge checks.
• Fix the system lookups and the approval read.
• Light the intraday reports on the LIVE cut.
• Make the demo tenant exercise the system.
• Make the existing market data screens correct.
• Make the demand self-correcting and visible.
• Name a curve pillar's market series.
• Name the publish subject and record who published it.
• Notify a person that a scenario is ready.
• Parse the engine log when a run fails.
• Port the market data cuts reference.
• Reconcile the binding stories and the market data docs.
• Record the trades per book on the provisoned config.
• Remove the committed session cookie.
• Repair the web after the feed rename.
• Retire the feed binding.
• Route the synthetic feeds into the ingest.
• Schedule a report from its own page.
• Schedule the catalogue when Acme is provisioned.
• Seed the ladder family and let it fail like the rest.
• Set the intraday frequencies a desk expects.
• Test the market data service in a non-system tenant.
• Use oresmd on the market data generation path.

• The intraday reports run at the cadences a desk expects, decided by the product owner on 2026-11-04 and stated in the catalogue, the pages and the live scheduler. The triple vol spot ladder and the surface vega ladder run hourly at every hour rather than inside the London day, because each costs a full sensitivity run and a desk reads the shape between the closes. The spot ladder runs every half hour and trades since last in every fifteen minutes, so neither is a definition that can never fire. The spike, strike and option maps keep the on-demand placeholder, and every other report keeps its cadence. The close twins do not move. See Set the intraday frequencies a desk expects.
• The ladder family is stated in the catalogue at every party and fails at the engine (2026-11-04). The product owner overruled the design's decision to hold it back until the report inputs and the volatility data arrive: a definition that produces no figure costs nothing to hold, and the list should show what the platform runs. Ten of the design's fourteen rows are seeded as fifteen definitions per party, because five of them run on both cycles, and they bind the sensitivity run settings a party already holds. Rows 11 to 14 stay unseeded on their market data. See Seed the ladder family and let it fail like the rest.
• A schedule is made by the one operation the shell calls, and a screen adds no schedule of its own (2026-11-04). The BFF relays schedule_report_definitions and unschedule_report_definitions on the person's own session and answers their count, their failed ids and their words, gated on the permission each operation checks — the definition's write to schedule it, its delete to take the schedule away. Activating an on-demand report writes the expression the job will fire on and schedules it in one call, because the scheduler reads the expression from the definition. A definition with no scheduler job is on demand, and so is one whose expression never fires, so the list and the page read one word. See Schedule a report from its own page.
• The tick store holds one tick for each source, owned by the system tenant, and the history read checks the subscription (2026-10-25). The per-party copy added 80% of the store on the measured tenant, and neither the usage recorder nor the delivery meter reads the store. See A source tick is stored once and entitled when it is read.
• Split from Rework the market data feeds into a market data service with adapters on 2026-10-24 at sprint 28 close. The acceptance above is copied from that story; its done tasks are recorded there.
• The route is the one consumer record (2026-10-24). The feed binding retires, with its two tables, its screen and its policies. A projection of the routes would keep two records for one fact and need a writer to hold them in step. This reverses the sprint 27 decision that consumption is a binding. Evidence and consequences are in Decide the binding's place in the route architecture.
• Closed on 2026-11-08 at sprint 29 close with its done tasks. The open tasks and the original acceptance moved to Rework the market data feeds into a market data service with adapters — the remaining work.