Cuts prototypes
Table of Contents
1. Summary
A cut fixes a body of data at one timepoint so that a valuation can be reproduced. Three journeys describe the person's side of that — taking a cut, pricing a report from one, and rerunning and auditing one — and no cut exists in the application today: no component, no table, no read and no screen.
One prototype answers to the group. It draws every surface the three journeys name, and it settles what the design note cannot: what a body that could not be assembled looks like, what each state of a cut reads as on a screen, how a report comes to price from one cut, what the resolution says before a run, and what a run states about the body it priced from. There is no pricing surface, because there is none: a cut is selected where a report is defined.
The conventions the take reads — the named cut times — have no prototype of their own. They are two surfaces of the same page, because a person taking a cut reads a cut time and a person maintaining one changes it, and the two are never on screen at the same moment.
Prototypes is the top page and the only inventory.
2. One decision, and the surfaces it forces
The journeys are not a screen plan. Read one to one they would give a list, a record, a take flow, a picker, a run card and a reference list, which is what this page draws, but the grouping is what the decision note argues: a cut is a record with a derived state, an authorisation that is the inbox's, and a second binding that a run names.
The prototype therefore turns on two questions — what does a person need to see to trust a body they did not assemble? and how does a person know what a report will price from before they run it? — and every surface answers one of them: the counts of the parts, the gaps where a part stands open, the accounts of the acts, the runs that already rest on the body, the verdict on a reproduction, the badge on the report, and the preview that states what the selection resolves to now.
| Prototype | What it argues | Open it | Review |
|---|---|---|---|
| The cut | The screens a cut needs, in one page with eleven surfaces: the reports list with the cut badge, the report that carries the selection, the selection dialog with its resolution preview, and the run that resolved — then the cuts list with its type filter, the cut's record, the take flow, and two Reference data lookups — the cut types, whose record groups a type's cuts by the period above its frequency, and the named cut times. The list draws the seven states with the taker, the authoriser and the count of runs, and the default order is the timepoint so the cut in use is the first row. In use is the state of a body whose kind requires no authorisation, and the basis stands under each state that has one, apart from the indicative mark, which is the kind's and not the state's. The record draws the body as the four inputs the cluster argues for, a gap table where a part could not be filled, the acts — two where the kind requires an authorisation, with the four-eyes rule stated as a fact, and one where it does not, with the basis in its place — the runs that rest on the body, and a history of one entry or two because a taken body is immutable. The take is four steps on a rail, and the second step is where the body is refused: no Take the cut is drawn while a gap stands, and the draft keeps the gaps because the list is what a person chases. The report side draws the selection as a property of the definition, the resolution preview computed by the run's own operation, a report with no selection, one pinned to a cut, one whose selection resolves to nothing, and the LIVE report whose body exists only after a run — which the run's card states as a body it minted, marked indicative and reproducible only by naming its cut. The selection is the only market association: the market bindings retire, and the binding decision now records that. The run's page carries the card that names the cut, read from the run and never from the configuration, and below it a comparison in three verdicts — reproduced, differs, and cannot be compared, with its reason stated — and the outcomes one strip away. The named cut times are a standard list and a standard record in Reference data, and the take reads the close from them. | prototype | none |
3. What it settles
The prototype settles four things the decision note left to the screens.
The gaps are drawn where the body is. A body that cannot be assembled is kept, not thrown away, and its gaps are drawn as a table of part, item, why it stands and what closes it. The take offers a draft in place of a take, and the record reads the same table. The alternative — a take that fails with one message — was not drawn, because it loses the list a person acts on.
The state is drawn as two facts, not one. The badge carries the derived state, and a line under it carries the fact that qualifies it: which part a taken cut waits on, and when a superseded cut was replaced. A screen that drew only the badge would make a cut awaiting a signature look like one that holds none.
The refusals are one sentence in two places. The picker refuses a cut where it is picked, and the run refuses the same body in the same words before the engine is reached. The sentence names what the kind requires, so a body of a kind that requires no authorisation is never refused on that ground. Neither offers a way past a refusal except the remedy the state names: an authorisation, or a new take, or a change to the configuration.
A reproduction is a sentence before it is a number. The comparison states what was reproduced and what the two runs shared — the body and the engine — before it shows a figure. That ordering is what makes the third verdict usable: an auditor writes the reason down, and the figures are what follow from it.
4. What none of them settle
Whether the gap table becomes a shared part of the standard, or stays the take's own. Whether the comparison reads a run's archive into figures, or the run records its figures as rows when it completes. Whether the cut's scope is one book group, as drawn, or a composition of the cuts of its books. Whether one inbox kind serves every occasion that needs a signature, as drawn, or each occasion registers its own. And whether the selection earns its own step on the create flow, or stays a field on the step that names the report.
5. Adding a prototype
Follow Prototypes, which has the one way. A prototype here
is a static page, never a route in ores.web, and it carries a design note at
doc/prototypes/cuts/<name>.org that this page links.
6. See also
- Prototypes — every prototype, grouped by journey.
- Cuts journeys — the journeys these answer to.
- The cut is the body a run prices from — the decision the prototype draws.
- Market bindings prototype — the picker and the card this prototype continues.