User Journey: Rerun and audit a cut

Table of Contents

This page documents a user journey: An auditor reads the history of a cut, who took and authorised it, the runs that priced from it, and reproduces a result from the same body and the same engine, or reads why it cannot.

A user journey describes what one person is trying to do, before anything is built. It is a design document that outlives any sprint, so it names the screens, the entity fields each screen shows, and the operations and messages each step needs.

The decision behind it is The cut is the body a run prices from. This journey is the one the whole cluster exists for: the Cuts note states that the purpose of a cut is a valuation that is fully reproducible, and a purpose is not met until somebody reproduces one.

1. Goal

"A number in a report was signed off months ago and I am asked to stand behind it. I want to read which body it came from, who fixed it and who signed it, every run that rested on it, and then produce the same number again from the same body and the same engine — or be told, in words I can put in a file, why the same number cannot be produced."

The journey is done when the person has either reproduced a figure from the cut, or holds a statement of the reason reproduction is not possible and what would be needed.

2. Actor and trigger

An auditor runs this journey, and so does a market-risk owner answering a challenge to a number, and an engineer chasing a difference two runs of one body show. All three read the same surfaces; only the engineer takes the fourth step, which compares the figures rather than restating the verdict.

Reading needs reporting::cuts:read and reporting::report_instances:read. Re-running a report needs reporting::report_instances:write, which is the permission a person already needs to press Run now. Reading the engine version is part of the run's own record. A person who may not re-run a report reads the cut and its runs and is drawn no Run it again.

The trigger is a request from outside the party: a regulator's question, an internal audit's sample, or a challenge from the desk. The person starts from the report the number appears in, or from a cut whose label they were given, and the journey ends with a comparison on the screen.

This journey reads and re-runs. It does not authorise a cut, which is Take a cut, and it does not choose which cut a report prices from, which is Give a report its cut.

3. Steps

3.1. Step 1: open the cut, and read what it is

  1. Reach the cut. The person reaches it from the run's card, from the Runs of a report, or by opening Cuts and searching the label. The record page's heading is the derived label, and the lead line reads the kind, the timepoint, the scope and the state.

  2. Read the body. The The body tab draws the parts, each with the counts and the state it held when the body was fixed.

    Part What the tab draws
    The deals The population by count and by state, the books, the corrections inside it, and the read that produced it
    The market data The publish record of every set the body fixed, its curve, party, as-of and publisher, the fixings in force, and the value count
    The reference data The version in force of every configuration the run reads, each a link to that version
    The engine and the code The engine version, the wrapper version and the service build
    The taking identity The account, the party and the instant
  3. Read the gap list, where there is one. An incomplete body draws its gaps and says that no run ever priced from it. That is the answer to a challenge about a number the cut does not hold, and it is stated rather than implied.

3.2. Step 2: read who took and who authorised it

  1. Read the authorisation. The Authorisation tab draws the acts and the sign-off: the taker and the instant, the request, the account the request waited on, the decider, the instant and the comment, or the refusal and its reason. Each names its account and links the request in Approvals, which is the record the inbox keeps for every kind.
  2. Read the four-eyes fact. The tab states, in one line, that the taker and the decider are two people, and it says what the schema enforces: a decision by the person who asked is refused, and one person approves a request once. The rule is the inbox's for every kind, and Approval requests states it. A signature a reader can check is worth more than one a reader must trust.
  3. Read the basis where the kind requires no signature. A cut of a kind that requires no authorisation draws one act and the sentence that names the basis: that the kind requires none, and, where the kind says so, that every result priced from it is marked indicative. The tab draws it in the place the decision would stand, so an auditor reading the page does not take a signed body and an unsigned one for the same thing.
  4. Read what the label does not say. The tab states that the label names the kind, the scope and the date, and that it says nothing about who signed it, so the state and the basis are read as facts and not inferred from the label.

