User Journey: See who changed a curve, and when

"I want to be able to say who changed this published curve, what they changed, and who approved it, so I can answer a challenge and show the trail." The journey is done when the auditor holds the trail of one curve: every blueprint change, every build, every manual adjustment and every publish, each with an actor and a time, and can put one version beside the one before it.

The actor is the auditor, or reviewer: a signed-in person inside their tenant who holds a read permission on the market data entities and on the approval records. No dedicated auditor role holds only those reads today; see What is missing. The trigger is an internal or external challenge to a number a run used, a periodic review of how curves are governed, or a publication the person must attest. The journey starts at a market series, or from the evolution view, and ends when the person leaves the trail.

The record is bitemporal: each row carries the transaction time of its versions beside the financial time of the thing it describes. What the trail can show, and what it cannot, follows from which entities keep those versions; see What is missing.

1. Open the trail. The person opens Market data, finds the series by its oresmd_uri, and chooses Trail. The system shows the series row: the URI, the subclass, the derivation kind, the derivation config and its version, and the provenance of the row, which is who modified it, who performed it, the change reason code and the change commentary.
2. Read the blueprint changes. The system lists every version of the series row, newest first, with the field-level difference from the version before: when the derivation config or its version changed, and who changed it and why.
3. Read the builds. The person opens the points. The system lists the series' observations by observation time, with each point's oresmd_uri, value, observation time and source. A build is many points written at one observation time under one source.
4. Read the per-point provenance. For a derived point the person reads its lineage: the derivation config and version, the source as-of, and the source series it read. Only a derived point has a lineage row; an observed point has none, and that absence is the observed marker.
5. Read the manual adjustments. The person asks which points a person wrote rather than a feed. The system shows the points whose source is the internal manual adjustment source, beside the change reason on the record.
6. Read the approvals. The person opens the approval requests and their decisions for the object: who asked, when and why, and who decided what and when. The generic approval record exists; no market-data approval kind does; see What is missing.
7. Read the publishes. The system shows every publish of the curve: the version published, the person who published it, and the time. No publish operation exists, so this panel is empty by construction; see What is missing.
8. Put one version against the one before. The person selects a version and the system shows it beside the version before, with the field-level difference. This exists for the series row; it does not exist for a point; see What is missing.
9. Leave. The person goes back to the series or to the evolution view.

Every read is answered inside the reply. The trail carries no state of its own; it is a reading of the versions the server already keeps.

One screen. The object and its provenance sit at the top, the blueprint versions and their differences sit under it, the builds, the per-point provenance and the manual adjustments sit in the middle, and the approvals and publishes sit at the bottom, so the person reads the object, then what was built, then who signed it off.

A static page at doc/prototypes/market_data/see-who-changed-a-curve/index.html: mock data only, no backend, no build step and no session. It argues that the trail of a curve: blueprint changes, builds, hand adjustments, approvals and publishes in one place, each with an actor.

Variants

a one merged timeline, b one table per kind, c a two-version compare

States

rich, empty (nothing published yet), manual (a hand adjustment with its actor)

Source

doc/prototypes/market_data/see-who-changed-a-curve/index.html

Open

/OreStudio/doc/prototypes/market_data/see-who-changed-a-curve/ once the site is built, or the file directly

The series, the lineage and the source are versioned, so each has a history and an actor per version. The observation rows are not: they are the tick-level table, and they carry no actor. The approval records are versioned and each decision is a row of its own.

The history request is the generic one, addressed at the owning component's subject, so the market data one is marketdata.v1.history.get with entity_type ores.marketdata.market_series, ores.marketdata.observation_lineage, ores.marketdata.market_data_subscription or ores.marketdata.series_classification_rule. Those four register a history provider. ores.marketdata.market_observation does not, because it has no audit columns and a version must carry an actor as well as a time; see What is missing. The lineage read is keyed by the lineage row's id, not by the observation, so the screen needs the id before it can ask.

1. Observations carry no actor. market_observation has no version, modified_by, performed_by, change_reason_code or change_commentary, because tick-level volumes made them impractical, so the market data registrar withholds a history provider for it. The candidate is a provider over the observation rows, or an actor and a change reason carried on the write. Until then the screen shows each point's observation time and source, and it cannot say who wrote a point or when it changed.
2. No publish operation and no publish event. Nothing publishes a curve, so the trail holds no publish acts. The bootstrap's republish writes the output series' observations directly, and its own protocol says the review and approval gate is a separate, later layer. The candidate is a publish operation with a published version, and a publish event. Until then the publishes panel is empty and the screen says that nothing is published.
3. No market-data approval kind. The inbox holds one kind, iam.role_grant; no kind names a curve publish or a manual adjustment, so no approval request can be raised for this object. The candidate is a market-data approval kind with its decide permission, its approvals-required count and its comment rule, and the operation that applies an approval. Until then the approvals panel can show only requests of another kind, and none names this object.
4. No candidate-against-published distinction. No field on an observation says whether it is a candidate or a published value, so the trail cannot separate the two. The candidate is a published version or a published flag. Until then the screen reads the market's values and does not claim which of them were published.
5. No field diff for a point, and no lineage read by observation. The history read returns versions with their difference for the four entities that register a provider. It does not for market_observation, and marketdata.v1.observation_lineages.get takes the lineage row's id, not the series, observation time and URI the repository's own lookup accepts. The candidate is a lineage read keyed by the observation. Until then the screen reads a lineage row by id when it has one, and matches the rest by hand.
6. The manual adjustments are not marked. market_observation carries a free-text source, so a point a person wrote cannot be told from a point a feed wrote except by that string, and the write's change reason does not travel with the row because the entity keeps no version. The candidate is a manual marker, or a source convention the column validates. Until then the screen treats a source that names no producer channel as manual, and says the classification is a convention.
7. No auditor role. No role holds only the market data reads and the inbox reads this journey needs; a person reaches it through the read permissions they already hold. The candidate is an auditor role.

• Watch a curve or surface evolve — the values the trail explains
• Manage a curve's blueprint — the blueprint whose changes the trail shows
• Adjust a curve or surface by hand — the manual points the trail must name
• Ask for a publish to be approved — the request the approvals panel reads
• Decide a publish — the decision the approvals panel reads
• Publish the approved set — the act the publishes panel must record
• Withdraw or replace a published curve — the act that follows a publish, and must stay in the trail
• Watch the market and clear its exceptions — the market side of every build

• Interest Rate Curves
• Funding and Projection Curves
• Curve Point Provenance
• Term Structures and Tenors
• Tenor and Curve Architecture
• Data-Oriented Design

• Market data journeys
• ores.marketdata.market_series
• ores.marketdata.market_observation
• ores.marketdata.observation_lineage
• User Journeys