docs: architectural amendments for RFC-0104 v1.17 and RFC-0105 v2.14

Address deferred issues and architectural findings from code reviews:

RFC-0104 v1.17 amendments:
- A1: Unified runtime dispatch (type-specific opcodes reserved for future)
- A2: Cross-type comparison via type promotion, not lossy f64
- A3: Division iterations 128 (was 256), update Golden Rule #3
- A4: Generic Op::Sqrt opcode for DFP sqrt
- A5: Single casting truth (perform_cast delegates to cast_to_type)
- A6: DETERMINISTIC VIEW deferred to separate RFC-0110
- A7: Minimum verification requirements

RFC-0105 v2.14 amendments:
- B1: Unified runtime dispatch (DQA opcodes reserved, never emitted)
- B2: Cross-type numeric comparison via type promotion table
- B3: Single casting truth (three paths → one implementation)
- B4: Validation on DQA extraction (Dqa::new instead of direct construction)
- B5: Persistence payload validation (DFP 24 bytes, DQA 16 bytes)
- B6: Display and string representation (format_dqa/parse_string_to_dqa)
- B7: Verification requirements table

Author: mmacedoeu

rfcs/accepted/numeric/0104-deterministic-floating-point.md

@@ -368,8 +368,10 @@ DFP_DIV(a, b):
     // Quotient accumulator
     quotient = 0u128
 
