Task: Turn the FX soft references into foreign keys

Give the FX family the keys its models promise. The seven tables declare no foreign key, and twenty columns are labelled as a soft reference to a named table, each deferring the real key to "PR 4". The identity-by-key check asks for a key, not a text code that only a non-empty check defends.

• Every one of the twenty soft references is either a real foreign key or carries a recorded reason that it stays soft.
• A reference that becomes a key keeps its existing rows: the unit states how the existing codes map to keys, and no row is lost.
• The closed vocabularies keep one home. A column that becomes a key to a type table must not also restate the closed set in its own check.
• The trade anchor keeps its trigger-enforced key, or gains a declared one.

1. List the twenty references with their target table and the code values in the corpus.
2. Split them: the closed trading vocabularies become keys; a currency code becomes a key to ores_refdata_currencies_tbl; an FX index code has no target table yet and stays soft with a reason.
3. Add the keys in the models, regenerate, and recreate the database.
4. Import the corpus again and compare the stored rows with the document.

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 evidence for this task is Investigation: FX family data model review, finding 5. Measured there: 0 declared foreign keys and 20 soft-reference claims across the seven models.
• fx_index and underlying_code name an FX index that no ores.refdata entity holds. If that entity is not scaffolded in this unit, record the gap rather than inventing a key.

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.

Fourteen references became real keys and twenty-one stay soft with a recorded reason.

The fourteen are the family's closed vocabularies: long_short on the accumulator, the Asian forward, the digital option and the variance swap; option_type on the barrier, digital and vanilla options; barrier_type on the barrier and digital options; exercise_style on the vanilla option; moment_type on the variance swap; and settlement on the forward, vanilla and barrier options, whose lookup holds the two methods the documents state. Each now carries a foreign key block to its lookup table, so the generated insert trigger refuses a code the lookup does not hold. The nullable columns validate only when they state a value.

Twenty-one references stay soft, in two groups:

• The currency columns, fourteen of them. A currency is ores.refdata's row, published from the data-quality pipeline per environment rather than by this component, and a trading database may hold only the codes its own imports loaded. A freshly recreated database holds no EUR and no USD in any tenant, while the FX rows state them, so a trigger check would refuse the documents the store is meant to accept. Each of the fourteen columns states that reason.
• The seven trade-type codes. The column's check lists exactly the codes the trade-type catalogue routes to that table, and the catalogue is what decides the routing, so a foreign key would duplicate the router.

The other text columns name no table: underlying_code and fx_index name an ORE Underlying/Name that no ores.refdata entity holds, and description is free text.

• A key is the trigger check, not a SQL constraint. The tables are temporal, so a REFERENCES constraint would accept a closed version as current. The generated check reads the current row, which is what the rest of the family already does for its trade and activity keys.
• A currency reference stays soft because its rows are not this component's. The unit's acceptance allows a recorded reason, and the alternative would be a foreign key that fails in every database whose currency set is loaded after the documents.
• The trade-type code stays soft because the check is narrower. It lists the codes the routing sends to the table, where a key would accept any catalogue code. The trade envelope keys its own trade_type to the same lookup without a check, so the two tables state the same set differently; the discriminators unit decides which one wins.
• The lookup's closed set is now stated twice. The SQL check and the lookup table both hold it. Removing the checks is the discriminators unit's decision, not this one's, so they stay.
• A barrier type is not a closed ORE enumeration. ORE states the leaf as free text, so the lookup is the set this store accepts, not a schema set. Every barrier value in the repository falls inside it.