#197 assert_translation_rate_resolved accepts a cross-currency rate of exactly 1.0 (#194)

[Anonymous]

Originally created by: grynn-in

Fixes [#194]: assert_translation_rate_resolved failed a correct near-parity rate.

What was wrong

Check 3 of the test flagged any cross-currency row with translation_rate = 1.0, on the reasoning that "a genuine market rate between two distinct currencies is never exactly 1.000000" and that 1.0 meant the parity fallback had fired. Neither holds any more:

• The model has had no parity fallback since [#109]: a translated currency with no approved rate stops the build (throwIf(translation_rate is null, …) in gold_consolidated_trial_balance), so a cross-currency 1.0 can only be an approved rate.
• Approved rates are entered at the source's precision. Annual rates quoted to 3 decimals put near-parity pairs at exactly 1.000. On the stack the 2012 CAD→USD average was 1.0 (the Fed's figure is 0.9995 CAD per USD), and a full build failed on 40 rows.

The fix

Check 3 and its comment block are removed. Checks 1 (= 0) and 2 (is null) stay. The header explains the two remaining failure modes and why a 1.0 cross-currency rate is legitimate.

Evidence

• Test first, with committed fixtures under dbt_project/test_fixtures/:
• assert_translation_rate_resolved.sql (one CAD→USD row at 1.0): Got 1 result on main (fdb7760) → PASS with the fix (7434fa8).
• assert_translation_rate_resolved.must_flag.sql (one row at 0, one at NULL): Got 2 results before and after.
• Runs were in throwaway zzg_gold schemas inside the stack's ClickHouse, with the live table's DDL; live tables untouched. The fixtures folder and its README arrive with [#196]; this branch adds only the two fixtures.

🤖 Generated with Claude Code

https://claude.ai/code/session_013WewQKFQgG7o2M3mUDPRR5

[Anonymous]

Originally posted by: grynn-in

Review round 1: no findings. The reviewer confirmed the premise from the model (the only path to a 1.0 translation rate is the same-currency branch; a governed-rate join miss resolves to NULL and stops the build), and that a mistyped 1.0 for a pair like JPY/USD is already refused at build time by the governed_rate_guard pre_hook's implausible-magnitude check.

[Anonymous]

Ticket changed by: grynn-in

• status: open --> closed