Task: Analyse the credit family and propose its relational data model

Survey every credit surface and propose the relational entity-relationship model that reworks the family to the instrument table rule of the trade shape investigation section 14, following the bond pilot and the rates rework.

• Every credit-related type and subtype is inventoried across the modeling orgs, SQL, domain C++, mappers, repositories, services, messaging and the ores.ore mapping.
• The current model's divergences from the instrument table rule are recorded as findings, each with its evidence, including the risk participation agreement's required elements, which the export omits.
• The proposed entity-relationship model is recorded as a diagram and table set: family header, product facts, shared children and securities.
• The ORE binding's bare float members that the credit corpus uses are listed, so the digits work is planned.
• The rework is staged into verifiable units; no code changes land on this task.

1. Survey. Read the credit model, the generated surface, the ORE mapper, the binding's credit structs, the catalogue and the corpus documents.
2. Findings. Record each divergence from the instrument table rule with its evidence.
3. The model. Propose the header, the product facts and the shared children in a table set and a diagram.
4. Staging. Order the rework into units that each end in a check.

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

• The design is design.org beside this page, with design_er.puml and the rendered design_er.png.
• The operator asked that the key principles of the work be remembered and that a checklist be written from the bond and rates work. Three memories record the principles (data-oriented design, the hot and cold split, exact decimals), and the runbook rework_an_instrument_family holds the checklist.
• The rates repair already routed RiskParticipationAgreement to the credit table. What is left of the agreement's problem is its required elements, its underlying and the retired rpa_instruments table.

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

The credit family is surveyed and the rework is designed. The family is eight trade type codes in one 25-column table, and six of the eight have an importer. The design finds fourteen divergences from the instrument table rule, among them six columns no mapper writes, two importer-less codes, an exported risk participation agreement that is not valid ORE, and money values stored as float artifacts.

The proposal is a six-code header with the reference entity and the two dates, six product fact tables keyed by the trade, the swap leg tables reused with a leg_group column, the shared option and strike children reused, and one new basket child. The rework is staged into eight units, from the digits to the proof over the eight corpus documents.

Acceptance met: every credit type is inventoried, the divergences are findings with evidence, the model is a table set and a diagram, the bare float members the credit corpus uses are listed, and the rework is staged with no code change.