Story: Add proper curve support to ores.marketdata

Four things, and the tree already holds three of them under other names.

• Identity: which curve this is. market_series is already the identity of a term structure; the oresmd URI is the name. The seeded example is oresmd://ir/USD?type=series&instrument=discount&quote=rate&curve_id=USD-SOFR-FOMC ((marketdata_market_series_fomc_populate.sql)). There is no instrument_type::curve in code: the only instrument_type enum is ORE's own MarketDatum list (api/include/ores.marketdata.api/datum/ore_types.hpp), and the {fixing, curve, quote, vol} enum is a design-file fiction. A curve is named by curve_id in the URI today, not by an instrument type.
• Points: the pillar-to-value map. These are market_observation rows. The point identity is the oresmd_uri; the observation table has no point_id column (the design file draws one; the model does not). The pillar's tenor lives inside the URI.
• Build: when the curve was built against which source, and by which recipe. This is the part that is only half present. market_series carries derivation_kind and derivation_config_id/version; observation_lineage carries, per point, derivation_config_id/version, source_as_of and source_series_ids. What is missing is a reference date and a build kind, and a build identity that groups the points of one build.
• Recipe: how to build it. This lives in ores.refdata as ir_curve_bootstrap_config (family role, discount curve for a projection, interpolation, day count, tenor convention, split tenor) plus ir_curve_bootstrap_pillar rows. Its output_series_id and the pillars' tenor codes are soft references into other components.

The first investigation read the build as entirely absent. It is not: observation_lineage is written by republish() beside every output observation (curve_republish_service.cpp:365-366) and already answers "what was this built from, by which recipe, and against what as-of". A build header therefore does not have to invent provenance; it has to group the points of one build and add the two facts lineage lacks, reference_date and build_kind. That is a much smaller table than the sprint 25 design assumed.

The sprint 25 curve_point design draws a point_id column. The shipped observation table has none; the point identity is the whole oresmd_uri. Any curve design either reads the pillar identity out of the URI or adds a real =point_id=/tenor column. The first is free; the second must be justified.

Three shapes are available. The recommendation is the first, with the third held open until a journey proves it.

1. Keep the series as the identity, add a build header, keep the points as observations. A curve_build row names the output series, the reference_date, the build_kind, the recipe (config id + version) and the source_as_of; the points stay market_observation rows whose observation_datetime is the reference date and whose oresmd_uri is the pillar. This reuses bitemporality, versioning, row-level security, eventing, shell units, the protocol and the TypeScript twin, and adds one small table. It matches what republish() already writes, so no data has to move.
2. A curve_point table beside curve_build. The sprint 25 design. It buys an explicit point-to-build link and a place to hang point-level trustworthiness fields, and it pays for it with a second bitemporal, versioned, evented, shell-served table that duplicates the observation stack. Justified only if a consumer needs point sets that are independent of the series' own history, such as two builds compared point by point.
3. A curve entity distinct from market_series. Rejected as the starting point: it duplicates the identity, versioning and history the series already owns. The series is the term structure; a curve is a series whose points are pillars.

The deciding input is what a consumer does with a curve, which is what the journeys are for. The design deliberately stops before curve_point and lets the journey work decide whether it is earned.

The relation is real but undeclared today, in three places.

• The recipe side. ir_curve_bootstrap_pillar.start_tenor_code and .end_tenor_code are undeclared soft references to refdata_tenors: no foreign key, and the only database check validates curve_role_code, not the tenors. The engine resolves a pillar by end_tenor_code -> tenors_by_code -> resolution(convention) -> anchor + offset [+ schedule steps] -> date (tenor_resolution.cpp:151-222), and the end tenor doubles as the point_id the resolver reads the quote under (curve_republish_resolver.cpp:90-92). A typo in a tenor code is a runtime throw, not a save-time refusal.
• The point side. The observation's oresmd_uri carries the term coordinate (datum::term: period, date, fx_tenor or continuation), and the oresmd term field is the canonical datum-side name for a tenor. The two vocabularies join only by string at the pillar bridge; nothing checks that the URI's term is the pillar's tenor.
• The gaps. Tenor resolution never rolls for a business day (the conventions carry no calendar column), so a pillar that lands on a holiday is not adjusted; split_tenor_code is stored but read by no consumer logic; and dataset_family_role=FUNDING/PROJECTION is the one role vocabulary that is live, while refdata's curve_role is hard-coded in the engine and oresmd's curve_role is inert outside the synthetic feed's conflict check.

