User Journey: Take a cut

"The centre has closed and the day's reports are waiting on a body of data nobody has fixed. I want to say which cut this is, see exactly what it holds before I commit it, be told plainly and early when a part cannot be assembled, and have somebody else sign it off where the occasion calls for it, so the numbers the reports show can be reproduced next year. When it is authorised I want the cut to be an object I can point at, and not a date that means something different tomorrow."

The journey is done when the cut holds a body, a second person has authorised it, and the cut's page says so — or when the body cannot be assembled and the page says why, in items a person can chase.

A finance officer runs this journey for the end of day kind, and a market-risk owner for the independent price verification. Both act inside their own party and inside their own tenant, on the books whose centre they own. A desk runs the same journey for a flash cut at an instant it states.

Three permissions decide what the person sees. Assembling and taking a cut needs reporting::cuts:take. Reading the cut and its gaps needs reporting::cuts:read. Deciding the authorisation needs the permission the inbox kind names in its decide_permission_code, which for a cut is inbox::approvals:decide_finance — a permission the inbox already holds, held for a cut by a person other than the taker. The rule that the asker never decides is the schema's, not this feature's, and Approval requests states it. A person who may not take a cut is drawn no button, as the Record screen standard requires. The Reporting area is drawn for a person who holds reporting::report_definitions:read, which is the read the area already asks for; the Cuts card inside it is drawn for reporting::cuts:read.

The trigger is the close of a business day, or a correction that moves the day's population after its cut was taken. The person opens the cuts list because the reports of the day cannot run, or because the deal cut must be retaken until the population is clean, as the Cuts note records. The journey ends on the cut's page, in a state the page draws.

This journey takes a cut and has it authorised. The cut is taken for a report to price from, and the report selects it through Give a report its cut; the two journeys meet at the resolution, which reads the cuts this one leaves behind. The kind whose instant a run supplies is not taken here at all: a LIVE cut is minted by the run that consumes it, and a person never presses a button to make one.

This journey does not approve or withdraw a published curve — those are Ask for a publish to be approved and Withdraw or replace a published curve — and it does not run a report. It does not author a convention, a calendar or a curve configuration: it reads the version in force and records it.

Three surfaces: the cuts list, the take flow with its four steps, and the cut's record page.

The list is the standard's. The take flow is the one place where a rail of steps earns its place, because the work is four acts over one body rather than one edit: the kind and the instant, the assembly with its gaps, the review against the previous cut, and the press that takes and raises. The record page is the standard's record page with four tabs: The body, Authorisation, Runs and History.

The judgement, per step, against the record screen standard.

The the cut prototype draws this journey, and its design note says what it argues, which states it draws and what is fake. It belongs at doc/prototypes/cuts/the-cut/.

It is one plain page with six surfaces behind the query string: 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 reference data. For this journey it draws a day with no cut, a draft, an incomplete body with its gaps, a taken cut awaiting its kind's authorisation, a cut in use whose kind requires none, an authorised cut, a refused cut and a superseded cut. Every value on it is a fixture, and the page says so.

The rows this journey writes are the cut and, where the kind requires one, the request with the cut's detail. The take writes them together, so the body a decider reads is the body that was frozen. The build order follows the platform's own: the model, then the store, then the operations, and the screens last.

The take is one call and not three, because the body, the request and the cut's state land together or not at all. A take that wrote the body and then raised the request would leave a cut nobody is asked to sign. The request itself is the inbox's call: the take knows the kind and the body, and the inbox knows the record, the rules and the queue, so neither reimplements the other.

