Story: Name the convention sets a report chooses

Conventions become named convention sets. A set carries a name, a purpose and a description, and a system holds few of them, so a person reads a short list and knows what each one is for. A report binds one set by choosing it. Authoring a set is a separate UX and is addressed outside this story. This story records the gaps that today stop the list from being drawn from the schema, and points at the two report prototypes that show the choosing surface.

• A convention set has a name, a purpose and a description, and the three are stored, not derived.
• A system holds few convention sets: few enough that one page lists them all, and each one is clearly named and clearly purposed.
• A report binds one set by choosing it, and the set it binds is stated on the report and on the configuration it binds.
• The choosing surface is one page: a row per set carrying its name, its purpose, the number of kinds it covers, and whether it is the set this report uses.
• A person who finds no set that fits follows one link from that page to the authoring UX. Authoring a set is not part of the report flow.
• The publish carries a correction to a tenant that already holds the row for all 26 kinds.
• The conventions configuration a report binds carries its kinds as children, and a run reads the document those children name.

The choosing surface this story asks for is drawn in two report prototypes, and those two pages are the answer to the story:

• Create a report — doc/prototypes/reporting/create-a-report/. Step 2, The conventions it binds, lists the named sets, states the purpose and the kinds each one covers, marks the one this report uses, and offers the choice as a radio.
• Change what a report runs — doc/prototypes/reporting/change-what-a-report-runs/. Step 1 carries the same list for the report being changed, with the same choice and the same link out.

Both pages draw one fixture list and say so. The authoring prototype is not in this story. Authoring a set has its own journey and prototype: Name a convention set, in the story Prototype the management of conventions. The link out from a report to the authoring UX is drawn and marked as not in this MR.

The story states a decision and the gaps that block it. It breaks into tasks once the set's columns and children are scoped.

• Conventions are named convention sets, not a per-kind table. A person chooses a set; a person does not assemble 26 kinds one at a time in a report.
• Authoring a set is a separate UX. The report offers two acts only: choose an existing set, or follow the link to the authoring UX.
• The report prototypes carry no per-kind table, no alternative per kind, no provenance card and no migration state. Those belong to authoring.

Each entry is a fact about the tree at 2026-10-17 and is why the prototypes draw fixtures.

• No name column and no purpose column. Nothing stores the name of a convention, let alone a purpose. The name a page shows today is derived from the terms of the document in use, and a purpose has no home at all. So the names and purposes in the prototypes are fixtures.
• No default marker. Every kind holds many documents (swap 320, commodity future 790) and no table records which one a run reads. The choice of a set can not yet say which document a kind resolves to.
• The configuration carries no children. ores_reporting_configurations_tbl carries a name, a configuration_type_code and an owning_component, and no rows beneath it. So a conventions configuration binds 26 kinds in name only: it names none of them.
• The publish has no update path for 25 of the 26 kinds. A re-publish inserts where the row is absent and does nothing where it is present, for 25 kinds. Only currency_pair updates, and its last publish updated 179 rows. A correction can therefore reach 1 kind of the 26 and no more.
• The tenant holds the facts that make the list honest. ACME holds 10,991 convention rows across the 26 kinds: 2,155 for the party and 216 held once for the tenant. 25 of the 26 kinds arrived from a data quality publish and tenor was copied from the system tenant.

• The authoring UX: the screen that creates a set, names it, states its purpose and description, and binds the kinds it covers. It is its own work, and it is deferred so that the report surface stays a choice.
• Per-kind migration inside the reporting group. The prototype that argued it is retired with this story, because it was built on a configuration binding that does not exist.
• Any change to the conventions database or to the seeders. This story records the decision and the gaps; the schema work is its own.