The cut is the body a run prices from

Table of Contents

1. Summary

The Cuts structure note fixes what a cut is, what it holds and why. It settles no state, no act, no authorisation, no identity, and nothing about what selects a cut. This page settles them. A cut records the body it fixed and the acts that made it, and nothing else; its state is derived from those facts and stored nowhere; a cut kind declares whether a cut of its occasion needs an authorisation, and where it does the authorisation is an approval request of the inbox. A report carries a cut selection as a property — a kind, or a specific cut — and the run resolves the selection to a concrete cut at the moment it starts, records that cut and its timepoint, and prices from its body. One selection kind, LIVE, has no timepoint of its own: the run supplies it, and the run mints the cut.

The authorisation is not a mechanism this cluster invents, and neither is the selection a second market association. One record already holds everything that waits on a person, and one object now names the body a run prices from, which is what the market bindings were doing in the absence of a cut.

Everything on this page is our working convention. No public source states how a firm should model the authorisation of a cut or the selection a report carries, and the Cuts note records which claims in the cluster rest on a source and which do not.

2. What the screens must settle

Three journeys and one prototype need six things, and the cluster's domain pages supply none of them.

Need The question Where the answer is
The facts What does the record hold, against what the cluster argues it must hold? The facts a cut records
The states What is a cut before it is authorised, and what may a run do with it then? The states and what derives them
The acts Who takes a cut, what authorises it, and what stops one person doing both? The authorisation is the inbox's
The permissions Which permission reaches each act? The permissions
The consumer How does a report come to price from one cut rather than another? The report carries the cut
The identity What does a person quote, and is it typed or derived? The identity

3. The facts a cut records

A cut records six groups of facts. The parts are the body the Cuts note argues for; the other five groups name the occasion, the scope, what the assembly could not fill and who acted.

Fact What it holds Why the cut records it
The kind The occasion, from the closed set Kinds of cut classifies, and the instant a process names where no kind applies The kind fixes the instant, the recurrence and the centre, and it declares whether a cut of the occasion needs an authorisation
The timepoint The instant, with its timezone, and the cut time it came from where a named cut time supplied it A body fixed at an instant is not fixed until the instant is stated with its clock
The scope The books whose deals the valuation values, and the rates centre whose market data they revalue against A body that names no population values nothing, and a market data half with no centre denotes whichever centre answered first
The parts One reference per part of the body: the fixed market data set, the deal population, the versions of the reference data and the settings, and the engine and code versions The four inputs are what the reproducibility argument requires, and a reference is what a rerun replays
The gaps Every part the assembly could not fill, with the item, the part and the reason A body that could not be assembled is a fact a person acts on, and silence makes the cut look smaller rather than incomplete
The acts Who took the cut and when, and the authorisation: the request the take raised, the decision it reached, the decider and the instant, or the refusal and its reason — or, where the kind requires none, the fact that none was required The taking identity and the authorisation are not inputs to the valuation: an unsigned body is a candidate, and an occasion that needs no signature still has to say so rather than look unsigned

Two of these facts are ours alone and no prior art supplies them. The gap list follows from the definition: a cut missing a part is incomplete rather than smaller, so the absence is recorded where the body is recorded rather than left to a run to discover. The act of taking follows from the same sentence: something fixes the body, and the something is a person acting at an instant — or, for the one kind whose consumer supplies the instant, the run acting for that person.

3.1. What is derived, and why nothing is stored

The state, the consumability verdict and every word the screens print about a cut are functions of the facts above. None is stored.

The precedent is the published set. ores.marketdata.curve_publish states that the state a reader sees is a function of the stored facts and is stored nowhere: withdrawn when an instant holds, superseded when an instant holds, published when an instant holds, and a candidate otherwise. A cut has the same shape and the same reason. A stored state follows a write that may fail, may be repeated or may be missed, so the row and its state can disagree; a derived state cannot disagree with the facts it is derived from.

3.2. The kind is reference data

