A report binds to a published curve, not to a name

Table of Contents

1. Status: superseded in part, 2026-10-30

The decision below is kept because its argument stands: a name is not provenance, and a run must name the set it priced from rather than a string that matches one. Its carrier has changed. A cut now names the body a run prices from, and the market data half of that body holds the publish records this decision put on a row of the run settings. So the binding row, its pinned as-of and its tab on the configuration retire, and the three findings carry into the cut: a candidate cannot be part of a body, the ORE name is still derived from the curve and the party, and the export still builds the XML from the published set's points. The run records the cut rather than the binding, and the market card is read through the cut. The decision that settles the cut's side of this is The cut is the body a run prices from, and the journey that replaces this one's is Give a report its cut.

2. Summary

A report's market binding names a market configuration set by name, and the report's curve provenance stops at that name. The target is a binding that names the published set itself: the publish record, its as-of and its party, under the market role the report binds. The ORE export then builds the market configuration from the published set's points, and it refuses a set that is not in the published state. The name the market document carries is derived, not typed. This closes the chain described in Tracking market data identity from fixing to report.

3. Why a name is not enough

The binding's market_configuration_name is a free string that matches a configuration set in todaysmarket.xml, which ores.analytics owns. See ores.reporting.configuration_market_binding. Three things follow, and each is a provenance hole.

The name says nothing about which curve it means. A run names "USD-SOFR", and whether that is the curve a person published last week, the curve a candidate holds, or a curve a hand-written XML block describes is not in the record.

The name does not carry the as-of. Two runs under one binding can price from two different market instants without either run saying which, so a report result cannot be reproduced from the binding alone.

The name does not carry the state. A set that was withdrawn or superseded can still be named, and the export will happily build the XML from it.

4. The decision

A market binding names the published set:

Field Meaning
configuration_id The report configuration the binding belongs to, unchanged
role The ORE market role, unchanged
publish_id The publish record the binding names: the set, its party and its as-of
market_configuration_name Derived from the set's curve, not typed

The binding no longer carries a free name. The run's market configuration is the curve the publish record names, at the as-of the record holds, in the party that owns it.

4.1. The export enforces the state

The ORE export resolves publish_id through the published read. A set in the published state is exported. A candidate is refused, because nobody approved it. A withdrawn or superseded set is refused unless the run explicitly asks for a historical as-of, which is the only way a rerun reproduces an old result. The refusal names the set and its state, so a person sees why the run cannot start.

4.2. The XML is built from the set

The export writes the market configuration from the set's published points: the curve identity, the as-of and the points, in the ORE vocabulary of the boundary, as ORE import and export describes. The derivation is recorded on the report run, so a result names the publish record it priced from.

5. Consequences and the work

The entity changes: configuration_market_binding gains publish_id and priced_as_of, and loses the free name as an input. The binding screen picks a published curve with a picker over the published read, drawn by the curve, its party and its as-of, and shows the state; today's shared RecordPicker cannot carry it, because its choices are its whole kind read once and it draws no state. The screen itself is settled in What the screen settles. The ORE export reads the set instead of a name. The report run records the publish record it used.

The demonstration needs the binding of its report configuration to the published USD-SOFR curve, so a run can be shown end to end.

6. What the screen settles

The Market bindings prototype draws the screen this decision implies, and it settles five things the decision left to it. The person's side of them is Bind a report to a published curve.

6.1. The bindings are a collection of the run settings, and a tab of its page

The rows belong to the run settings configuration, so they are a collection of that kind: one row per market role, changed in a dialog, saved once for the document, and versioned with the configuration. They are a tab of its record page named Market bindings and they follow the Configuration screen standard rather than a screen of their own. The report page's market tab is the second door, so a person who starts from the report reaches the binding in one step.

6.2. The state is the row's first fact, and it is the binding's verdict

The row draws the verdict — Published, Historical, Refused, Ended, No binding — with the set's stored state under it. The two are different facts: a set that was superseded is not the set this run would use, and the screen must say the second.

6.3. A candidate is refused where it is picked

The picker draws the published sets with the curve, the party, the as-of, the state and the publisher, and it refuses a candidate at the row. Bind is not drawn for one, so the screen will not stage a write the run would refuse. Nothing on the screen writes a candidate, and the refusal says what would make the set usable: an approval.

6.4. The ended set is refused, and the pin is on the binding

An ended set is refused in the same place, and the one route past the refusal is the person stating the set's as-of as a historical as-of. That statement is a field of the binding — priced_as_of — and not a choice made at the run. It is visible on the screen a person reads before pressing Run now, it is a version in the configuration's history, and it holds for every run of that configuration until somebody changes it. A run dialog that asked for an as-of would keep the same answer in a place nobody can read before the press.

6.5. The run names the set, and the refusal reaches it

The ORE name is drawn and never typed: the row carries a Writes column showing the market configuration name the export will derive from the set's curve and party. The run's own page carries a card naming the publish record it priced from — the curve, the party, the as-of, the publisher, the published instant and the points read — read from the run and not from the binding, because the binding may move afterwards. A run whose binding names a candidate, names an ended set with no pinned as-of, or names nothing at all is refused before the engine is reached, in the same words the screen uses.

7. What this does not settle

  • Which deal population the run valued. The binding names the curve and the as-of and says nothing about the trades, so a report that must state both needs a second binding, to a cut. A cut is a label for a timepoint and the object it fixes, and this repository models neither the identity nor the authorisation, so this decision depends on a concept that does not exist yet. Cuts states what a cut must hold and what would have to be built.
  • Whether a binding may name more than one set, for a report that needs several curves. The first slice binds one set per role, and the prototype draws one row per role and refuses nothing: a role that needs a list is not drawn.
  • Whether other market data, such as FX spots, binds the same way. The first slice binds the curve; the same shape would carry any published series.
  • Whether the curve configuration document remains an input alongside the binding, or retires once the binding names the set. That is the next decision after the first slice runs.
  • The spelling of the derived name. The decision says the name is derived and no rule states how the curve, the party and the as-of fold into a name that todaysmarket.xml accepts. The prototype draws an illustration in the Writes column and the export owns the rule.
  • Whether the pinned as-of is the set's or the run's. The prototype pins the set's own as-of, which is what a rerun of a published result needs. A rerun at an instant the set did not hold is not drawn and not refused.
  • The vocabulary of the market roles. role is a free string in ORE's schema, and no table holds the names a run may use, so the screen draws the codes the run document carries and says the list is not a vocabulary.
  • Whether a report may price from another party's set. The prototype offers the configuration's party alone, on the rule that the same curve code in two parties is two curves.

8. See also

Emacs 29.3 (Org mode 9.6.15)