Task: Implement synthetic data generation against the new market data model

• A feed publishes a market_tick (oresmd_uri quote URI, value, observation_time, source) on synthetic.v1.tick.<source> (or the sandbox prefix).
• ores::marketdata::service::app::feed_ingest_loop subscribes to every producer's ticks. refresh() caches the enabled feed_binding=s by source; each binding is one consumer. =persist() runs per binding:
  • derives the series URI with oresmd_uri_codec::write(series_of(datum));
  • creates the market_series row if the tenant+party+series URI has none, with series_subclass from series_classifier and market_series_asset_class rows;
  • writes one market_observation with series_id, observation_datetime, value, source and the point oresmd_uri;
  • drops a tick from a source with no enabled binding, one warning per source.
• The synthetic feed_controller auto-creates the feed_binding for a bound feed, and a sandboxed feed never gets one.

So acceptance 1 and most of 2 already hold on paper. What is missing is proof and the provenance axis.

1. Nothing says generated. market_series.derivation_kind defaults to OBSERVED, and the OBSERVED seed's own description says it is the default "for every existing producer (synthetic, vendor feeds)". The model therefore treats a synthetic series as observed, because observed currently means "directly published, not derived", not "real". There is no axis that says real versus generated. market_observation carries only source.
2. No test proves the persist path. app_tick_plan_tests covers routing, and feed_controller_tests covers start/stop, but nothing drives a tick through persist() and reads back the rows.

D1. Provenance is a second axis, not derivation_kind. Decided. derivation_kind answers "was this published or computed?" (OBSERVED vs IR_CURVE_BOOTSTRAP, CRM_DERIVATION), and a synthetic feed is genuinely published, so calling it a derivation would break that meaning. Real-versus-generated is a separate axis about the producer, carried by the feed_binding and readable from the series an observation belongs to. Decided: a producer_kind reference-data code table (VENDOR, SYNTHETIC) alongside derivation_kind, referenced by feed_binding and market_series, listable in the UI and validated by the seed rather than free text.

D2. One pipeline, asset class only where it is real. Decided. The generator pipeline is common to every asset class, and IR and FX must not have separate paths with spurious differences. An asset class may vary only where the difference is genuine: the shape of its datum, its config fields, and the process that produces its numbers. Everything around that — the feed abstraction, the tick, the oresmd identity, the subject, start and stop, the producer kind, the ingest, the provenance, the series and observation write — is one path parameterised by the config, not a branch per asset class. Any existing FX/IR fork in the pipeline is either justified against this rule or removed.

D3. Work in slices. Slice 0 is done: the fork inventory is at evidence/asset-class-fork-inventory.org — 24 forks, 13 spurious, 11 genuine. It changed the order, because it found that binding auto-creation is unreachable from the live control plane (feed_controller::start(ore_key, GMM) is FX-only with no production caller, and it is the only caller of ensure_feed_binding), and that binding_mode is not expressible for IR, so a sandboxed IR curve publishes on the ingested subject.

• 1. One producer subject, mode-aware for every kind: collapse the FX synthetic_producer_subject(source, mode) and the IR hardcoded synthetic_tick_subject(source), thread binding_mode into the IR build input and through the one add() / start() path. Fixes the IR sandbox bug; test both subjects.
• 2. Binding creation on the one live start path, gated by binding_mode, deleting the FX-only ad-hoc start.
• 3. The producer_kind from D1, on the shared binding and the shared persist path.
• 4. The persist() integration test: series and observation written, an unbound source dropped.
• 5. Collapse the remaining spurious forks the inventory lists: the feed_config_handler kind resolution and duplicated start/stop, the duplicated vintage scan, the duplicated tick clock, the duplicated simulate/preview envelope, and the common config plumbing fields.
• 6. The curve bootstrap consumer check.

mode)= in ores.synthetic/api/include/ores.synthetic.api/feeds/producer_subject.hpp serves FX and IR; the IR build input and make_ir_curve_feed carry the mode, and the auto-start path, feed_config_handler and folder_feed_control_handler pass the configured mode instead of a default. IFeed gains nats_subject() so the subject is assertable at the public seam. IR sandboxing is fixed.

