Struct BuildRecord 

struct BuildRecord {
    provenance: BTreeMap<CurveId, Arc<CurveProvenance>>,
    refits: BTreeMap<CreditCurveId, Arc<SurvivalRefit>>,
    curve_refits: BTreeMap<CurveId, Arc<CurveRefit>>,
    recipes: Option<CurveRecipes>,
    counterparties: Option<Counterparties>,
    meetings: BTreeMap<CentralBank, MeetingSchedule>,
    source: SourceSetting,
}

How the market was, or would be, built. Addressed by the keys the pricing seam declares, and contributing no lifted parameter: never read by the lift, never compared.

Fields

provenance: BTreeMap<CurveId, Arc<CurveProvenance>>

The ladders behind the calibrated curves, keyed by the role each curve was pinned under. A curve pinned under two roles appears twice, sharing one handle — which is what lets both roles’ risk meet in the same par column.

refits: BTreeMap<CreditCurveId, Arc<SurvivalRefit>>

What each credit entity’s calibrated survival curve was solved from, so it can be solved again under a moved recovery with its quotes held.

curve_refits: BTreeMap<CurveId, Arc<CurveRefit>>

What each calibrated rate curve was solved from, keyed by the role it was pinned under — a curve pinned under two roles appears twice, sharing one handle — so a scenario can solve it again from moved quotes. Written and cleared with provenance.

recipes: Option<CurveRecipes>

The effective curve recipes: how a curve this market does not hold would be built, keyed by the same CollateralSpec a trade already declares as its discount key.

The future-tense twin of provenance, which records how a curve that is held was built. Both are addressed by the key the pricing seam declares.

It is read only by MarketContext::recipe and by the failure that could not resolve a curve — never by the lift, and never by the span layout, which is inside a pinned allocation budget.

None — the default — is a market that carries no recipes, and is distinct from carrying an empty overlay. CurveRecipes resolves overlay ▸ base ▸ absence against an immutable shipped base, so an empty CurveRecipes still answers for every registered key. A market would then claim to know how to build four currencies’ curves merely by existing. Carrying recipes is therefore opt-in: a caller who wants the shipped base asks for it by name.

counterparties: Option<Counterparties>

The counterparties a desk books against, keyed by acronym, so a draft can be collateralised under the CSA the counterparty’s record names. Opt-in like recipes: a market carries none unless given some, and a master contributes no lifted parameter and is never compared.

meetings: BTreeMap<CentralBank, MeetingSchedule>

The central-bank schedules a desk pins — a bank’s published decision days, from which its rule derives the dates the overnight rate moves — keyed by bank. Reference data like the counterparty master: a window takes its meeting’s name from here, and the seed answers where no schedule is pinned.

source: SourceSetting

Where the market’s missing data is fetched from: the process default copied when the market was built, a source given by with_data_source, or offline.

Trait Implementations

impl Clone for BuildRecord

fn clone(&self) -> BuildRecord

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for BuildRecord

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for BuildRecord

fn default() -> BuildRecord

Returns the “default value” for a type.