-    // Fixed 256 iterations for determinism
-    for i in 0..256:
+    // Fixed 128 iterations for determinism (sufficient with pre-scaling guarantee)
+    // Pre-scaling ensures a.mantissa < b.mantissa, so 128 bits of quotient precision
+    // yields 15 guard bits above the 113 we keep — sufficient for correct RNE rounding.
+    for i in 0..128:
         // Shift dividend left by 1 (with carry between hi/lo)
         (dividend_hi, dividend_lo, carry) = shift_left_with_carry(
             dividend_hi, dividend_lo
@@ -388,7 +390,7 @@ DFP_DIV(a, b):
             quotient = quotient | 1
         // Else: quotient bit remains 0, dividend unchanged
 
-    // quotient now has 256-bit precision
+    // quotient now has 128-bit precision
     // CRITICAL: Align quotient for round_to_113
     // Find MSB position in 256-bit quotient (0-255)
     quotient_msb = 255 - quotient.leading_zeros()
@@ -1468,7 +1470,7 @@ Recommended CI matrix: x86_64-linux, arm64-linux, macOS, wasm
 
 2. **No f64 for SQRT Seed:** The initial approximation for SQRT must use bit-by-bit integer sqrt. Using `f64::sqrt(x)` as a seed is FORBIDDEN — it introduces non-determinism.
 
-3. **No Iteration Short-Circuiting:** Execute ALL iterations as specified (256 for division, 226 for SQRT). Compilers must NOT elide "useless" iterations via "fast-math" flags.
+3. **No Iteration Short-Circuiting:** Execute ALL iterations as specified (128 for division, 226 for SQRT). Compilers must NOT elide "useless" iterations via "fast-math" flags.
 
 ### Mission 1b: Additional Transcendental Functions (Future Phase)
 
@@ -1811,7 +1813,97 @@ None. DFP is a new type that does not modify existing FLOAT/DOUBLE behavior.
 
 ---
 
-**Version:** 1.16
+## Appendix: Implementation Architecture Amendment (v1.17)
+
+> **Date:** 2026-04-01
+> **Status:** Accepted amendment based on code review findings
+
+### A1. Unified Runtime Dispatch (Resolves: S11, S12)
+
+The original RFC specified type-specific DFP opcodes (`OP_DFP_ADD/SUB/MUL/DIV`). After implementation review, the architecture uses **unified runtime dispatch** as the primary path:
+
+- All generic `Op::Add/Sub/Mul/Div/Mod/Neg/Abs` route through a single `arithmetic_op()` method
+- `arithmetic_op()` performs runtime type detection (one byte comparison per operand)
+- Type-specific opcodes (`OP_DFP_ADD`, etc.) are **reserved for future JIT optimization** but not emitted by the current compiler
+
+**Rationale:** Runtime detection cost (one `match` on a byte) is negligible vs disk I/O in a database VM. The DQA review proved that type-specific opcodes (7 defined for DQA) become dead code when the compiler doesn't emit them.
+
+**Compiler requirement:** The expression compiler MUST ensure all generic arithmetic opcodes route through the type-aware `arithmetic_op()` dispatch. Any new arithmetic opcode added to `Op` must include Extension type handling.
+
+### A2. Cross-Type Numeric Comparison (Resolves: S7, F1)
+
+**Previous behavior:** Cross-type comparison (DFP vs Integer/Float) used `as_float64().unwrap()`, which:
+1. Panicked for Extension types (server crash)
+2. Lost DFP's 113-bit precision via lossy f64 conversion
+
+**New behavior:** Cross-type comparison uses **type promotion** instead of lossy conversion:
+
+| Left Type | Right Type | Comparison Strategy |
+|-----------|------------|---------------------|
+| DFP | Integer | Promote Integer → DFP, compare in DFP space |
+| DFP | Float | Promote Float → DFP, compare in DFP space |
+| DFP | DFP | Same-type `compare_dfp()` |
+| DFP | Quant | `Error::IncomparableTypes` (explicit CAST required) |
+
+**Implementation:** `as_float64()` still supports DFP for backward compatibility but the `compare()` method uses dedicated promotion paths that avoid precision loss.
+
+### A3. Division Iterations: 128 (Resolves: D1)
+
+The implementation uses **128 iterations** (not 256) for the long division loop. This is mathematically sufficient:
+
+- Pre-scaling guarantees `a.mantissa < b.mantissa`
+- 128 iterations yield 128 bits of quotient precision
+- 15 guard bits above the 113 kept — sufficient for correct RNE rounding
+- Golden Rule #3 updated: 128 for division (was 256)
+
+### A4. DFP SQRT Opcode (Resolves: S5)
+
+Add `Op::Sqrt` as a generic opcode (not DFP-specific):
+
+```
+Op::Sqrt => {
+    let v = self.stack.pop().unwrap_or_else(Value::null_unknown);
+    let result = match v {
+        Value::Integer(_) => Value::Null(DataType::Integer),  // sqrt not defined for integers
+        Value::Float(f) => Value::Float(f.sqrt()),
+        Value::Extension(data) if data.first() == Some(&(DataType::DeterministicFloat as u8)) => {
+            // DFP sqrt via dfp_sqrt()
+            ...
+        }
+        _ => Value::Null(DataType::Null),
+    };
+    self.stack.push(result);
+}
+```
+
+### A5. Single Casting Truth (Resolves: F3)
+
+Three code paths previously implemented independent type coercion:
+1. `Value::cast_to_type(&self, target)` — borrowing
+2. `Value::into_coerce_to_type(self, target)` — consuming
+3. `CastExpr::perform_cast(&self, value)` — storage expression
+
+**Requirement:** `perform_cast()` MUST delegate to `Value::cast_to_type()`. `into_coerce_to_type()` MUST use `cast_to_type()` internally, only inlining the same-type fast-path (no conversion needed, return self).
+
+### A6. DETERMINISTIC VIEW (Resolves: S10)
+
+Deferred to a separate RFC-0110. The VM's `deterministic` flag and `arithmetic_op_deterministic()` method are reserved infrastructure. The SQL surface (`CREATE DETERMINISTIC VIEW`) requires parser grammar changes beyond the scope of this amendment.
+
+### A7. Verification Requirements
+
+DFP integration MUST include:
+
+| Category | Tests Required | Coverage |
+|----------|---------------|----------|
+| Value API | Round-trip, Display, as_string, as_float64, coercion | Per type conversion |
+| VM Arithmetic | add/sub/mul/div/mod/neg/abs/cmp | Per opcode × per type |
+| Cross-type comparison | DFP vs Int, DFP vs Float | Per combination |
+| SQL round-trip | CREATE → INSERT → SELECT → WHERE → UPDATE → DELETE | End-to-end |
+| Persistence | Serialization → deserialization fidelity | Per wire format |
+
+---
+
+**Version:** 1.17
 **Submission Date:** 2025-03-06
 **Last Updated:** 2026-03-08
 **Changes:** v1.16 final fixes (10/10):

rfcs/accepted/numeric/0105-deterministic-quant-arithmetic.md

@@ -1178,8 +1178,95 @@ This invariant ensures:
 
 ---
 
+## Appendix: Implementation Architecture Amendment (v2.14)
+
+> **Date:** 2026-04-01
+> **Status:** Accepted amendment based on code review findings
+
+### B1. Unified Runtime Dispatch (Resolves: S8)
+
+The original RFC specified 7 type-specific DQA opcodes (`OP_DQA_ADD/SUB/MUL/DIV/NEG/ABS/CMP`). After implementation review, the architecture uses **unified runtime dispatch** as the primary path:
+
+- All generic `Op::Add/Sub/Mul/Div/Mod/Neg/Abs` route through a single `arithmetic_op()` method
+- `arithmetic_op()` performs runtime type detection via `is_quant_value()` / `is_dfp()` byte checks
+- DQA-specific opcodes (`Op::DqaAdd`, etc.) are **reserved for future JIT optimization** — dispatched correctly in the VM main loop but never emitted by the current compiler
+
+**Rationale:** The 7 DQA opcodes are fully implemented and tested but the compiler emits only generic opcodes. Making the compiler type-aware would require schema inspection during compilation — a significant architectural change deferred to a future optimization pass.
+
+**Compiler requirement:** The expression compiler MUST ensure all generic arithmetic opcodes route through `arithmetic_op()`. Any bypass (like the old `div_op()`/`mod_op()` static methods) risks silently returning NULL for Extension types.
+
+### B2. Cross-Type Numeric Comparison (Resolves: S1, S10)
+
+**Previous behavior:** Cross-type comparison used `as_float64().unwrap()`, which:
+1. Returned `None` for all Extension types (including Quant), causing server panics
+2. For DQA: `(q.value as f64) / 10^q.scale` overflows f64 for large values with high scale
+
+**New behavior:** Cross-type comparison uses type promotion:
+
+| Left Type | Right Type | Comparison Strategy |
+|-----------|------------|---------------------|
+| Quant | Integer | Promote Integer → Quant(scale=0), compare via `dqa_cmp` |
+| Quant | Float | Convert Quant → f64 (lossy but explicit), compare as f64 |
+| Quant | DFP | `Error::IncomparableTypes` (explicit CAST required) |
+| Quant | Quant | Same-type `dqa_cmp` after canonicalization |
+
+**Warning:** Quant → f64 conversion for comparison is lossy for values exceeding f64 integer precision (2^53) at high scales. A query like `WHERE quant_col > 9007199254740993` may produce incorrect results for values near the precision boundary. This is documented as a known limitation — use `CAST(float_col AS DQA)` for exact comparison.
+
+### B3. Single Casting Truth (Resolves: S2, S3, S4, S7)
+
+Three code paths previously implemented independent type coercion for Quant:
+1. `Value::cast_to_type()` — borrowing, was a stub returning NULL
+2. `Value::into_coerce_to_type()` — consuming, was a stub returning NULL
+3. `CastExpr::perform_cast()` — was returning Error
+
+**Requirement:** All three paths delegate to a single implementation in `Value::cast_to_type()`:
+- `into_coerce_to_type()` calls `cast_to_type()` internally, inlining only the same-type fast-path
+- `perform_cast()` delegates to `Value::cast_to_type()` via `Ok(value.cast_to_type(target))`
+
+### B4. Validation on Extraction (Resolves: S9)
+
+`extract_dqa_from_extension()` previously used `Some(Dqa { value, scale })` (direct construction), bypassing `Dqa::new()` validation. A corrupted payload with `scale > 18` would be accepted.
+
+**Requirement:** All DQA extraction from byte data MUST use `Dqa::new(value, scale).ok()` or equivalent validation. Direct `Dqa { value, scale }` construction is only permitted in `Dqa::new()` itself and in the `CANONICAL_ZERO` constant.
+
+### B5. Persistence Validation (Resolves: S13)
+
+Wire tag 11 (generic extension) deserialization now validates DQA payloads:
+
+```
+if dt == DataType::Quant && len != 16:
+    return Err(Error::internal("corrupted DQA extension: expected 16 bytes, got {len}"));
+```
+
+DFP payloads are also validated (expected 24 bytes for `DfpEncoding`).
+
+### B6. Display and String Representation (Resolves: S5, S10)
+
+Quant values display as their decimal representation:
+- `Dqa { value: 123, scale: 2 }` → `"1.23"`
+- `Dqa { value: 42, scale: 0 }` → `"42"`
+- `Dqa { value: -100, scale: 2 }` → `"-1"`
+
+The `format_dqa()` and `parse_string_to_dqa()` helpers handle the bidirectional conversion.
+
+### B7. Verification Requirements
+
+DQA integration MUST include:
+
+| Category | Tests Required | Coverage |
+|----------|---------------|----------|
+| Value API | Round-trip, Display, as_string, as_float64, coercion | Per type conversion |
+| VM Arithmetic | add/sub/mul/div/mod (via arithmetic_op_quant) | Per operation |
+| Cross-type comparison | Quant vs Int, Quant vs Float | Per combination |
+| Format/parse | format_dqa ↔ parse_string_to_dqa round-trip | Scale 0, 1, 2, 9, 18 |
+| SQL round-trip | CREATE → INSERT → SELECT → WHERE | End-to-end |
+| Persistence | Serialization → deserialization with validation | Corrupted payloads rejected |
+
+---
+
 **Submission Date:** 2025-03-06
-**Last Updated:** 2026-03-08
+**Last Updated:** 2026-04-01
+**Revision:** v2.14 - Architecture amendment: unified runtime dispatch, cross-type comparison, single casting truth, validation on extraction, persistence validation, display/string representation, verification requirements
 **Revision:** v2.13 - Tightened MUL clamping wording, added large-value chain test, added >90% note to DQA_CMP fast-path
 **Revision:** v2.12 - Added SQL vs canonical representation clarification, fixed division rounding wording (TARGET_SCALE precision), strengthened SIMD determinism rule, enforced canonicalization in encoding API, added control-flow to VM canonicalization rule, added power<=36 invariant, added scale alignment overflow test vector
 **Revision:** v2.11 - Fixed DIV negative test vector (-12 not -13), added i64 range check to DQA_ASSIGN_TO_COLUMN, added CANONICALIZE to DIV return, unified scale overflow references, fixed test vector notes, added DIV canonicalization test vector, fixed MAX_I128_DIGITS to 39