The cut prototype

The decision note settles the record: the facts, the states, the permissions, the identity and the second binding. It does not settle the screens, and the screens are where the model lives or dies:

1. Where do the cuts live, so that a person who asks what a result was computed from finds them?
2. What does a body that cannot be assembled look like, and what may a person do with it?
3. What does a cut look like in every state, and how does a person tell a body that awaits a signature from one that holds none?
4. How does a report come to price from one cut, and where does a person set that?
5. What does the selection read as before a run, and what does the run say once it has resolved it?
6. How does a person tell a report that prices from the close from one that prices from the moment they press Run?
7. What is a named cut time, where does a person read one, and what does the take read from it?

The prototype answers all six, and the notes below say what each answer costs.

Switch with the bottom bar, or with the query string. The default is the list.

The cuts list is the home of the journey that takes a cut, and the cut's record is the home of the journey that audits one. The reports, the report and the selection are the report journey's. The cut types are the lookup both of those read: the take offers the types, and the selection names one.

The type list is a standard Reference data list: the code and its name, the family, whether the type is signed, whether its values are indicative, the retention and the count of cuts the party holds of it. The family is what the list groups by and what a person scanning it reads first, because the three end of day types share a body and differ in their occasion and their retention.

The type record draws four things: what the type is for, in its own description; its rules — the family, whether it repeats, who signs it, whether its values are indicative, the resolution rule it names and its retention with the destination; the rule that a cut copies its type's authorisation and retention when it is taken; and its cuts, grouped.

The grouping rule is one sentence and it is the type's frequency: the group is the period one step above it. A daily type reads by month, which is why the end of day type's October cuts sit under one heading; a monthly type reads by year; a yearly type reads as one group, because there is one of it a year and a decade of them is still one screen; and an on-demand type reads by day, because that is the only period its cuts share. The prototype draws every one of those groupings, and the end of day type's cuts under a single month heading.

The Menu structure asks one question of a screen: which topic would a person look in? A cut exists for one purpose, the valuation a run computes, and a person who asks what a number was computed from looks where the reports are. So the list, the record and the take flow take the trail Home, Reporting, Cuts, and the run settings tab that names a cut sits among the configuration's own tabs.

Two placements are rejected. Market data holds the feeds 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 is the opposite case: a named cut time is a list that changes by the month, so it sits in Reference data among the currencies and calendars, and the option-expiry sense of the word reads the same list.

The prototype adds no area and no card, because the menu page's rule is that a screen is added to an area page as a card when the screen exists. The page states the area and the trail, and the card follows the build.

The table is the standard's list with one column of the design's own: State draws the derived state as a badge, and under it the fact that qualifies it — a superseded cut says when it was replaced, a taken cut says which part it waits on, and a cut in use says that its kind requires no authorisation. Two columns answer the question the cluster exists for: Taker and Authoriser, and the count of Runs that priced from the body. The Authoriser cell is a dash for a cut whose kind requires none, and the state beside it carries the reason.

The default order is the timepoint, newest first, because the person reading the list is asking which body the next run will price from. A superseded cut sits under the one that replaced it and stays in the list: the runs that priced from it still reproduce from it, so hiding it would hide the provenance of a result.

The state badges follow UX Language. Grey is an inactive record, so Draft and Superseded are grey. Blue is pending, so Taken is blue. Green is the colour of a record that is active and in order, so Authorised and In use are green: both are bodies a run may price from, and the word and the line under it say which basis admitted each one. Red is a body that failed, so Incomplete and Refused are red.

The indicative mark is drawn apart from the state, as a violet tag beside it, because it is a fact of the kind and not a state of the cut: the flash kind fixes indicative values, so its cut is In use and its results carry the mark, while the start of day kind requires no authorisation either and carries no mark. A mark that stood in the state column would say that the two cuts stand differently, and they do not.

Two notices sit under the table. One names the cuts that are not consumable and their states, so a person knows the reports of the scope are refused before trying to run one. The other names the cuts in use with no signature and says why they are admitted, so a body nobody signed is not read as a body somebody forgot.

The body is the design's own tab, and it draws the four inputs the Cuts note argues for: the deals with their counts and states, the market data as a fixed snapshot with its sets, values and fixings, the reference data by version, and the engine and the code. A sixth panel draws the identity: the derived label, the kind, the timepoint with its timezone, the cut time it read, and the take ordinal.

The gap list is drawn where a body could not be assembled, as a table of part, item, why it stands and what closes it. The shape is the one thing in this prototype that no rule covers, and the note names it as the candidate for a standard: a configuration's import lists what it could not read, and this lists what an assembly could not fill, with the same three facts — the item, the reason and the remedy.

