Finding 003: PDOC CPP in binary64, and two-credit rounding

Who this is for: Engineers reconciling Takehome against live PDOC, and reviewers checking why the M-003 one-cent disagreements closed.

When you finish: You know the three rules that close 149 of the 164 July 2026 one-cent disagreements, the evidence for each, and what is still open.

Record: M-004 (new) and M-003 (residual) in CONFORMANCE.md. Status: closed for 149 of 164 forms; 15 remain open and count in both rates. Date: 2026-10-22.

Summary

Rule	Arm	Forms it closes
1. K2 and K2P are two credits (CPP and EI), each rounded to the cent	default (`t4127`)	rules 1 and 2 together: 67 tax-line forms
2. Ontario V1 is two surtax lines (20% and 36%), each rounded	default (`t4127`)	three of those 67 are Ontario forms that need rule 2
3. PDOC's period CPP line C matches IEEE-754 binary64 (inferred from its outputs)	`rounding_compat: pdoc` (ADR-007)	82 forms: 81 CPP-only, one where the provincial line follows through K2P

Measured with cargo run -p takehome-conformance (the grid outputs are in tools/conformance/src/grid_pdoc_outputs_2026.csv):

	Before (2026-09-20)	After, default	After, `rounding_compat: pdoc`
July grid, 8,982 compared forms	8,818	8,885	8,967
Ontario January, 20 forms	20	20	20
Overall Option 1 rate	8838/9002	8905/9002	8987/9002
PDOC bonus class (own class, not in the rate)	7/20	19/20	19/20

Rule 1: K2 is two credits

T4127 (Payroll Deductions Formulas) does not say where to round inside K2. It writes the federal CPP and EI credit as

K2 = [(0.14 x (P x C x (0.0495/0.0595), maximum 3,519.45)) + (0.14 x (P x EI, maximum 1,123.07))]

That is two products added together. They are also two separate lines on the T1 return (CPP contributions and EI premiums). PDOC rounds each product to the cent before adding them. The engine rounded the sum once. The difference is at most one cent of annual credit, which moves a period tax line only when the period quotient T/P sits near a half-cent. That is why the old record saw "neighbour" forms one cent of gross apart that agreed: the tail was upstream of the period rounding, exactly as finding 002 suspected.

The same structure applies to K2P (lowest provincial rate), the bonus K2 and the Option 2 K2. All now round each credit separately. The CRA's own Chapter 4 bonus worked example (K2 = 491.63) is reproduced either way and stays a golden test.

Rule 2: Ontario V1 is two surtax lines

V1 = (0.20 x (T4 - 5,818)) + (0.36 x (T4 - 7,446))

PDOC rounds each surtax line. Three Ontario forms close with this rule and no other form changes.

Rule 3 (M-004): PDOC's C matches binary64 (inferred from its outputs)

All 82 CPP-line disagreements had the engine one cent above PDOC. Every one is an exact decimal half-cent:

(500.00 - 350.00) x 0.0595 = 8.925       decimal: rounds half-up to 8.93
150.0 x 0.0595 in binary64 = 8.924999999999999   PDOC shows 8.92

PDOC's code is not public; the rule below is inferred from its outputs on the July 2026 grid (last capture 2026-09-15). The rule that reproduces PDOC is: subtract and multiply in IEEE-754 binary64, take the shortest decimal that round-trips to the result (what Java BigDecimal.valueOf, JavaScript String(x) and Python repr produce), then round half-up to the cent. Three conventions were tested on the full corpus:

Convention	CPP lines that disagree
Exact decimal half-up (T4127)	82
Binary64, exact binary value half-up	22
Binary64, `Math.round(x * 100) / 100`	6
Binary64, shortest decimal then half-up	0

The EI line does not follow this rule: binary64 I x 0.0163 breaks two EI lines that exact decimal gets right, so EI stays decimal in both arms.

The default arm keeps decimal arithmetic for C: 8.925 is a half-cent and T4127 rounds it up. The default arm is T4127 plus two PDOC-matched roundings that T4127's text does not specify (rules 1 and 2). rounding_compat: pdoc reproduces PDOC with an integer-only emulation of the three binary64 operations (crates/takehome-core/src/pdoc_compat.rs), so scripts/float-ban.sh stays clean. The emulator is differential-tested against hardware floating point: 200,000 conversions, 200,000 subtract and multiply pairs, and every gross cent from 0.01 to 20,000.00 at five pay-period exemptions (crates/takehome-core/tests/binary64_emulation.rs).

How the rules were chosen

The rules were chosen by inspecting the full corpus; 15 cases remain unexplained. There is no held-out validation set, so the closed count is a fit to these 8,982 forms, not a prediction for new ones.

Rejected on the full corpus, each making agreement worse: dropping any single intermediate rounding, truncating or banker's rounding at any step, binary64 for the tax chain, unrounded C or EI inside K2, rounding the base before the rate, a rounded 0.0495/0.0595 ratio at 2 to 12 places, and splitting the BC tax reduction product.

What is still open (M-003 residual)

15 forms, all period tax lines, all one cent. In each the engine's T/P sits within a tenth of a cent of a half-cent (fractional cent between 0.40 and 0.54). Six are daily pay (P = 240). None of the rules above, nor any single rounding change tested, closes them without breaking other forms. They count against both rates and are listed in CONFORMANCE.md.

The 780 forms PDOC step 2 did not advance are exactly the 3 x 260 bonus boundary forms (bonus 4,999.99, 5,000.00 and 5,000.01). The salary capture path does not enter a bonus. They stay named and out of the Option 1 rate.

Reproduce

cargo test -p takehome-core --test audit_2026_10_22
cargo test -p takehome-core --test rounding_compat
cargo test --release -p takehome-core --test binary64_emulation
cargo run -p takehome-conformance -- --check

With the corpus archive extracted to data/pdoc-cache/records/, cargo run -p takehome-conformance -- --extract-grid-outputs rebuilds the outputs CSV byte for byte.

Last reviewed: 2026-10-22
Engine: 0.1.0

Source: docs/findings/003-pdoc-cpp-binary64-and-split-credits.md in the Takehome repository, rendered as written.