The recommendation is to make the pillar's tenor a checked reference to refdata_tenors, and to carry that same tenor code on the curve's points so a reader can group by tenor without parsing the URI. The business-day gap and the split tenor are separate defects, not part of the representation.

The tree has no market-data journey group and no journey that owns a curve; the closest analogues are journey_keep_a_holiday_calendar_right (rules, then a derived artefact consumers read) and journey_add_or_correct_a_currency (entity with owned child panels and history). Curve creation, review and consumption have no owner, and the journey-extraction task for marketdata is still BACKLOG. The candidates a journey pass should settle, one person and one goal each, are:

They settle the model because each names an operation the server must serve: a build journey needs a build, a comparison journey is what earns curve_point, and a provenance journey decides which of curve_point_provenance's fields are worth storing. They also force the vocabulary question, because the actor classes in the journeys are TenantAdmin and Operations today and neither is a rates quant.

• The curve-snapshot reads are unauthenticated: curve_snapshot_handler checks no permission and no curve-snapshot code is seeded (iam_permissions_populate.sql). This is a W02-class defect and belongs in its own capture.
• The recipe's tenors are unvalidated at save time, as above.
• CUBIC_SPLINE is recognised by the engine and throws; IMM_ROLL is superseded and throws.

1. Agree the journey catalogue above with the owner (J08 of the extraction standard), then run the marketdata journey extraction, reading the legacy CurveBuilderWorkbench from git show af67db3062^:projects/ores.qt/....
2. Let the journeys choose between build-header-only and curve_point, and write the chosen shape into the target model before any table is added.
3. File the curve-snapshot permission defect and the tenor-validation defect as captures; neither waits on the representation decision.
4. Keep the ORE handoff out of this story, as it already is; the lossless export is the second journey's consumer and its own story.

A curve is a market_series whose oresmd URI names it. Its points are market_observation rows of that series. Its inputs are per-point observation_lineage rows. Its recipe is the refdata config and its pillars. None of this needs a new key.

The point-to-tenor hop is the one that has no column. That is deliberate: the component removed its decomposed key columns and made the URI the single identity, and the model says a reader that wants the key's parts reads them through oresmd_uri_codec rather than off a row (ores.marketdata.market_series.org). Adding a tenor column to market_observation would reverse that decision, and it would pollute a generic time-series table with one facet's coordinate. The relation is instead carried where it is authoritative: by the recipe's pillar, whose tenor must be validated (see below), with the point's coordinate equal to it by construction (curve_republish_service.cpp passes point.point_id, the end tenor, to datum_at_point).

The facts a build needs are already stored, or are derivable:

A build is therefore the (series, observation_datetime) slice of a curve series' observations, and two builds are told apart by that slice, by the bitemporal version within a slice, and by the recipe version. No table is needed to represent that, and adding one would denormalise a fact the observation hypertable already holds: the table is append-only, partitioned on observation_datetime, carries no audit payload, and gives identity by key. That is the shape a data-oriented model wants for the points.

The cold tables the requirements do imply are two, and neither is a second representation of the points:

• the shape tables, which state the object's axes and their ordered values so a hole is a hole (see Where is the shape? below), and
• the per-point provenance annex, keyed by the point and holding no value (see Manually keyed points below).

Both are cold data split away from the hot row, which is what the data-oriented criteria ask for.

One consumer type would earn a table: a journey that treats a build as an object in its own right, with a state, a reviewer or a sign-off, rather than as a slice of a series. The prior Qt surface had exactly that shape, Build & Diagnostics then Publish, and the review/sign-off task is still a recorded intention. If that journey is agreed, the table is small and cold, and it joins without touching the points:

ores_marketdata_curve_builds_tbl
  id               uuid      -- surrogate key
  tenant_id        uuid      -- row-level security
  party_id         uuid      -- ownership, natural key part
  version          integer   -- bitemporal version
  valid_from       timestamptz
  valid_to         timestamptz
  series_id        uuid      -- FK -> ores_marketdata_market_series_tbl(id)
  reference_date   timestamptz  -- the instant the curve answers at; the join key
  build_kind       text      -- BOOTSTRAP | DERIVED | IMPORTED, validation fn
  source_as_of     timestamptz  -- when the inputs were observed
  -- the standard record provenance: modified_by, performed_by,
  -- change_reason_code, change_commentary