The ores.synthetic.service.tests and ores.synthetic.core.tests binaries refused to start while the local database schema fingerprint (0e5e94985734f233) was behind the checkout (416d79146b6d63e3). The database was recreated on 2026-10-06 (fingerprint now 416d79146b6d63e3) and services restarted. ores.synthetic.service.tests now passes, so the renamed feed_controller subject cases run and pass. ores.synthetic.core.tests has one unrelated failure from the fresh database, in feeds_fomc_curve_resolution_tests.cpp:92: the country import inside its fixture cannot find the ISO_3166_1_ALPHA_2 coding scheme, so a populate step the fixture depends on is missing after db recreate -k. That is an environment gap, not this change, and it needs capturing as its own task before the service-level tests are dependable.

unreachable; the only caller of ensure_feed_binding was an FX-only start(ore_key, GMM...) with no production caller. Both live paths, the config-driven add() and the on-demand start(IFeed), now call one bind_feed(source, mode, token) after releasing the mutex. It binds when the mode is bound and a caller token exists, and does nothing for a sandboxed feed or an internal start with no session. The marketdata round-trip sits behind a one-method feed_binding_store seam, so the rule is tested without a live service. The dead path and the should_ensure_feed_binding two-mode contract it needed are deleted.

Open decision from slice 2: boot auto-start passes an empty token because no end-user session exists, so it still creates no binding. A binding for an auto-started feed must come from provisioning, or from a service-account identity decision about whose tenant and party the row lands in. Neither is settled and both are product calls, so they are recorded here rather than guessed at.

table holds VENDOR and SYNTHETIC. feed_binding carries it, defaulting to VENDOR, and the synthetic binding store sets SYNTHETIC. The ingest stamps the series it creates from the binding and leaves an existing series alone. Everything is generated from the org models, including the SQL and the shell surface for the new entity. The codegen sweep reports that no file this branch touched would change. All nine affected suites pass, including the generated producer-kind eventing test.

against the database. feed_ingest_loop::handle_tick holds the whole of what the loop does with an arrived tick and returns the drop reason the caller observes, so a test reaches the real persist through the real path; on_tick only decodes and delegates. A bound synthetic tick is driven through it and the rows are read back by oresmd URI, with the series carrying producer_kind SYNTHETIC and the observation carrying the point URI, source, series id and value. A tick whose source has no enabled binding returns unbound_source and leaves no series. The codegen sweep stays clean.

them spurious. Each spurious one is now collapsed or captured.

• Collapsed. The producer subject and binding mode fork, one builder for every kind (slice 1). The FX-only ad-hoc start(ore_key, GMM...) and the vintage scan it alone duplicated, deleted in slice 2, which also removed the two-mode should_ensure_feed_binding contract that existed only to protect its default argument.
• Captured. The remaining spurious forks are the control-plane duplication around the producer registry: the per-asset feed_config_handler start and stop with kind resolved by probing the FX then the IR repository, the FX-shaped and triplicated vintage lookup, the duplicated tick clock, the duplicated simulate and preview envelope, the factory rebuilt at four call sites, and the common config plumbing fields repeated across the two generation-config entities. They are one coherent piece of work and are captured as Collapse the remaining synthetic control-plane forks, so this task can close without leaving them unrecorded. Every one is listed with its file and line in evidence/asset-class-fork-inventory.org.

and here is the evidence rather than an assertion.

• The ingest writes one market_observation per bound consumer whatever the producer kind is, because persist takes the binding and the datum only; nothing in it branches on the asset class or the kind.
• The curve bootstrap reads observations through the same market_observation_repository on the same table, so a synthetic series and a vendor series are the same shape to it. That is what makes the one-pipeline rule pay off here: the consumer needs no synthetic case.
• The generated provenance is readable from the series: the slice 4 test reads a series written by the ingest back from the database and asserts producer_kind = "SYNTHETIC", and =market_series carries the field for every consumer to read.