See the engine run settings a party holds prototype

"Which settings does the engine run my reports with, and which reports share them?" The list finds the configuration. The page shows one group on each tab, and the Used by tab shows who is reached by a change.

The prototype describes a setting only when the ORE user guide describes it, and it holds every documented engine setting. A setting that appears in the sample files or in the source, and not in the guide, is left out. Where the guide and the source disagree, the source wins, so the defaults on the screen are the source's.

Eleven of the 19 settings that the model stores today are in the guide. The other eight are not: accrualDate, fixingCutoff, dateCalendar, dateConvention, defaultMappingToIdentity, useAnalytics, csvCommentReportHeader and additionalResults as a Setup parameter. Four documented settings are new: useAtParCouponsCurves, useAtParCouponsTrades, ignoreFixingLead and gzipCompressionLevel.

The 15 settings fall into three groups. Fixings and cash flows holds six. Market and trade building holds six. Execution holds three. The groups Dates and Report output of the earlier design hold no documented setting, so they are gone.

A person uses the page in two ways, and the page serves both.

Reading. The group tab lists each setting with its value. A setting that is not set shows the default that the engine uses, such as "Default: Yes", so the value in force is always visible. The documentation is collapsed under each setting. A button on the card opens or closes all of it.

Changing. Edit turns the card into a form in place. There is no dialog, so nothing hides the documentation. Each setting becomes a control, and its first option is "Default (Yes)", which unsets it. Focusing a control opens the documentation of its setting. A setting that differs from the saved value is marked, with a count of the changes at the foot of the card. The foot says how many reports the section reaches. A section that changes the numbers, on a configuration a report binds, offers Propose a change: Save submits a proposal for the next version, the version in force stays in force until the sign-off completes, and the person who proposed it cannot sign it off. An operational section offers Edit and writes directly with a reason and a history entry. A configuration no report binds writes directly in every section. Cancel leaves the card as it was.

Each tab holds one section, as one card. The card says whether the section changes the numbers a run computes or is operational, and shows its own version. A numbers-changing section on a bound configuration shows a pending proposal as a banner. A setting that changes the numbers carries a label for it. A group with no row shows "not set", and the engine uses its default for every setting in it.

The switch is the one the feed screens use, and the choice is remembered for every screen that offers it. Simple shows the setting and its documentation. Advanced adds the documentation entry inside the expanded documentation: the ORE XML location, the release that introduced the setting, the release that removed it, and the format. The release that removed a setting is empty for a setting that ORE still reads.

The documentation of a setting is data of its own, apart from the settings. It is documentation only. The type, the range and the validation of a value stay with the data model. The screens look an entry up by the name of the setting. An entry relates to the ORE file it belongs to, such as ore.xml.

The entries hold no table of values. A value that the model already knows as an entity, such as a calendar or a business day convention, is bound to that entity by the control, and the description gives examples. A closed list of values that belongs to one setting, such as the observation model, is explained in the description, and the control offers the list. Where the list needs an entity of its own is a question for the data model.

The same entry shape serves every ORE document. The conventions, the pricing engines, today's market, the curve configuration and the analytics all have named elements and parameters that need the same facts. This prototype draws the Setup block only.

The prototype shows no engine build and no warning about one. A report does not state the ORE build it runs on. The compute submit handler picks the build with the highest engine version at the time of submission. A warning that a setting is newer than the build needs a build that the data model holds, so it waits for the data model. The Introduced in and Removed in entries are the whole of the version documentation.

The History tab is the shared timeline. A change to a section is one entry that names the section and its part version. The entry also moves the version of the whole configuration, because a write to any part makes the next version of the central row. A proposal that waits shows at the top and is not a version in force. Revert is offered on every entry that is not current and writes the values the section had before as a new version; on a numbers-changing section the revert is a proposal.

• ?screen=list and ?screen=record&id=e1|e2|e3&tab=details|fixings|building|execution|reports|history. e1 is the standard settings that twenty HK reports share. e2 has four threads and serves two reports. e3 is a trial that no report binds.
• ?state=all|empty|error|loading for the four list states.
• ?actor=viewer|analyst|admin. A viewer reads, an analyst adds and edits, and only the administrator deletes.
• ?mode=simple|advanced sets the switch. ?clean=1 hides the prototype furniture. ?edit=fixings|building|execution opens that group in edit mode.
• Delete is refused while a report binds the configuration.

The report names are the real names of ACME Corporation HK Ltd, and the five values the standard settings set are the ones the seed writes today. The third configuration, every history entry and every count in the list are fixtures. No operation lists the reports bound to one configuration, and no operation returns a group count for a list row.

• The import warning. The importer drops a Setup parameter that the model does not hold, such as fixingCutoff, and warns, naming it, that the numbers may differ from the original run.
• The Add, Revert and Delete dialogs keep the standard form, and the engine settings page is the only place that edits in place.

• The wording of the documentation is drawn from the ORE user guide, with the release numbers measured from the ORE source. A reviewer who knows ORE should read the descriptions.
• Where the target ORE build lives in the data model, so that the screen can warn about a setting the build does not read.
• The approval parts of a numbers-changing section. The prototype lets an analyst propose and names no parts. Model risk confirms them.
• The flags are drawn as Yes and No. ORE accepts every spelling, so the model can store booleans. Whether the projection writes true or Y is still open in the story.
• Whether the list should show the groups that are set, or only the count.