A kind is not a sentence in a knowledge page. It is a row of a lookup a person maintains, because four of the facts it carries are decisions a firm changes and reads back: whether the occasion is signed, whether its values are indicative, how a report resolves it, and how long its cuts are kept.

Column What it holds Why it is the kind's
code, name, description The kind's identity, in the reference data's own words A person selects it by code, and a person new to the team reads what it means
family_code The family the kind belongs to: end_of_day, start_of_day, verification, intraday, consumer The family fixes the body rule and the source of the instant; a kind inside it fixes the rest
approval_kind_code A nullable foreign key to ores_inbox_approval_kinds_tbl: the inbox kind that authorises a cut of this type, or null where none does The end of day types point at a kind whose decider is Finance, the verification at one whose decider is Market Risk, and the open, the intraday and the live views point at nothing. The column is the whole of the authorisation rule; the signed-or-not a screen draws is derived from it and stored nowhere
output_is_indicative Whether a result priced from a cut of the kind carries the indicative mark The intraday and the live views are indicative; the close and the open are official
resolution_rule_code The rule by which a report resolves a selection of this kind to a cut The resolution states the rules; the kind names one
retention_months How long a cut of the kind is kept before it leaves the warm tier Retention states the rule
retention_destination_code Where a cut of the kind goes when it leaves the warm tier The tiers are the ones the data tiers states
legal_hold_default Whether a cut of the kind starts under legal hold A held cut is never removed, whatever its retention says
display_order The order a person reads the kinds in The take and the selection both read it
version, valid_from, valid_to The bitemporal window every reference row keeps A changed rule is a version a person can read, and no rule is silently overwritten

The authorisation is a foreign key and not a phrase. approval_kind_code points at ores_inbox_approval_kinds_tbl, the lookup the inbox already holds, and a null means the type requires no authorisation at all. A check on the column is a plain foreign key to the approval kinds; the constraint the schema needs beyond it is that a cut minted under a type with a null FK raises no request, which the take enforces rather than the database, because the take is where the request would be written.

Each type names its own inbox kind, so the kinds differ where the deciding function differs: the end of day types point at reporting.eod_cut_authorisation, whose decide_permission_code is inbox::approvals:decide_finance, and the verification points at reporting.ipv_cut_authorisation, whose decider is Market Risk. The two rows name the same subject — a cut of that occasion — and differ in who answers.

3.3. Nothing a screen prints about authorisation is stored.** The type list and the

type record draw the words from the foreign key's target: the approval kind's name and the permission a decider needs, such as Finance · decide_finance, and a dash where the key is null. A firm that gives the close to another function changes one approval kind and no type, and every screen that drew the old words draws the new ones.

The kind is held by the reporting component, because reporting both resolves a selection and draws the cuts, and no cut component exists. A cut component would own the kind beside the cuts, and the open list records that as the move to make when the cut entity is built.

3.3.1. Why a family, and why EOM and EOY are kinds

Two questions, and the corpus's own vocabulary answers them. A family groups the kinds whose body is the same and whose instant comes from the same place. A kind is one row per occasion that differs in its declarations.

The end of day family holds three kinds: the ordinary close, the month end and the year end. All three fix the same four inputs, read them at the same centre's close, and differ in one thing that matters to the archive: how long the cut is kept. That is why the month end and the year end are kinds and not a flag on one end of day kind — the retention is the kind's, and one row cannot hold three retention periods. And it is why they are one family and not three, because a report that selects the ordinary close must still price from the body fixed at a month end, and the family is what lets it.

The start of day family holds one kind, the verification family one, the intraday family one, and the consumer family one. A family of one is not a wasted row: it states the body rule and the instant source for every kind that will join it, and a kind that fixes the same body at a new instant is added to it rather than invented beside it.

3.4. Resolution rules the kind may name

Rule code What it resolves to
same_day_close The end of day family's cut of the date the report covers, at the centre's close
last_business_day_of_month_close The month end cut of the month the report covers, at the close of that month's last business day
last_business_day_of_year_close The year end cut of the year the report covers, at the close of that year's last business day
same_day_open The start of day cut of the date the report covers
cut_it_is_built_on The verification cut of the date the report covers
run_instant A cut the run mints at the instant it starts
the_cut_named The cut the selection names, and nothing else