natural key:  (party_id, series_id, reference_date, build_kind)
unique index: (tenant_id, party_id, series_id, reference_date, build_kind) current only
index:        (tenant_id, party_id, series_id, reference_date desc)
FK:           series_id -> market_series(id), list_by, order reference_date desc

Its one join is market_observations.series_id = builds.series_id AND market_observations.observation_datetime = builds.reference_date, which the existing observations_series_datetime index already serves. The recipe and the inputs stay where they are: market_series.derivation_config_id for the build, observation_lineage per point. The build table carries only what neither holds, and it stays off the hot path: the kernel reads the points, not the header.

The recommendation is to not create it until that journey is agreed, and to write the journey first if it is. This is the one place the curve model may add a table, and the journeys decide it.

The three regimes get three shapes, and the storage shape is already the right one.

• Storage (Regime 2). The points are rows, not a blob: identity by key (series_id, observation_datetime, oresmd_uri), table-shaped children, core state split from the cold observation_lineage annex, batched access through one repository call. The one decision to keep is that a curve must not be stored as a serialised snapshot on a single row: that would break bitemporality, the as-of read and the eventing that every other series has.

• Kernel (Regime 1, the bootstrap and any valuation). The existing read_as_of returns an array of observation objects, each holding its value as text and its coordinate inside a URI string. A kernel should not walk that. Add one read that projects the same rows into arrays:

  struct curve {
      boost::uuids::uuid series_id;
      std::chrono::system_clock::time_point as_of;
      std::vector<std::chrono::sys_days> pillar_dates;   // resolved tenors
      std::vector<double>                discount_factors;
  };
  curve read_curve(context, series_id, as_of);           // one query, one parse
  

  The value text is parsed once at the boundary, the tenors are resolved once, and the kernel sees stride-1 spans. No per-point object, no variant, no parse in the loop. read_as_of stays for the generic reader; read_curve is the kernel projection of the same rows, not a second source of truth.

• Wire (Regime 3). The curve read is one batched message carrying parallel arrays, not one message per point, and the existing marketdata.v1.curve-snapshot.get is reshaped to it rather than joined by a second subject.

It does. The composite object is a series; its nodes are the series' point observations at each instant; the hypertable already stores them that way, and read_as_of_buckets already reconstructs snapshots. Nothing about the evolution requirement needs a new table:

• Discovery by typed attributes — currency pair, object kind, party — is a wire and service concern: the request carries typed fields and the server resolves them to the series URI. If that lookup needs an index rather than a scan, the index goes on a derived projection of the URI's parts, not on a new table.
• Coordinate typing is a read concern: the server parses each node's oresmd_uri once through the codec to produce the coordinate labels and to align the matrix. The identity stays the URI, as the component decided.
• Alignment, shape change and the instant range are the evolution read's design, not the schema's.

What the evolution requirement does change is the priority: the aligned matrix read is the first thing to build, and the single-curve build journey is not.

The storage supports the question. An FX vol surface is one market_series whose points carry (expiry, strike_label) coordinates — the fx_option row in datum/schema.hpp — and the observation hypertable is append-only and partitioned on time. The retrieval does not:

• Discovery needs the URI string. Both reads are keyed by oresmd_uri (get_curve_snapshot_buckets_request.oresmd_uri). "The FX vol surface for EURUSD" must be turned into the exact oresmd string by the caller; nothing indexes the identity's parts or lists the surfaces of a currency pair.
• Evolution is a fixed window ending now. The one evolution read takes bucket_seconds and bucket_count (5 buckets of 1800s by default) and ends at the present. There is no time range and no set of instants, so "over the last quarter" is not expressible.
• The result is not aligned. get_curve_snapshot_buckets_response.buckets is a vector<vector<market_observation>>: the client matches nodes across buckets itself, and each value is text. Nothing returns the surface as a matrix of instants by nodes.
• Shape change is undefined. When the surface gains an expiry or loses a strike between two instants, the buckets simply hold different point sets. Nothing reports an added, dropped or persistent node.
• The object has no type. A curve, a surface and a grid are all "a series" with different coordinate shapes; nothing states which series are surfaces, or what their axes are. A generic evolution view cannot offer "all the vol surfaces for EURUSD" because it cannot tell one composite object from another.

So the data model does not make the FX vol surface evolution easy to retrieve, and the reason is the requirements, not the storage. The storage already holds the right rows; the reads and the acceptance never ask the question in the person's terms.