Authorisation draws one of two things, and the kind decides which. A cut whose kind requires an authorisation draws the acts — taken, and the decision with its decider, its instant and its comment — a panel naming where the request lives (the inbox's kind, the request, the permission that decides it and the queue), and the four-eyes rule as a fact rather than a warning. A cut whose kind requires none draws the one act and the sentence No authorisation is required by its kind, with the reason in the kind's own words, and it says that the basis is a fact of the kind and not an absence to be explained. Runs draws the runs that priced from the body, which is the question a person asks before a cut is superseded. History is the shared timeline, and it is short: the body is immutable once taken, so a signed cut has two entries and a cut that required no signature has one.

The take is the one place where a rail earns its place: it is four acts over one body rather than one edit, and the review is the point of the exercise. The rail reads: Kind and timepoint, The body, Review, Take the cut. The first step states each kind's basis beside what the kind fixes, so the person who takes a cut reads whether a signature will be needed before choosing one.

Step 2 is where the design has teeth. Every part is drawn with its state — closed or open — and the gaps sit under the table in full. Save as a draft appears in place of Take the cut while a gap stands, and the rule under the buttons says why: a decider would be asked to sign a body that does not meet the definition.

Step 3 reviews the body against the previous cut of the same kind and scope, because the movement between two cuts is what the day's reports state: the deals that entered, the deals that left, the states that moved, the values that moved and the versions that changed.

Step 4 draws what the press did, not a success message, and it has two shapes. A cut whose kind requires an authorisation draws the body frozen at an instant, the request raised of the kind the type's approval_kind_code names, in the queue of the permission that decides it, the cut in Taken, and the statement that the taker cannot authorise it — with the button not drawn, which is the standard's rule for an action a person may not take. A cut whose kind requires none draws the same frozen body, the cut in In use, the sentence that no request was raised and why, and the mark its results will carry where the kind is indicative.

There is no pricing surface, so the cut is not chosen while a price is looked at: the report carries a cut selection, and the run resolves it. Three surfaces carry that, and they are reporting's existing screens with one object added.

The reports list gains a Cut column. The badge is a chip carrying the kind's code, and under it the fact that qualifies it: no cut selected, pinned where the selection names one cut, indicative where the kind's values are, and no body until a run for LIVE. The badge draws no green, amber or red, because it classifies the report and does not report its health; the health of the last run keeps its own column.

The report page draws the selection on Definition — the kind, what it resolves against, and the date the report covers — and the cut the last run resolved on Market, because the two are different facts and the second survives the first moving. Under the definition sits the resolution preview, and it is the design's one new part: it states what the current selection would resolve to now, computed by the run's own operation against the same store, with the cut's label, timepoint, state, basis and holdings; or the sentence that would refuse the run, naming the kind it looked for, the date and the scope.

The selection dialog is where a person sets it. It offers the four selection kinds — EOD, SOD, IPV and LIVE — each with the sentence it resolves against and whether it is signed, and the cuts the party holds for a report that pins one body; a flash or process-named cut is pinned, because no rule resolves its occasion. Selecting a kind previews it, and the preview is the same panel the report page draws. A person therefore reads the consequence of a choice before saving it, which is the whole reason the preview is the run's operation and not a second rule written for a screen.

The run's page begins with the sentence that says what it resolved: the report selected EOD, and the run resolved it to that cut — or, for LIVE, that the run minted the cut at its own instant. Below it sits the binding decision's card, read through the cut: the label, the kind, the timepoint, the scope, the counts, the taker, the engine version and the cut's basis, with the indicative mark where the kind carries one.

Below the card sits the comparison, in three verdicts. Reproduced draws the two runs' figures as equal and says they are one result computed twice. Differs draws the figures that moved, and says the body and the engine are the same, so the difference is a defect and not a movement of the market. Cannot be compared names its reason, and one of the reasons is the LIVE case: a report run twice on LIVE minted two bodies, and the card names both cuts and says the first is reproduced only by naming its cut.

The strip above the runs switches between every outcome — three verdicts, the reasons, and the refusals — because a reviewer cannot judge the design from the happy path. The refusals name the selection: no cut of that kind and date, a cut taken and unsigned, a cut whose body has gaps, a cut that was refused, or a report that selects nothing.

The reference data surface is a standard list and a standard record. The list draws the code and name, the time of day, the timezone, the centre, the kinds the cut time serves and the counts of what uses it. The record carries the fields, the daylight-saving rule, what uses the row, and its history, and it states the rule that a cut time cannot be deleted while a book or a pair names it.

Three callers are drawn, and only one of them exists as a field: a book's centre, a currency pair's planned default_cut_code, and the cuts that fixed an instant at it. The page states that the times are our convention and no public source fixes them, which is the position the cluster records.

Switch with the bottom bar, or with the query string. The two axes are the surface and the state of the world.

The bottom bar switches the surface and the state, and the query string carries the difference from the default, so any pair can be linked. A row of the reports list opens the report. A kind in the selection dialog writes ?sel, and a cut in it writes ?sel=EOD&pin=<cut>. A row of the cuts list opens the cut, and one of the selection's pinned cuts opens it too. A row of the cut times opens the record. The run's strip writes ?verdict. A kind chosen at take step 1 draws the instant that kind fixes.

Everything on the page is mock data: the party, its three books, its eight reports and their selections, its nine cuts with their labels, takers, authorisers and instants, the twelve hundred and eighty-four deals, the three thousand nine hundred and twelve market data values, the seven published sets, the eight runs and their figures, the six cut times and their counts, and the seven rows of the cut type table, which carry the rules the screens read: the family, the authorisation, the indicative mark, the resolution rule and the retention. There is no server, no session, no framework and no build step. A press writes nothing; the query string is the only state, and a reload returns the page as it was.

The mock tenant's clock is 07 October 2026, 09:00 UTC, which is the clock the market bindings prototype uses. The published sets the market data half names are that prototype's own fixtures moved on a day, so the two pages agree about ACME London's USD-SOFR-3M curve: the set published on 06 October at 16:00 and in use, publish record 8f2a4c19.

The reviewer should know five assumptions. The scope is a book group of the London centre, which the decision note takes as the convention and leaves open. The end of day cut of 06 October is the one a report resolves to, because the close of 07 October has not happened at the mock clock. The end of day and independent verification kinds require an authorisation, decided by the permission the inbox kind names, inbox::approvals:decide_finance; the start of day, flash and LIVE kinds require none. The flash and LIVE kinds fix indicative values while the start of day kind does not, which is the pair that shows the two declarations are independent. And the date a report covers is read from the fixture's own field rather than from the run settings, because no read joins the two.

The prototype is doc/prototypes/cuts/the-cut/index.html: one file, with its CSS and its JavaScript inline, no framework, no prototype.css, no prototype.js, and no build step. The site build copies the directory as it stands and adds nothing to it.

The product screens would live here:

The operations exist except where the design note says they do not. The inbox's raise_approval and decide_approval are the platform's, the published reads are ores.marketdata's, and every cuts read and write is missing.

Open. It is offered for sign-off with the decision it draws.

The design to sign off is: a cut selection on the report definition, set on create and on update, with the badge on the reports list and the report page; the resolution preview computed by the run's own operation; the run resolving the selection and recording the cut, its timepoint and the selection it resolved from; LIVE as a kind whose body exists only after a run; cuts in Reporting with the list, the record and the four-step take; the seven states in the UX Language's colours with In use for a body whose kind requires no authorisation; the basis drawn under every state that has one and apart from the indicative mark, which is the kind's; the run's card read through the cut with the comparison in three verdicts; the named cut times as reference data in Reference data, and the cut types beside them — a lookup a person maintains, whose rules the take, the resolution and the archive read, with each type's cuts grouped by the period above its frequency. It also signs off the retirement of the market bindings, which the binding decision now records as superseded in part.

Two screens of the eleven are built: Reference data > Cut types, with the list and one type's record, and Reporting > Cuts, with the list and one cut's record. The first unit reads them and draws them; the take flow, the authorisation, the report's selection and the LIVE mint are the units that follow.

Five things the build settled, each read from the prototype and recorded here because the page above argued them.

The type list and the type record draw the approval kind's name and the permission its decider needs, and a dash where the type names no kind. The build reads that target through the inbox's own approval kinds, so a firm that gives the close to another function changes one approval kind and no type.

Both are functions of the facts a cut records, and one operation answers both so the list, the record and the resolution cannot disagree. The one rule the screens hold is the sentence under a state, which says which fact admitted the body.

draft badge, Incomplete and Refused its failed badge, Taken its pending badge, In use and Authorised its active badge, and Superseded its inactive badge. The indicative mark is a separate chip, which is a proposal the catalogue has no word for yet: no badge definition holds indicative.

no read answers. No operation returns the deals a population holds or the sets a snapshot fixed, so the deals card and the market data card name the reference and state the gap in the app's own words rather than leaving the card empty.

grouping is the screen's. A daily kind reads by month, and the operation answers the cuts of a month. Creating a type is not offered: its retention destination is a tier the store knows by a check and no lookup names the tiers, so a form that created one would invent the store's vocabulary. Changing and removing a type are offered, and the write keeps the destination the type holds.