A kind whose occasion no rule can resolve names the_cut_named, and a report reaches its cuts by pinning one rather than by selecting a kind. The intraday flash cut and any cut an ad-hoc process names are such kinds: their instant answers to no schedule, so a report cannot say the flash cut of the date and mean one body. The selection therefore offers the kinds that have a rule, and pins the rest.

4. The states and what derives them

A cut is in one of seven states. Each is stated by the facts that hold, and the order of the tests is the order a reader needs them.

State The facts that hold What a run may do The mark
Draft No taking instant holds, and no gap stands; the assembled body is saved before the take Nothing. It is not a cut yet Grey, the mark of an inactive record
Incomplete No taking instant holds, and one or more gaps stand; the attempt is saved as a draft Nothing. The gaps are the answer Red, because the body failed its own standard
Taken The body is fixed, the kind requires an authorisation, and no approval is recorded Nothing. It is the body the decider reads Blue, the mark of a pending item
In use The body is fixed, and the kind requires no authorisation Price from it Green, the colour of a record that is active and in order
Authorised The body is fixed and an approval is recorded Price from it Green
Refused The authorisation was refused, with the reason Nothing. A refusal is terminal for that body Red
Superseded The cut was authorised or in use, and a later cut of the same kind and scope holds its place Price from it, and say a later cut is in use Grey, as the published lists draw an ended set

The table is a derivation and not a lifecycle: a state is one of the seven and never a mixture of two. Two facts decide which of the three usable states applies, and neither is a matter of taste: whether the kind requires an authorisation, and whether one was recorded.

Six consequences follow, and each is a decision the screens draw.

The gate follows the kind, not a single rule about cuts. A run prices from a body that is fixed and signed where a signature was required. A cut of a kind that requires none is usable the moment it is taken, and a cut of a kind that requires one is not usable until the approval is recorded. A gate that demanded an authorisation of every cut would refuse the occasions that need none, and a gate that accepted any taken body would price from an unsigned one.

A draft is a record, not a scratchpad, and a gap is what separates it from an incomplete body. The gaps a body cannot close name a person to chase — a series with no value at or before the instant, a deal at no version, a curve nobody has approved, an engine version nothing recorded. A take that threw the attempt away would make the person remember the list. The draft therefore holds the attempt, each gap with its reason, and the cut's own page is where the list is read.

An incomplete body is refused before it is signed. The take raises no request while a gap stands, because a decider would be asked to sign a body that does not meet the definition. The refusal is at the take and not at the authorisation, and the screen says what would close each gap.

A held request leaves the cut where it was. The inbox's hold state parks the request and not the body, so the cut stays Taken, its card reads that the request is held, and the waiting time is the request's to report.

Supersession does not withdraw authorisation. A superseded cut is still a record of an instant, and a run that priced from it still reproduces from it. The published-set rule that an ended set is refused unless its as-of is pinned does not carry over, because a curve is a value in use and a cut is a record of what was used. The one word the screen must say is that a later cut replaced it: a person who reads a result must not take it for the day's cut.

The indicative mark is the kind's, and it is not the state's. A result priced from a flash cut or a LIVE cut is indicative because the kind says so, and the mark is drawn on the cut, on the selection's badge and on every result it prices. A cut of a kind that requires no authorisation is not therefore indicative, and the start of day kind is the case that shows it.

A LIVE cut is never a draft and never taken by a person: the run mints it with its body already fixed, so its first state is In use. A selection whose cut does not exist yet is not a state of a cut at all — there is no row to carry one — and the resolution refuses such a run and says which cut it looked for.

5. The authorisation is the inbox's

A cut that requires an authorisation raises an approval request of a kind the reporting component registers. Nothing about the wait for a person is the cut's own: the record, its lifecycle, its rules, its queue, its notifications and its history are the approval request's, and the cut adds a detail table and a descriptor.

