Cuts journeys
Table of Contents
A cut fixes a body of data at one timepoint so that a valuation can be reproduced. Three journeys cover a person's side of that: taking one, pricing a report from one, and rerunning and auditing one. The domain is on Cuts, and the model the screens imply is on The cut is the body a run prices from.
The three read as one answer. The take fixes a body and has it signed; the report selects a kind of cut and the run resolves it to one body; the audit reproduces a figure from it or says why it cannot. A cut that nobody consumes is a day's paperwork, and a run that names no cut is a number whose production no screen can account for — which is what the report binding decision recorded when it found that a binding to a curve left the deal population open. That decision is now superseded in part: the cut is what a run names, and the binding row retires.
Reporting is the only surface. There is no pricing screen, so a cut is not chosen while a price is looked at: a report carries a cut selection, and the run resolves it. A selection is a kind — end of day, start of day, independent verification, a process-named instant, or LIVE — or a specific cut. LIVE is the kind whose body does not exist until a run gives it a timepoint: the run mints the cut it prices from.
1. Journeys
| Journey | Actor | Gist |
|---|---|---|
| Take a cut | finance, market-risk, trading-desk | Choose the kind and its timepoint, assemble the body, review what it holds against the previous cut, take it, and have a second person authorise it — or read the gaps that stop it |
| Give a report its cut | market-risk, tenant administrator | Give a report its cut selection on create or update, read what the selection would resolve to now, run the report, and read the run that resolved it to one cut — with the badge on the report and the cut on the run's card |
| Rerun and audit a cut | auditor, market-risk, engineer | The body, the two acts, the runs that rested on the cut, and a rerun compared with its original in one of three verdicts |
Two of the three write: the take writes the cut and raises its authorisation, and a rerun writes a run. The audit writes nothing, and the cut it reads is immutable once taken.
2. What a cut is here
The cluster states it. The body holds the deals, the market data, the reference data, and the engine and code versions; the cut records the taking identity, the authorisation and the gaps as the acts around the body. The occasion a cut is taken for classifies it, and the purpose — a valuation that can be reproduced — fixes the body for every occasion, so a flash cut and an end of day cut hold the same four inputs.
Two facts about our system shape all three journeys. No cut exists today: no component, no table, no read and no screen. And where a cut would fix a body, the repository holds a read that re-resolves: the curve snapshot read carries no as-of, and the trade store's intervals are rewritten when a correction arrives. The journeys therefore name operations that do not exist, and each says so in its What is missing section rather than drawing a screen the server cannot answer.
3. The states, in one place
A cut is drawn in one of six states, and the derivation is on the decision note. The three journeys use the same words, and the same words appear on the screens.
| State | The person's reading | The run's answer |
|---|---|---|
| Draft | The take began and no body is fixed yet | Nothing |
| Incomplete | The body could not be assembled, and the gaps say why | Nothing, and the gaps name the remedy |
| Taken | The body is fixed, its kind requires an authorisation, and nobody has signed it | Nothing, and the refusal names the request it waits on |
| In use | The body is fixed, and its kind requires no authorisation | It prices from the cut |
| Authorised | A second person signed the body | It prices from the cut |
| Refused | The signature was refused, with the reason | Nothing; the remedy is a new take |
| Superseded | A later cut of the same kind and scope replaced it | It prices from the cut, and says a later cut is in use |
4. Who reaches the screens
| Actor | What they read | What they change |
|---|---|---|
| finance | The cuts of their party, the body's parts, the gaps, and the requests they must decide | Take a cut; authorise one they did not take |
| market-risk | The same rows, and the independent verification cut they take | Take a cut; authorise one they did not take; choose the cut a report prices from |
| trading-desk | The flash cut of the day and the runs that priced from it | Take a flash cut |
| auditor | Every cut, its acts, its runs and the comparison of a rerun | Nothing |
| engineer | A comparison that differs, and the versions on each side | Nothing; the remedy is a change to the engine, which is another journey |
The reads are reporting::cuts:read and reporting::report_instances:read, the
take is reporting::cuts:take, and the decision is the permission the inbox kind
names, which for a cut is inbox::approvals:decide_finance — a permission the
inbox already holds. The two cut names are proposals, and the
decision note states why they take
the shape they do.
An approval is not this group's record. The request, its queue, its decisions, its four eyes and its notifications are the inbox's, and a cut that requires an authorisation raises a request of a kind the reporting component registers. A cut of a kind that requires none raises nothing, and its record states the basis.
5. Where the screens are
The area is Reporting, because a cut exists for the run that consumes it and a
person who asks what a result was computed from looks where the reports are. The
trail of the list is Home, Reporting, Cuts; the record adds the label; the take
flow is a workflow at /reporting/cuts/take, listed in the Workflows menu of the
list header as the Menu structure
requires.
The opposite placement is rejected rather than unconsidered. Market data holds the prices and curves that change by the minute, and a cut changes once a day and is not a price; Trades holds what the tenant holds and does with a trade, and a cut is not a trade. The reference data the take reads — the named cut times — is a list that changes by the month and sits in Reference data, which is the one area for such a list.
No BFF route serves reporting and no reporting screen exists, so every surface these journeys name is new. Each journey records that gap, and the prototype draws what the screens would be.
6. The prototype
The the cut prototype draws all three journeys, with its design note beside it. It is one plain page: the cuts list, the cut's record, the take flow, the picker that consumes a cut, the run that names one, and the named cut times of Reference data. Every state the three journeys name is behind the query string.
7. Related
- Cuts — the cluster: the definition, the purpose and the body.
- The cut is the body a run prices from — the states, the permissions, the identity and the second binding.
- Kinds of cut — the occasions the take offers.
- A report binds to a published curve, not to a name — the first binding, and the hole the cut fills.
- Reporting journeys — the group whose report, run and configuration screens these extend.
- Approval requests — the record the authorisation is, and the queue the decider answers in.
8. See also
- User Journeys — the index this group belongs to.
- User Journey Extraction Standard — the checklist these journeys are written against.
- UX — the standard the screens follow.
- Prototypes — where the prototype is inventoried.
- Menu structure — the area and the trail the screens take.