The question is the right one, and the answer today is: nowhere. The seven marketdata tables hold the series identity, the points, the fixings, the asset-class junction, the lineage, the feed bindings and the classification rules. None of them says which tenors, expiries or strikes make up a term structure. The shape is inferred from the points and nothing else:

• For an observed structure the shape is whatever arrived. The set of tenors is SELECT DISTINCT over the point URIs, so a tenor missing because the feed dropped it is indistinguishable from a tenor the structure does not have.
• For a bootstrapped curve the shape is the refdata recipe's pillars: ir_curve_bootstrap_pillar carries start_tenor_code, end_tenor_code and sequence_index. That is close, but it is a build recipe in another component, it exists only for bootstrapped curves, and it describes the recipe's inputs rather than the term structure's nodes.
• The oresmd schema declares the coordinate fields an instrument type carries — the axes — but no per-series values, so it cannot say which tenors a particular curve comprises.

Without a shape, several of the requirements below cannot be met. A missing node cannot be drawn as a hole. Completeness cannot be checked. "Which nodes were added or dropped between two instants" cannot be answered against an expected axis. And a surface's components cannot be enumerated without scanning history.

The object's shape is its axes and their ordered values:

A node is one value per axis; the grid is the product of the axes; an observation is the value at a node; and a node with no observation is a hole, which is exactly what the rendering, completeness, alignment and component requirements need. The tables are small and cold:

ores_marketdata_series_axes_tbl
  series_id   uuid      -- FK -> market_series(id)
  axis_field  text      -- an oresmd field code: term, expiry, strike_label, ...
  sequence    integer
  unique current: (tenant_id, party_id, series_id, axis_field)

ores_marketdata_series_axis_values_tbl
  series_id   uuid
  axis_field  text
  value       text      -- the code or level, validated where a vocabulary exists
  sequence    integer
  unique current: (tenant_id, party_id, series_id, axis_field, value)

Both are cold: tens of rows per object, read once when an axis is drawn or a build is validated, never on the point path. They join to the series by series_id, and to the points by (series, axis attribute) against the coordinate the read extracts from the point's URI. A point whose coordinate is not a declared axis value is a defect, and the write-time check that refuses it is what keeps the shape and the points from drifting.

For a bootstrapped curve the shape and the recipe's pillars are the same tenors seen twice, so the rule is: the shape is the marketdata-side statement of what the object comprises, and the recipe states how each node is built. A build writes the shape from its pillars when it publishes, so the two cannot drift; an observed or imported structure writes its shape from what it declares, with no recipe at all. This is also where the tenor validation lands: an axis value that is a term must be a refdata_tenors code.

The vol surface's quoting convention is not a detail beside the surface; it is one of its axes. The FX option key is FX_OPTION/<quote>/unitCcy/ccy/expiry/strike, and ORE keeps the strike as a label: ATM, 25RR, 25BF (ore_key_fx.cpp:56-64). So ATM, risk reversal and butterfly are strike_label values, one per node, and each one is a term structure over expiry — exactly the three the question names. That decomposition is already in the data; the model exposes none of it:

• There is no read that returns a component. "The ATM ladder" is every node of the surface whose URI carries ATM, and the client finds them by parsing and filtering.
• The labels are free text with no vocabulary and no validation, so BF, FLY and 25BF are three spellings the model cannot reconcile, and the delta convention they imply is not stored at all.
• There is no "what are the components of this surface" read, so a screen cannot offer ATM, 25RR and 25BF without scanning history.
• The evolution read is URI-keyed and windowed, so "the ATM ladder over the last quarter" is not expressible either.

This is the same gap as the surface, one axis down, and it argues for the axis work rather than for a table: the components are slices of the surface's grid, not independent objects.

The question this raises is whether ATM, RR and BF should each be a series of their own, grouped into a surface, rather than a coordinate of one surface series. The answer turns on what changes and what is consumed:

• A market quote is a (pair, expiry, strike label) point. The grid is one object quoted by one convention, and a change to its shape is a point change. One series per surface makes that an ordinary bitemporal point write.
• One series per component would make a shape change a change of group membership with its own history, which is a junction with validity rather than a point, and it would spread one object's identity across N series.
• The components are almost always read together with the surface, and the curve set storage grouping is for grouping independent series — a funding curve and its projections — not for slicing one grid.

So the recommendation stays: the surface is one series; ATM, RR and BF are values of its strike-label axis, and what they need is a typed, named, validated axis and a read that returns a slice, not a series and not a table.