1. No cut entity and no component. No cut component exists, no table holds a cut, and no service answers a read of one. The decision note settles what the record must hold; the model, the store and the operations are the work that follows.
2. No read answers a population at an as-of. The trade store is versioned, so a query over its intervals reconstructs a past state, and no operation exposes it. The Trade cut page states the second half of the gap: the interval a row states is rewritten when a correction arrives, so a re-run of the same query returns a different body. The cut therefore copies the population it fixed, and the copy has no home yet.
3. No fixed market data snapshot. The Market data cut page records that marketdata.v1.curve_snapshot.get re-resolves on every call and carries no as-of, and that the resolution-side snapshot exists as a definition and no entity. A cut records the identity of a snapshot that nothing materialises.
4. Nothing records the service build. The engine version survives because a workunit names an app version. The revision of the services that gathered the body does not survive anywhere, and a result reproduced from a different build of the gathering code is not reproduced from the same software, which is the condition the Cuts note quotes.
5. No gap list exists anywhere. A configuration's import lists what it could not read, and nothing lists what an assembly could not fill. The screen needs one, and the prototype defines the shape the standard would take.
6. The kinds of cut are not a vocabulary in the store. The four occasions are stated in a knowledge page and in no table, so nothing holds the two facts the take and the gate turn on: whether a kind requires an authorisation, and whether its values are indicative. A kind held as a code in a populated list, with those two columns, is the smaller change. And the approval kinds the types name are not seeded. reporting.eod_cut_authorisation and reporting.ipv_cut_authorisation exist in no seed, so a type that names one has nothing to raise. Each row is small — a code, a decide permission, one approval, no hold, no expiry, no apply workflow — and the queue and the request page take it without a change of their own.
7. No route and no screen. No BFF route serves reporting, and no reporting screen exists in the web application, so the cuts list, the take flow and the record are all new.
8. The cut's approval detail row and its descriptor exist; the subject link and the apply do not. The inbox draws a kind through a detail row keyed by the request and, on the web, through a KindDescriptor that names the kind, its words and its own section. The cut carries both: its detail row is keyed by the request, and its descriptor names the close's ask and the verification cut's. Two things are still missing. Nothing answers a cut by the request that raised it, so the request page says where the body is read and links it not, rather than offering a link that leads nowhere. And the apply that writes the cut's authorisation on approval is not built, so the record states that instead of drawing an apply nobody made.
9. The cut times reference data does not exist. The close of a centre's business day is a fact a person needs and no table holds it for our centres. The prototype draws the reference data the take reads, and the option-expiry cut code page states the row the expiry sense needs from the same list. The take therefore asks a person to type the instant and says on the step that it does, because a field that looked up nothing would read as a fault.
10. No read compares two bodies. Step 11 asks the review for the differences from the previous cut of the same kind and scope, and no read answers them: the deal population, the market data and the reference data are each read at one instant and nothing reads two instants and states the movement between them. The take's review step states what the body holds and says the comparison is not read, rather than drawing an empty list of differences.
11. No read answers the books of a scope. Step 7 states the books a scope holds and the centre they revalue against, and `reporting.v1.cuts.read_scope` is missing: nothing reads a book's classification, so nothing can refuse a scope that spans two centres before the assembly meets it. The take asks a person to type the scope and the centre and says on the step that the two are not checked against the books.

• Give a report its cut — what the cut is taken for: the report's selection, and the gate the resolution meets when no usable cut exists.
• Rerun and audit a cut — the runs that price from this cut, and the reproduction of one of them.
• Ask for a publish to be approved — the remedy for a curve that is still a candidate, which is one of the gaps.
• Decide a publish — the decision the gap waits on, and the same inbox this journey's authorisation uses.
• Publish the approved set — the act that makes a set the market data half can fix.
• Sign off a pricing engine change — the same approval machinery, drawn for a change rather than for a body.
• Bind a report to a published curve — the other half of what a run names, and where the cut is chosen.
• Change what a report runs — the change that makes a cut stale before it is taken.

• The cut is the body a run prices from — the decision this journey draws.
• Cuts — the definition, the purpose and the body.
• Kinds of cut — the kinds, what each fixes, and the two that need no authorisation of their own.
• Market data cut — the half of the body this journey assembles from published sets.
• Trade cut — the half it assembles from the versioned trade store.
• Naming the cut — why the label is qualified and why the word is kept.
• The option-expiry cut code — the reference row a cut time is, and the second sense of the word.
• Book groups and rates centres — why a scope revalues against one centre.
• Approval requests — the record the authorisation is, its rules, its queue and its lifecycle.
• Operational authorisation — where the argument that an authorisation is metadata, and not the record it releases, is made.
• Implement four-eyes authorisation framework — the deferred work that would add several deciding functions, which a cut does not need.

• Cuts journeys — the group this journey belongs to.
• User Journey Extraction Standard — the checklist this journey is written against.
• Record screen standard — the list, the record page, the writes and the states.
• Menu structure — the area and the trail.
• UX Language — the state colours and the access mark.
• New tenant — the journey that stands up the centre a cut time belongs to.