Sign off a pricing engine change prototype

"I must decide if this change to the way we price is safe, and I must leave a record that I decided." Each approval part reads the same change, the same reach and the same evidence, and decides for its own part.

• ?screen=queue and ?screen=proposal&id=pr1|pr2|pr3&tab=signoff|changes|reach|history. pr1 is a proposal for version 5 of EOD pricing. pr2 is a proposal for Intraday pricing. pr3 is an earlier proposal that was made official.
• ?proposal=pending|partly|ready|rejected|superseded sets the state of pr1: no approval, one of three, all three, rejected by market risk, or out of date because another version was approved first.
• ?actor=proposer|quant|risk|validator|viewer sets the person. The proposer holds the Market Risk part, so the refusal is reachable: the row shows no button and says another person who holds the part must sign it off. A viewer sees no button. When no part has approved, only Quant can answer, and the other two rows say Waits for Quant.
• ?state=all|empty|error for the queue.
• Approve asks the signer to confirm that they read the changes and the reach. Reject needs a reason. Making a proposal official names the reports it reaches. A rebase moves an out-of-date proposal onto the version in force and clears the approvals. A withdrawal closes an open proposal.

• Four eyes. The proposer cannot sign off, and one person approves a request once. The inbox already enforces both: a trigger refuses the requester's decision, and a unique index refuses a second approval from one person. The screen draws the refusals.
• The version in force stays in force. Every state of a proposal says so, and the Reach tab says that a run made after the change is not comparable with an earlier run for the changed products.
• The parts come from the inbox. Market Risk is a seeded approval part (market_risk). Quant and Model Validation are new parts, and their names are assumed. Quant answers first (answer order 1), and the other two answer together (order 2). A refusal from a part that can answer ends the request. Each part is decided by a permission such as inbox::approvals:decide_quant, and a tenant grants it to whichever role does that work.
• The proposal is an approval request. Its kind would be analytics.pricing_engines_change. That kind, the two new parts and a policy row for a put of pricing_model_config do not exist yet.
• A refusal needs a reason and deletes nothing. The proposal stays in the history.

Every value. The inbox holds requests, decisions, parts and the four-eyes rules, but no pricing engines kind, no Quant or Model Validation part and no policy row exist, and no pricing engines operation holds a proposed version or a status. The evidence files are names. The reports, their portfolios and their product types are fixtures. The names of the two new parts and the answer order are the page's assumption.

doc/prototypes/reporting/sign-off-a-pricing-engine-change/index.html. One file, plain HTML, CSS and JavaScript, with the style and the script inline, no modules, no fetch and no build step.

• The History tab draws the shared timeline as the Entity screen specification draws it: an event chart split by kind, a rail grouped by day with the time in the left gutter, one header line for each entry, the note on its own line, a collapsed detail, the current-version emblem and the Hide system activity toggle. The prototype does not draw batches of entries that are one act, and the toggle is always on, because the fixture has no reader without the account permission.
• A change to an official configuration is a proposal, and the sign-off is its own screen, because the control is the screen's job.
• The person who proposes cannot sign off, and the page draws the refusal as a state that a reader can reach.
• A proposal that every approval part approved is not yet in force. Someone makes it official, and the page names what that reaches.
• A proposal that sits on an old version must be rebased, and the approvals do not carry over.

None yet. This page is on the branch that proposes it and waits for review.

• The approval parts, their names and their answer order. Model risk decides.
• Whether an approved proposal applies at once through an apply workflow, as the book change does inside its apply window, or waits for a person to make it official, as the page draws it.
• How the page draws a hold, a resume, an expiry and a reversal. The inbox has all four decisions. The page draws approve, refuse and withdraw.
• Whether making a proposal official needs a permission of its own, or an effective date other than the next run.
• Whether a candidate that replaces the official configuration is the same flow. It also rebinds the reports of a cycle, and the page does not draw that step.