Users key points by hand: a trader's IR level, a broker's vol, a correction after a bad feed. That is a first-class market-data operation, not an anomaly, and it needs three facts the model does not store at a point today: that the value is manual, who keyed it, and when.

Two facts decide the design:

• The hot row must not carry them. market_observation is no_audit_columns, append-only, and the hot path. Adding actor and reason columns would put cold metadata on every one of its rows and undo the hot/cold split the model already has.
• A manual point is an ordinary bitemporal write. The value has the same shape as any other point, and the table's soft_update_delete trigger already closes the prior row and inserts the new one. The override therefore needs no value storage of its own: the manual write is a normal write, and the history keeps both the fed value and the manual one.

What is missing is the point's provenance, which is cold and belongs in the existing per-point annex. observation_lineage is keyed by the same triple and already carries modified_by, performed_by, change_reason_code and change_commentary. What it lacks is the two things a manual point needs in order to be told from a fed or derived one:

• a point source kind — quoted, interpolated, extrapolated and manual (the curve point provenance proposal's derivation kind, extended with manual), and
• the actor and time at point granularity, which the annex has and the observation does not.

The clean shape is one per-point cold annex, not a second table keyed the same way: either broaden observation_lineage into the point-provenance annex that document already proposes, or rename it to say what it now is. Two cold tables keyed by (series_id, observation_datetime, oresmd_uri) would be a smell.

Because the manual write is bitemporal, a later feed tick would close the manual row and take over, so the precedence is a policy the model must state rather than a consequence of write order. Either the point is marked locked in its provenance and the ingest skips a locked point, or the read prefers the latest manual point over the latest automatic one until the manual point is cleared. Either way the rule is explicit and testable, and the evolution view can show the manual segment with its actor and its reason.

1. A composite object is first-class: identifiable and of a kind (term structure, surface, grid), with its axes named, before any point is read.
2. Its shape is declared: the axes and their ordered values are stored as a cold, per-object declaration, so a node with no value is a hole and not an absent node, and completeness can be checked.
3. Its nodes have typed coordinates – terms, expiries, strikes or deltas, dimensions – that can be queried, joined and aligned, not only text inside an identity string, and every node coordinate is a value of the declared shape.
4. Every axis value is a typed, validated code with a vocabulary, so ATM, 25RR and 25BF are canonical and a component can be named.
5. The components of an object along an axis are retrievable as term structures in their own right, over time: "the ATM ladder of the EURUSD surface, over the last quarter" is one request.
6. Evolution is a first-class read: one bounded request returns the aligned matrix of instants by nodes, with the coordinate labels and the values.
7. Shape change is explicit: the read reports nodes added, dropped and persistent against the declared shape.
8. The single-instant read, the slice read and the evolution read share one definition of the object, so they cannot disagree.
9. Every node's value carries its provenance per instant, so the view can explain a change.
10. A point's source kind is stored per point – quoted, derived or manual – and a manual point names the actor, the time and the reason.
11. A manual point is not silently overwritten by a later automatic write; the precedence between the two is explicit.
12. The evolution view distinguishes manual points and shows their actor and reason, so a person can see what was keyed by hand.

Items one to five are done. Items six to eight and ten are now BACKLOG tasks, named under each item. Item nine closed before it was ever a task.

1. The composite-object identity at the wire boundary: a typed request (asset class, scope such as a currency pair, object kind, party) that resolves to the series, so "the FX vol surface for EURUSD" needs no hand-built URI. Task Resolve a composite object from its typed identity, DONE.
2. The shape tables: the per-object axes and their ordered values, written from the recipe's pillars by a build and from the declaration by an import, with every term value validated against refdata_tenors and a write-time check that refuses a point whose coordinate is not a declared axis value. That validation is of a declared shape, not of a pillar a person saved, so it does not close capture A6472918. The capture is promoted to its own story, Validate a curve pillar's tenor codes, which stays open. Tasks Give a composite object its shape tables, Refuse a point its shape does not declare and Let an import declare the shape it carries, all DONE.
3. The axis values as typed, validated codes: the strike-label vocabulary and the quoting convention, so ATM, 25RR and 25BF are canonical and the components of a surface are enumerable. Task Type the axis values a composite object varies over, DONE. The label is a codec type. A per-surface quoting convention stays with journey 2.
4. The slice read: a component along one axis – the ATM ladder – returned as a term structure over time, from the same object definition. Task Read one slice of a composite object over time, DONE. The instants are the object's, the ladder is the shape's, and an object of more than two axes is refused.
5. The aligned evolution read: the object plus a range or a set of instants, returning instants by nodes with the coordinate labels and numeric values, and the added, dropped and persistent nodes against the declared shape. It replaces the fixed five-bucket window and returns a matrix, not arrays of objects. Task Read a composite object's aligned evolution, DONE. The instants are the points an instant states, the grid is the shape's product, and the fixed five-bucket window is gone.
6. The single-instant read reshaped to the same object definition, so the three cannot disagree. Task Reshape the single-instant read to the object definition, DONE. The snapshot names the object by its typed identity and returns the shape's nodes.
7. The per-point provenance annex: the source kind (quoted, derived, manual), and for a manual point the actor, the time and the reason, in one cold annex keyed by the point's natural key. Name it once – broaden observation_lineage or rename it – rather than adding a second cold table beside it. Task Give every point a provenance annex, DONE. The annex was one table already; the task adds the read, on the snapshot, when asked.
8. The manual precedence rule: what a later automatic write does to a manual point, stated as a policy and covered by a test. Task State what a later automatic write does to a manual point, DONE. A manual point owns its coordinate until it is cleared.
9. Guard the curve-snapshot reads (capture D9258D1F). Closed before this list became tasks. The handler checks marketdata::curve_snapshots:read and the permission is seeded, see What the tree has moved since the earlier passes below.
10. Only then decide the curve_builds table, from the agreed journeys. Task Decide the curve_builds table, DONE. No build table. The journeys earn a publication record, added with the publish operation.

• The curve-snapshot reads are now authenticated and their permission is seeded. curve_snapshot_handler.hpp:81-85 and :121-125 check marketdata::curve_snapshots:read, and projects/ores.sql/populate/iam/iam_permissions_populate.sql:1519 seeds it. The D9258D1F defect is closed. The deeper analysis's "the handler checks no permission and no curve-snapshot code is seeded" (story :306-309) is stale.
• instrument_type::curve and to_curve_key() no longer exist. The only instrument_type is ORE's MarketDatum list (ore_types.hpp:38-84), which has no curve member. The generated grammar that held them was retired, so the open question that assumed them is moot.
• curve_republish_service.cpp has moved. The story's citations (:182, :224, :296, :299) are from d02032a18c. Today the stamp is :171-187, the bootstrap() call is :256, the observation write is :324-333 with the insert at :363, and the lineage write is :344-359 with the save at :365-366.
• The database holds no built curve. One bootstrap config exists; its output series is still derivation_kind'OBSERVED'= and has zero observations. Three lineage rows exist in total and none is current. A republish has never run outside the tests, so every "today" statement below about a built curve is a statement about code paths the tests exercise, not about data.

The gap counts are the journey documents' own "What is missing" items under doc/knowledge/journeys/market_data/, except journey 15, which is under .../operations/. "Serves it today" names the table, read or code that exists now, with a file and a line.

The story's "Curve data model" table (story :341-347) claims five hops. Four hold; one is wrong about its key.

Two further facts the hops table should state: market_observations carries no point_id and no tenor column (columns at create.sql:42-51), and observation_lineage is not written for observed points, so "points to inputs" is a hop that exists only for derived points.

1. How does a curve read its points? Today read_as_of returns an array of market_observation objects whose value is text and whose coordinate is inside a URI (market_observation_repository.cpp:418-451). Decision: add the read_curve projection returning parallel arrays, as the story's data-oriented layout asks (:445-463=). It is a read over the same rows, not a table, and it matches the Regime 1 criteria for SoA and stride-1 access (data_oriented_design.org:162-167). The engine already consumes a vector<bootstrapped_point>, so the kernel is one parse away from the projection.
2. An entity or a shaped series? Decision: a shaped series plus the cold point annex, not a curve_point table. The points must be bitemporal, versioned, evented and hypertable-backed exactly as observations already are (create.sql:118-138); a second point table duplicates that stack, and the story already priced it (:233-238=).
3. Does a curve need its own table when it is one series plus points? No. Identity is market_series.oresmd_uri (marketdata_market_series_create.sql:61), and the series already carries a validated taxonomy in series_subclass (18 seeded codes at refdata_series_subclass_codes_populate.sql:43-96, including yield and volatility) and a derivation marker (create.sql:64-66). A curve-vs-surface kind is the coordinate shape, which the read derives from the URI's declared coordinate fields (schema.hpp:304-386). Reviving a curve enum is not needed.
4. What consumes a curve? Nothing in production. The only caller of curve_republish_service is its own wire handler (curve_republish_handler.hpp:67-145, registered at application.cpp:199-210), and no web route, HTTP route or shell verb sends either subject. The client package has no curve call and the shell has no curve command. The engine's other callers are its tests, and curve_health_checker has no production caller at all. Decision: record that there is no consumer and keep the representation minimal and reversible; the first consumer is the compute or the evolution read, built before any table is added.
5. Does the oresmd curve vocabulary become load-bearing? Moot. instrument_type::curve and to_curve_key() were deleted with the generated grammar; the URI is the identity. No enum is revived.
6. Is IR_CURVE_BOOTSTRAP the whole story? No. CRM_DERIVATION is seeded and unused (refdata_derivation_kinds_populate.sql:44). Decision: put the point source kind on the generic annex so CRM and any later derived kind reuse it unchanged, which is what that table's own doc says it is for (ores.marketdata.observation_lineage.org:25-30).
7. Where does the recipe belong? Leave it in ores.refdata. Its config already owns CRUD, history and row-level security there (refdata_ir_curve_bootstrap_configs_create.sql:29-33), and market_series.derivation_config_id is the established soft reference. A move would duplicate refdata and break the soft-reference principle. Decision: keep it, and close the tenor-validation gap on the recipe side.
8. How does a curve relate to feed_binding and observation_lineage? feed_binding maps a producer channel name to a party (feed_binding.hpp:65,93); lineage records the series a derivation read (observation_lineage.org:166-177). Decision: a derived curve has no feed binding; its inputs are series ids, and republish() already writes those into source_series_ids (curve_republish_service.cpp:311,354). No change.

The acceptance demands four things the model lacks: a point's source kind, a manual point's author/time/reason, a precedence rule, and one read that returns a component's ladder over time. Three are provenance and one is a read. None needs a new table.

Where the point's provenance lives. On the existing cold per-point annex, ores_marketdata_observation_lineages_tbl. A point with no annex row is quoted: absence is the default, and quoted ticks keep writing one row to the hypertable and nothing else, which preserves the hot/cold split the model already has (marketdata_observations_create.sql:37-38). A point with an annex row is derived or manual, named by one new column:

point_source_kind   text   not null   -- 'derived' | 'manual', validated

Everything else the manual point must name is already on that annex: modified_by is who keyed it, change_reason_code with change_commentary is why, and the annex's bitemporal valid_from is when (marketdata_observation_lineages_create.sql:66-71). The annex already registers a history provider (observation_lineage_history_provider_registrar.cpp, fields at observation_lineage_history_field_mapper.cpp:41-62), so the auditor trail and the per-point provenance read exist for free once the row is written. Adding a second cold table keyed by the same triple would be a smell, exactly as the story says (:682-685=).

Two constraints have to move so a manual row can exist: derivation_config_id and source_as_of must become nullable, and the jsonb_array_length(source_series_ids) > 0 check must allow an empty array, because a manual point has no derivation config and no source series (create.sql:62-65,80). These are edits to the entity model (ores.marketdata.observation_lineage.org:52-204) followed by a regenerate, never a hand edit of the generated SQL or header.

This is the smallest representation that works. It is also the most data-oriented: cold provenance stays in a cold annex keyed by the point, the hot observation row is untouched, and no value is duplicated.

How the precedence rule is enforced and tested. Decision: read-time precedence. A current annex row with point_source_kind'manual'= owns its (series_id, oresmd_uri) coordinate for reading until it is cleared.

What an as-of instant means here, stated because it is easy to get backwards. An as-of timepoint is a market instant, and the read for that instant must take manually keyed points into account. A manual point whose own instant the snapshot covers belongs in that snapshot whenever it was keyed, this morning or five years ago: over-keying is an operator correcting what the curve is for that instant, not a statement about when they said so. So applicability is decided by the point's instant alone, and the annex's valid_from does not decide it. A manual point whose instant falls after the snapshot's instant belongs to a later instant and is not part of this snapshot.

The rule is one pure predicate over the kind of the latest automatic value and the active manual value, applied by read_as_of and read_as_of_buckets (market_observation_repository.cpp:418-516) as a small overlay over the cold annex, not a join in the hot loop. Read-time is chosen over a write-time guard because the manual write is an ordinary bitemporal write (create.sql:77-99 closes the prior row and inserts the new one), so the history keeps the fed value and the later feed values, which the acceptance requires; a write-time skip would discard them. The overlay is over tens of manual points, not over every tick, so the aligned read stays contiguous.

The test lives in projects/ores.marketdata/core/tests/repository_market_observation_repository_tests.cpp, beside the existing read_as_of cases (:135-226). It writes a feed point, writes a manual point for the same coordinate, writes a later feed point, and asserts read_as_of returns the manual value and read_as_of_buckets shows it in every bucket whose boundary is at or after the point's instant, which is the bucket where it starts to apply. A second case flips the predicate's preference and asserts the feed value wins, so the test fails when the rule is reversed, which is the acceptance's own wording.

What is deliberately not added. No curve_build, no curve_point, no curve entity, and no shape table in this task. The build stays the slice republish() already writes (:324-333), and identity stays the series. The declared shape and the aligned read are the first consumer's work; the shape tables are a named gap with a decision (journey 13) and can be added when the evolution read's added/dropped/persistent requirement is implemented.

None exists today, and the acceptance allows the record to say so. The bootstrap engine is called by the republish service and by its own tests; the health checker by its own tests; the snapshot reads by their own handler; and no sender, page, route or verb reaches the handler. The consequence for the representation is direct: because no consumer exists, the representation must stay minimal, reversible and cold, and the first unit of work is the consumer, not a table. The cheapest real consumer is journey 13's aligned evolution read over one series, because it needs only the rows and the provenance overlay above, and it proves the object definition that the single-instant and slice reads will then share. The compute preview of journey 4 is the second, because it needs no storage at all.

1. Keep the series as the identity; add no curve, build or point table.
2. Put the point's source kind on the existing cold annex; quoted is the absence of a row.
3. Reuse the annex's record provenance for a manual point's author, time and reason; add no fields for them.
4. Enforce the manual precedence at read time with one pure predicate, and test it in the existing repository test file so a reversed rule fails.
5. Build the aligned evolution read first; it is the first consumer and the first user of the point source kind.
6. Correct the joins record: the curve-to-points hop is soft, not a hard FK.
7. Treat the snapshot-permission defect as closed and the oresmd curve vocabulary as deleted; strike both from the open questions.

• Whether a consumer wants the raw feed value beside an active manual value at the same instant. Read-time precedence can return both in one response; a journey has to say whether it should. Its answer decides whether the overlay is a filter or a second field, not whether a table is needed.
• Whether curve_build is earned. That turns on the approval and review journey (9-12), which has no owner and no prototype beyond the wireframe. The decision to defer it is recorded, not derived from a consumer.
• The rename question: whether the annex should be renamed to say it now carries a point's provenance and not only a derivation's lineage. It is a mechanical codegen rename with no behavioural effect, and it is left to the task that adds the column.
• The exact vocabulary for point_source_kind. Settled: the column carries derived or manual, and quoted is the absence of an annex row. The acceptance's three kinds are all answerable, because a reader classifies a point in one step: no annex row means quoted, and a row names the other two. Absence carries quoted rather than a third stored value because of the hot/cold split. A quoted tick is the common case and writes one row to the hot hypertable and nothing else; storing 'quoted' explicitly would write a cold annex row for every tick in the system, which is the cost the split exists to avoid. The invariant this rests on is that a point a derivation created always has an annex row, so absence cannot mean derived. The wider set the provenance proposal carries – interpolated, extrapolated, flattened, back-filled – stays open, and adding it later changes no representation, only the check on this one column.

• A market observation is what the market sends. It arrives per point, from a feed or an import, and nobody signs it off. It is the evidence.
• A published curve or surface is what the system uses. A trader holding the market-data management role owns it, updates it from what they see in the market or adjusts it by hand, and publishes it once the configured approvals are given. Only the published object is visible to pricing, reporting and every other consumer.

• Journeys 3 and 4 of the first draft are one screen, now journey 3: the market's exceptions are cleared where they are seen.
• The two read journeys are one screen, now journey 13: one instant and a range are the same view at different zoom.
• Approvals are generic and configurable. An approval kind carries how many approvals are needed and which group decides, so a publish may need zero, one or n approvals. A withdrawal uses the same rule.
• The ORE export is not a journey. It is excluded from this catalogue and the data model must still cater for it; a later task owns it.
• The feeds journey moves to the operations group, because Operations owns it and it is not about curves.