What the cut needs Where it lives The precedent
The record of the ask, the decision and the wait An ores.inbox approval request: its kind, state, asker, reason, decision and expiry Approval requests
What the request is about A detail table in the reporting component, keyed by request_id: the cut and the counts of the body's parts ores.marketdata.curve_publish
Whether a cut needs one at all The cut kind's approval_kind_code, and the take raises nothing where it is null The kind is reference data
Who may decide The inbox kind's decide_permission_code Decide a publish
How many approvals close it The inbox kind's approvals_required; one for a cut Decide a publish
Four eyes A rule of the schema: a decision by the asker is refused, and one person counts once Approval requests
The queue The shared Approvals read, filtered to the kinds the caller may decide Approval requests
One open request per subject The detail table's natural key on the cut, which is what the inbox means by the same subject Approval requests
The screen the decider reads The request page, which draws the kind's detail as its own section the inbox's RequestPage and its kinds.tsx descriptor
Notifications The inbox's: the deciders are told a request waits, the asker is told the decision Approval requests
Applying the decision The reporting service stamps the cut's authorisation facts when the request reaches approved the shape IAM uses for a role grant

The take raises the request, in one act. The body is frozen when the request is raised, so what a decider reads is what gets authorised. The detail row is written with the body and keyed by the request, as the curve publish detail is keyed by its request. A take that wrote a body and then asked for a signature would leave an interval in which the body may move.

The taker cannot authorise, and the rule is not the cut's. The inbox refuses a decision by the person who raised the request, and a unique key on the request and the decider keeps one person from counting twice. A cut adds nothing to that rule and depends on it, which is why the take and the decision are two permissions and not one. A firm with one person who holds both cannot authorise a cut at all: the screen draws the refusal and names what is missing, which is a second person, and it does not draw the button.

A refusal is terminal for that body. The body stays readable, the reason is on the request and copied to the cut's page, and the inbox allows no second decision on a refused request. The remedy is a new take, which is a new cut and a new request, because an approval is a decision on one body and a decided body does not become another.

The apply is a reconciliation, not a second screen. When a request reaches approved, the reporting service writes the cut's authorisation facts and marks the detail row applied. It does so from the request's change event and from the state the request holds, so a missed event, a repeated one, or an approval made while the service was down all converge on one outcome, as a role grant does.

The cut's page links the request and never the reverse. The request is the record of the wait and the cut is the record of the body; the request page draws the body through the kind's detail, and the cut's page names the request. Neither copies the other's facts, because two copies of one act drift.

6. The permissions

Three permissions decide what a person sees and does. Two are the cut's own, and the third is the inbox's.

Permission What it governs Who holds it, in the fixture
reporting::cuts:read The list, the record, the report's selection, and the run's card that names a cut Market risk, finance, a reader
reporting::cuts:take Assembling and taking a cut by hand, which raises its authorisation where the kind requires one Finance, for the end of day kind
inbox::approvals:decide_finance The decision that authorises an end of day cut: the inbox kind's own decide permission Finance, and a different person from the taker

The first two names are proposals and follow the platform's namespace for a component's own record. The third is not new: it is a permission the inbox has already seeded, and the cut's kind names it rather than inventing one.

A LIVE cut is taken by the run, and the run's permission is the reporter's. Nobody presses Take a cut for a LIVE selection, so reporting::cuts:take is not the permission that guards it: the person who may run the report is the person who may cause a LIVE cut, and that is reporting::report_instances:write. The run writes the taking identity as itself acting for the run's account, so the cut's page names a system account and the run that minted it.

The permission is the approval kind's, and a type names its own. A cut body is signed by the function its occasion belongs to, so the end of day types name the Finance kind and the verification names the Market Risk one. The permission is read from the approval kind the type points at, never from the type.

7. The identity

The cut's key is a generated identifier. The label a person quotes is derived from the three facts that name the occasion, and it is never typed: 

<kind code>.<scope code>.<timepoint>[.<take ordinal>]
EOD.ACME-LONDON.2026-10-06
EOD.ACME-LONDON.2026-10-06.2
LIVE.ACME-LONDON.2026-10-07T07:40:00Z

