Curve Point Provenance

A term structure point changes constantly (every tick, potentially), and unlike a reference-data record, its trustworthiness at the moment it is read is exactly as important as who last touched it — arguably more so, since it feeds directly into pricing and risk. Knowing that a value was last modified by a particular user at a particular time (the standard fields) does not tell a consumer what they actually need to know before relying on it:

• Was this value actually quoted by the market, or is it a manufactured value — interpolated, extrapolated, or flattened (see Term Structure Extent for the regions each of those applies within)? A pricer relying on an interpolated value where it assumed a live quote is relying on something structurally different from what it thinks it has.
• Was it rejected by a consensus data provider's own quality checks before it ever reached the system? A rejected value that nonetheless made it onto a curve is a data-quality incident, not a normal quote.
• Is it stale — a back-filled value standing in for one that failed to arrive — and if so, how stale? A value that is merely a few seconds old is a different risk than one that is hours old, and a consumer cannot tell the difference without an explicit age.
• Has it been manually overridden, replacing whatever the feed or interpolation would otherwise have produced? Knowing that an override happened is what a market-data consumer needs first; Data Quality's existing fields already cover explaining who and why once that fact is known.

The following fields would satisfy the trustworthiness need above, alongside — not replacing — Data Quality's existing Record Provenance Fields. None of this is implemented yet — this is a proposal, not a description of existing behaviour:

• Rejected: whether the value was flagged by a consensus data provider's own quality checks before reaching the system.
• Derivation kind: which of directly-quoted, interpolated, extrapolated, flattened, or overridden produced this value — the single field a consumer would check first to know what kind of value they are looking at. This also carries the classification Broken Dates and Turn Points' three-way tenor classification depends on: a point's standard / broken date / turn classification is a stored fact recorded once alongside this field, not a derived judgement re-computed on every read — which is why a broken date is never "promoted" into a standard tenor over time; there is no mechanism that re-evaluates a point's classification after the fact.
• Back-filled, and age: whether the value stands in for one that failed to arrive, and how long ago the value it now shows was actually current.

A related but distinct provenance-adjacent problem appears for option expiries rather than term-structure tenors: a barrier option expiring at a non-standard, illiquid cut time is risk-managed by placing a Date Shift Reserve against the nearest liquid cut time, rather than by sourcing market data for the illiquid cut directly. This is the closest analogue to "mapping an illiquid point to the nearest liquid one" outside the tenor domain proper — it operates on option cut times, not on a term structure's own forward ladder, and is recorded here only as a cross-reference, not elaborated further in this cluster.