3.3. Step 3: read the runs that priced from it

  1. Read the runs. The Runs tab lists every run that priced from this cut, newest first: the report, the definition, the run's instant, its state, its engine version and its result's location. The count of those runs is the column the cuts list draws, so the two screens agree.
  2. Open one run. A row opens the run's page, and the run's card names the cut it priced from, as Give a report its cut draws it. The two pages are the same fact read from each side.
  3. Read a run that did not price. A run refused before the engine appears in the list with its refusal and does not count as a run that priced from the cut. The distinction matters to an auditor: a refusal is not a result.

3.4. Step 4: reproduce a result

  1. Press Run it again. The press is offered on a run that completed, and on the cut itself for the report that consumed it. It re-runs the same report against the same cut, and the dialog states what it will do: the same body, the same engine version if the version is still served, and a result to compare with the original.

  2. Read the verdict. The comparison is one of three, in the words the card uses.

    Verdict What the screen draws
    Reproduced The two runs side by side, the figures equal, and the sentence that they are one result computed twice. The cut and the engine version are stated once and shared
    Differs The first figures that differ, each with both values and the difference, and the statement that the body and the engine are the same. The screen says this is a defect in the engine or in the code and not a movement of the market
    Cannot be compared The reason, in one of three forms, and what would be needed to compare

  3. Read why reproduction is not possible. The third verdict is the one an auditor writes down, so it is stated precisely.

    Reason What the screen says
    The engine version differs The original run used one version and today serves another. The body is the same and the software is not, which is the condition the cluster's quoted definition of reproduction excludes
    A part of the body is no longer served The body records the part and the store no longer serves it: today, a fixed market data snapshot that was never stored, or a configuration version that was withdrawn. The screen names the part and the series
    The body was retaken The run priced from an earlier cut of the same day, and the comparison names both labels. A retaken body is a different body, and its results are comparable only as a movement
    A LIVE report was run twice The two runs each minted a cut at their own instant, so they share no body at all. The card names both cuts and says the two are comparable only as a movement, and that the first is reproduced by naming its cut
  4. Read what the rerun keeps. The new run records the cut it priced from, its own instant and its engine version, so a third person can repeat the exercise without asking the person who ran it. The screen states that no figure is overwritten: the two runs are two records.
  5. Reproduce a LIVE result by naming its cut. A run of a LIVE selection minted the body it priced from, and running the report again months later would mint another. The card therefore offers the one route the promise allows: a rerun against the cut the first run recorded, which is a selection of that specific cut, or the rerun the run's own page starts. The screen says plainly that a second LIVE run is a view of a later instant and not a repeated result.

3.5. The audit across the day**

  1. Read the day's sequence. From the cuts list, a person reads one day's cuts in order: the cut taken at the close, the retake that superseded it, and the runs that rested on each. The sequence is the audit trail a challenge asks for, and it is why a superseded cut is kept and drawn rather than hidden.
  2. Read who rests on a superseded cut. The Runs tab of a superseded cut names the runs that priced from it and the cut that replaced it. That is the question a person asks before a retake is authorised — what already rests on the body I am about to replace? — and the answer is a list rather than a guess.

4. Screens and wireframes

Two surfaces carry this journey: the cut's record page, read through its four tabs, and the run's page with its card and its comparison. The cuts list is the third, because the day's sequence is read there.

The judgement, per step, against the standards.

Step Shape on the screen Judgement
1 to 3, the cut The standard record page with its tabs RS-PAGE-01 to RS-PAGE-10
2, the body's parts A panel per part, with counts and links No rule draws a body yet; the prototype defines the shape
4 to 6, the authorisation A panel of the two acts, and a link to the request The entity screen specification's timeline shape, and the inbox's own page for the request
8 to 10, the runs The standard's parts panel with its rows RS-RELATED-04 to RS-RELATED-06
11 to 15, the reproduction A comparison of two runs, with a verdict No rule draws a comparison of two results yet; the prototype defines it and What is missing records the gap
16 to 17, the day The list ordered by timepoint, and the Runs tab RS-LIST-12 and RS-RELATED-04

wireframe_rerun_and_audit_a_cut.png

Figure 1: The audit of a cut: the body's parts, the two acts, the runs that rested on it, and the comparison of a rerun with its original.