The derivation is the rule the report binding decision applies to a market configuration name: the screen draws what the record will say and no field asks for it. Three reasons carry the rule.

A typed label is a name, and a name is what the binding decision rejects: it says nothing about which body it means, and two bodies can carry one. A derived label states the kind, the scope and the instant, and no second cut can carry it.

The take ordinal is the hub's numbered sequence made visible. A retake of the same day, kind and scope is the second cut of that day, and the ordinal says so in the one place a person looks. A LIVE cut carries its instant instead, to the second, because two LIVE runs in one morning are two bodies and the date alone cannot tell them apart.

The label is not the authorisation. A person reading EOD.ACME-LONDON.2026-10-06 knows which day's body is meant and not whether anybody signed it, so every screen that shows the label shows the state beside it, and a cut of a kind that requires no authorisation shows that basis in the same place.

8. The report carries the cut

A report definition holds a cut selection, and the selection is one of two things: a kind of cut, or a specific cut. The pair is one fact — the kind code with no cut named, or the kind code and a cut — because a specific cut is a kind of cut plus the identity of the one body meant.

The selection sits on the definition, and not on the run settings configuration. Four reasons carry the choice.

A report is the thing a person reads a badge on, and two reports bound to one configuration may serve different cycles: a board pack of the close and an intraday monitor share an engine but not a body. A selection on the shared configuration would give both the same badge and the same body, which is false for one of them.

The selection states what the report is, beside its type, its scope and its regulatory book type. The configuration states how the engine runs and which documents it reads. The two are different kinds of fact, and the badge belongs to the first.

The definition is versioned, so a change to the selection is a version with an account and a reason, and the runs already produced keep the cut they recorded. A change on a shared configuration would reach every report bound to it without any of their pages saying so.

A report is a version of an intent, and the intent is value this scope against the close of its day. The configuration cannot express that sentence for one report and not for another.

The badge is the selection's kind, drawn on the list and the record. A person who reads a list of thirty-one reports sees which of them price from the close, which from the open and which from the run itself, without opening one. The badge is a chip carrying the kind's code, and under it the fact that qualifies it: no cut selected where the report was created without one, pinned where the selection names a specific cut, and indicative where the kind's values are. LIVE is the one kind whose badge carries a note rather than a value, because its body does not exist until a run gives it a timepoint.

The badge is not a status: it is a classification of the report, so it borrows no green, amber or red. The health of the last run stands elsewhere on the row, where the reporting journeys already put it.

Create and update ask for the selection and nothing else. The selection is one field on the create flow and one field on the report's Definition tab, and the dialog offers the kinds the party may select plus the cuts already taken, with a preview of what the current choice would resolve to right now: EOD would resolve to EOD.ACME-LONDON.2026-10-06, authorised by a.reyes, or LIVE will fix a body at the instant the run starts, and every result it prices is indicative. The preview is the resolution the run will make, run against the same rules and the same store, so a person sees a stale choice before a run discovers it.

9. The resolution

The selection is a rule; the resolution executes it. The run resolves the selection to a concrete cut before it gathers anything, and the rules are five.

Selection Resolves to Its timepoint What the resolution refuses
EOD The end of day family's cut of the date the report covers — plain, or the month end or year end cut where that date is one — for the report's scope and centre The centre's close of that date No such cut, or one whose authorisation is not recorded
EOM The month end cut of the month the report covers, taken on that month's last business day The close of that last business day No such cut, or one whose authorisation is not recorded. A plain end of day cut on that day does not serve, because its retention is the shorter one
EOY The year end cut of the year the report covers, taken on that year's last business day The close of that last business day No such cut, or one whose authorisation is not recorded. A month end or plain cut on that day does not serve, for the same reason
SOD The start of day cut of that date, for the same scope The centre's open of that date No such cut
IPV The independent verification cut of that date The close of the cut it is built on No such cut, or one whose authorisation is not recorded
LIVE A new cut, minted at the run's instant The instant the run starts A body that cannot be assembled
A specific cut, of any kind Itself The cut's own instant A cut that is not consumable, or one of another party or scope

A flash cut and a process-named cut are not selected by kind. No rule resolves the occasion a flash cut takes, and the instant a process names belongs to that process: a report that wants either pins the cut.

The date the report covers is not the cut. The report's covered date is a setting of the run settings, and the resolution reads it together with the report's scope and its centre. A cut states its own instant; the date says which cut to look for. That is why a weekly report can price from the daily cut of the day it covers, and why the same report next week prices from a different body.

The scope is not chosen at the resolution. The report's scope names books, and Book groups and rates centres states that the books that revalue together share one centre's market data. The resolution reads the centres of the report's books, and a scope spanning two is refused before anything is gathered: no cut of one centre can value books that read another.

A refusal is one sentence, spoken before the engine. A selection that resolves to nothing is refused with the kind it looked for, the date, the scope and — where there is a cut but its authorisation is not recorded — the request and the person it waits on. The preview's sentence, the report page's sentence and the run's output message are one sentence, so a scheduled run nobody watched still says why it did not price.

The run records what it resolved. The run keeps the cut, its label, its kind and its timepoint, and the report's Market tab shows the selection beside the last run's resolved cut, because the two are different facts: the selection may have moved since the run. The run's own card names the body, read through the cut.

The resolution is one operation and it is previewable. One operation answers the cut a selection resolves to, its state and the sentence that would refuse it, for a preview or for a run. One operation serves both, because a preview computed by a second code path is a preview of that path and not of the run.

10. Retention

A cut is kept for as long as its kind says. The rule is short and it has three parts.

The kind states the period and the destination. retention_months and retention_destination_code on the kind are the floor and the place. The periods are ours and the fixture draws them: an end of day cut is kept 25 months in the warm tier, a month end 84, a year end 120, a verification 84, a start of day 25, an intraday view three, and a live cut one. A year end is the longest because it is the body a yearly report states and the body an auditor asks for years later; a live cut is the shortest because it is a view and its result is reproduced by naming it.

The cut records the rule it was taken under. A cut copies its kind's retention and destination when it is taken, so a later change to the kind does not move the retention of a body already fixed. The opposite would be a rule that rewrites the past: a firm that shortened a kind's period would delete cuts it had promised to keep, and no record of the promise would survive the change.

The kind's rules are read live where they are a decision and copied where they are a promise. Authorisation and indicative values are recorded on the cut when it is taken, because they are facts about that body. Retention is recorded with them, for the reason above. The resolution rule is read from the kind at the moment of the resolution, because a report resolving today must follow today's rule and not the rule in force when the report was defined.

Retention is a floor, and a person may raise it. A cut's retention may be extended by hand, with the reason and the account, and never shortened below its kind's period: shortening is a change to the kind, where it is a decision a person with the right permission takes and a version the history holds. The extension is drawn on the cut's page beside the kind's period, so a reader sees which of the two is in force.

A legal hold outranks both. A cut under legal hold is never removed, whatever its period says, and neither is one whose kind's default puts it there. The hold is a fact a person sets — on the kind as a default, or on one cut — and clearing it is its own act with its own reason.

Nothing removes a cut today. No retention job exists, and this page states the rule the archive will follow rather than a job that runs. What the rule already decides is that removing a cut is an archive act and not a delete: the row moves to the destination its kind named, and the run that priced from it keeps a reference that still resolves.

11. The LIVE kind

LIVE is the kind whose timepoint the consumer supplies. It differs from the four occasions of Kinds of cut in that nothing outside the run fixes it: no centre publishes its instant, no person chooses it, and no process names it. A report that selects LIVE says value this scope at whatever time you start.

Its body is the four inputs at the instant the run starts. The population is what the trade store holds then, the market data is the snapshot the profile resolves then, the reference data and the settings are the versions in force then, and the engine and code are what the run will execute. It is the whole body and not a smaller one, because a LIVE result that could not be reproduced would be a number with a claim it cannot meet. If a part cannot be assembled the run is refused with the gaps, and no partial body is minted.