5. Prototype

The the cut prototype draws this journey on two of its surfaces: the cut's record with its Runs tab, and the run that names the cut with its three verdicts. Its design note records the states and what is fake.

It must draw a cut whose runs all reproduced, a rerun that reproduced, a rerun that differs, a rerun that cannot be compared for each of the three reasons, and a superseded cut with the runs that still rest on it. Every value is a fixture.

6. Entities composed

Entity What it contributes Model
the cut The label, the parts, the gaps and the two acts The cut is the body a run prices from
report_instance The run, its instant, its state, its result's location and the cut it priced from ores.reporting.report_instance
report_definition The definition whose report the runs price ores.reporting.report_definition
report_error_event The errors a run reported, which is why a run that completed carrying errors is not a clean reproduction ores.reporting.report_error_event
app_version The engine and wrapper versions the reproduction turns on ores.compute.app_version
approval_request The authorisation the cut holds, and the decision behind it Approval requests
curve_publish The state each set in the body holds today, which a reader must not confuse with the state it held when the body was fixed ores.marketdata.curve_publish

This journey writes one row: the run it re-runs. Nothing about the cut is written: a cut that has been taken is immutable, and an audit that could change the object it audits would be worth nothing.

7. Operations and messages

Step Operation Subject Status
Steps 1 to 3, the cut Read one cut with its parts reporting.v1.cuts.get missing
Step 4, the authorisation Read the request, its part, its decision and its state inbox.v1.approval_requests.get exists
Steps 7 to 8, the runs List the runs that priced from a cut reporting.v1.report_instances.list_by_cut missing
Step 8, one run Read the run and the cut it records reporting.v1.report_instances.get exists; the cut is missing from the row
Step 9, the refusals Read the runs of a definition, and the state of each reporting.v1.report_instances.list, filtered by definition exists
Step 10, the rerun Trigger a run of the same definition against the same cut reporting.v1.ops.trigger_report_instance exists; the cut is not an input
Steps 11 to 12, the comparison Read the figures of two runs and compare them (nothing reads a run's figures as rows: report_instance gives the archive's location) missing
Step 12, the engine version Read the engine version each run used (the run records the date and not the version) missing
Steps 14 to 15, the day List the cuts of a scope over a range of dates reporting.v1.cuts.list missing
The screen itself Read a cut and its runs from the browser (no BFF route serves cuts) missing

The comparison reads the two runs' results as rows. The output of a run is an archive, and the last journey of the reporting group states the same gap from its own side: nothing parses a run's archive into figures. Until something does, the verdict this journey draws can be stated only from the facts a run records, which are its cut, its engine version and its state.

8. What is missing

  1. Nothing compares two runs. The reproduction promise is the purpose of the whole cluster and no operation answers it. A comparison needs the two runs' figures as rows, which needs the archive parsed, which is a gap the reporting journeys already record.
  2. The run does not record its engine version. A run records the date it priced at and the note that explains a moved date, and nothing names the version of the engine that computed its result. A reproduction verdict that cannot state the software is not a verdict.
  3. The cut records the service build, and nothing provides it. The body's engine and code part needs a revision for the services that assembled it, and the platform records no build for a service. The Take a cut journey records the same gap from the side of the take.
  4. A fixed snapshot is recorded and not served. A cut whose market data half is a snapshot nothing materialises can be read today only if the store still holds the values. That is the second reason a comparison fails, and it is a property of the gap rather than of the audit.
  5. No list of runs by cut. Runs are read by definition, by health and by instance. Nothing reads them by cut, so the Runs tab and the cuts list's count have no source.
  6. No route and no screen for reporting. The cut's record, the run's card and the comparison are all new, as the two journeys beside this one record.
  7. The day's sequence is not a read. The list ordered by timepoint answers it for one scope, and no read groups the cuts of a day by kind and ordinal. The first slice reads the list and states the order it uses.

9. Related journeys

10. Related knowledge

11. See also

Emacs 29.3 (Org mode 9.6.15)