Its values are indicative, and that is our convention. No authorisation precedes a LIVE cut, and the values it fixes are the values in the store at the instant the run began, which the day's official data will replace. A result priced from a LIVE cut therefore carries the indicative mark, as a flash result does, and the mark is read from the kind.

It requires no authorisation, and the reason is structural. The run both mints the cut and consumes it in one act, so an authorisation would hold the intake until a person answered, and the report it serves would have no result by the time it was read. Four eyes is not weakened by this: nothing is signed, so there is no signature to protect. A firm that wanted LIVE signed does not want LIVE; it wants a flash cut, which a person takes at an instant they name, and which is signed or not by its own kind.

A LIVE cut is reproducible only by naming it. A rerun of the same LIVE report tomorrow resolves to a new instant, so it is a different body and a different result. The first result is reproduced by naming its cut: a selection of that specific cut, or a rerun against the resolved cut, which the run's page offers because the run knows what it priced from. The card states the difference in the words the reproduction verdict already uses: two runs of one cut are one result computed twice, two LIVE runs are two results of two bodies and comparable only as a movement.

Supersession applies as it does to any cut. A later LIVE cut of the same kind and scope becomes the kind's cut in use, and the earlier one stays in use as a record. Because LIVE cuts accumulate at the rate of runs, the cuts list's kind filter and its date order are what make them readable, and a LIVE cut's label carries its instant to the second for the same reason.

12. The role bindings retire

The report binding decision made a run settings configuration name, per market role, the published set the run prices from, with its as-of, a pin for a historical rerun, and a derived ORE name. That row was the report's market association because nothing else named the market a run read. A cut now names it, and two records that name the same curves drift.

The finding. A binding row and a cut both name the curves a run reads. The binding names one published set per role at an as-of; the cut names the fixed snapshot that resolved every role at its instant. Where both stand, a report can price from a binding that disagrees with its cut — and the pin makes the disagreement look deliberate. The precedence is not a matter of taste: the cut is the body, the binding is a rule of the profile the body was built from, and a rule does not travel with the result. A result that named a rule instead of the body would be reproducible only while the rule and the store held still.

What the selection replaces. The configuration's market bindings, the Market bindings tab, the pinned as-of, and the binding row as an input to a run. The profile the bindings were — one published set per market role — becomes a fact of the market data side, resolved when a cut is assembled, which is where the Market data cut page already puts the profile.

What carries over, and is not lost. The published-state refusal still holds, one layer down: a candidate set cannot be part of a body, so the assembly reports it as a gap and the cut is incomplete rather than wrong. The ORE market configuration name is still derived from the curve and the party, and the cut's market data half records it. The export still builds the XML from the published set's points, in the ORE vocabulary of the boundary (ORE import and export). The run's market card survives and is read through the cut. The role vocabulary problem survives with it, because the roles are still a free string in the profile.

What retires with the row. The pin, because naming a specific cut is the same intent and is stronger: a pinned as-of reproduced one curve, and a named cut reproduces the whole body. And the picker over published sets on the run settings, because a person who wants a particular curve publishes it and takes a cut; the report then names the cut.

The supersession is marked where the decision is cited. The earlier page carries a dated status note saying which parts stand and which retire, and the pages that cite it say superseded in part where they name its row, its pin or its tab. Its argument — that a name is not provenance — stands, and it is the reason the cut, and not a name, is what a run now records.

13. How it meets the report binding

The earlier decision asked for a binding that names the published set rather than a free name, and recorded that it left the deal population open: a report that must state both needs a second binding, to a cut. This page supplies the cut, and the selection is where the report states it. The second binding is not a second row beside the first: it is the object the first row was approximating, so the row retires and the cut carries both halves.

The chain, in the words the screens use. A report names a cut selection; the run resolves it to a cut; the cut holds the body; the body holds the deal population, the fixed snapshot with its publish records, the reference data and the engine. A result names one object at the head of that chain, and every input is reachable from it.

What the deal population becomes. Today the gathering step reads the trade store by valuation date and the run records the date it priced at. After this page, the gathering step reads the cut's deal population, which is a copy of what the store held at the cut instant and not a query re-run against it. The Trade cut page states why: the interval a versioned row states is rewritten when a correction arrives, so two executions of the same query at different moments can return different bodies. The cut's population is a fact of the cut, and a rerun replays it.

14. What this page does not settle

The entity. No cut component exists and no table holds one, and the report definition holds no selection. This page settles what a cut must record, which states follow, who may act, what a report selects and how a run resolves it; it does not design the columns, the generated types or the subjects. That is the next work, and it starts from this page and from Cuts.

Where the kind lives. The kind is the reporting component's today, because reporting resolves a selection and draws the cuts. A cut component would own the kind beside the cut records, and moving it then is a move of one lookup and its subjects. The page takes the smaller step and names the larger one.

The end of day family's fallback. An end of day selection accepts the month end or year end cut of its date, because the body is the same one and a report of the close must price from it. The alternative — an end of day selection refusing a month end body — would leave every report of a month's last business day with no body unless it selected the month end kind, which no report of the close should have to know. The prototype draws the fallback and the month end selection's stricter rule beside it.

The retention periods. The numbers in this page are ours and no public source we verified fixes a firm's retention. A firm sets them from its own regulatory position, and the kind is where it sets them. Whether a cut may be retained shorter than its kind by a person with a stronger permission is open; this page treats retention as a floor.

Which kinds the firm seeds. The link is settled — a type names its approval kind — and what remains is how many kinds a firm seeds. Two are enough here, one decided by Finance and one by Market Risk. A firm may seed more, one per desk or one per occasion, and seed a type against whichever it means. A type whose approval kind is retired cannot be taken until it names another, which is the one consequence of the link a person has to manage.

The apply. The decision is applied by reconciliation, as a role grant is. The alternative is an apply workflow, which the inbox already offers a kind through apply_workflow_type and which buys a visible run and a retry where this page buys one idempotent row.

The scope of a cut. The convention taken here is that a cut's scope is the set of books that revalue against one centre's market data. The hub's narrower convention, one cut per book, is the smallest such scope and not the only one. Whether a group report prices from one cut of the group or from a composition of its books' cuts is open, and a report whose books span two centres is refused rather than composed.

The resolution of a selection the party took no cut for. A report may select EOD and find no EOD cut of its date, because nobody took one. The run is refused and says which cut it looked for. Whether the report should also draw a warning before the run — and whether a scheduled run should raise a request for somebody to take the cut — is open, and belongs with the schedule's journey.

A LIVE cut's volume. One LIVE cut per run accumulates fast, and the cuts list must stay readable: the kind filter, the date order and the scope are what carry it. Whether LIVE cuts are archived after a period is open.

The reference data half, by version or by value. The part holds the versions of the conventions, the calendars, the settings and the curve configurations the run reads. Whether the cut stores those versions or the identifiers of the documents is open, and a LIVE cut makes the question sharper, because the versions in force move between runs.

Which occasions need no authorisation. The classification gives the start of day, flash and LIVE kinds, and the fixtures draw them. Whether a process-named instant needs one is the process owner's answer, and the kind declares it rather than the design assuming it.

Who takes a cut where a party has one person. The four-eyes rule makes an authorisation impossible, and this page leaves that as a refusal to draw rather than a rule to bend. A kind that requires no authorisation sidesteps it, which is a fact about the occasion and not a route past the rule.

The relation to the run's settings. A cut holds the settings in force. Whether the cut names the engine run settings configuration and its version, or the individual settings, is open, and it belongs to Pricing Configuration rather than to this page.

15. What the sources establish

No claim on this page rests on a public source. The definitions of the states, the kind's declarations, the permissions, the selection and its resolution, the LIVE kind, the derivation of the label and the retirement of the binding row are ours, and the pages they rest on are cited above. The rules of the authorisation are not ours: they are the inbox's, stated on Approval requests and enforced by its schema. The Cuts note records which claims of the cluster do rest on a public source, and this page adds none to that list.

16. See also

Emacs 29.3 (Org mode 9.6.15)