[Abidoyesimze]

Summary

Implements Track B of #279 — a fix for F4 (dp-mechanism-review.md), not just a written recommendation.

Is the mismatch real, and how large in practice? Yes. The Laplace mechanism's privacy guarantee is calibrated against L1 sensitivity, but post_training_laplace reuses the same L2 clip as the Gaussian mechanisms. The relationship ||x||₁ ≤ √d · ||x||₂ means an L2 bound of C only guarantees an L1 bound of √d · C — for cache_model_0's reference model (~109K parameters), that's a ~330x gap. For real NN weight tensors (dense, not sparse — most coordinates have comparable magnitude, not a few dominant ones), the actual ratio tends toward the worst case, not away from it. So post_training_laplace's noise can understate its true sensitivity by roughly two orders of magnitude for this model size, and worse for larger ones.

Which resolution? Implemented update_laplace: mirrors update_gaussian's delta-level privatization (compute the local update, clip it, add noise, reconstruct), but clips the delta against its L1 norm instead of L2, so clipping_norm becomes the sensitivity bound the Laplace noise is actually calibrated against. post_training_laplace is left untouched — it remains an experimental baseline only (F5, already true regardless of F4), since F5's clip-the-wrong-quantity problem applies to it independently and isn't fixed by recalibrating the noise.

Given F5, is there reason to keep weight-level mechanisms? Only as clearly-labelled experimental baselines (no change needed here — already true). update_gaussian/update_laplace are the mechanisms with a defined sensitivity bound.

Changes

• clip_weights/clip_state_dict gain a norm_type parameter ("l2" default, "l1" for the new mechanism). The global-scope L1 case is exactly additive across tensors (no square root — unlike L2's sum-of-squares), so per-layer L1 clipping to C bounds the combined norm at C·n, not C·√d.
• apply_dp_mechanism gains an update_laplace branch, mirroring update_gaussian's structure.
• resolve_dp_config requires laplace_scale for update_laplace too (same reasoning as post_training_laplace).
• Documentation/technical/services/clients.md: new ### update_laplace section, tightened L1-vs-L2 notes.
• Developer/BACK_LOG.md's BL-24 marked resolved.
• 8 new/updated tests in tests/test_cache_client_dp.py, including a direct L1-composition test mirroring the existing L2 one (test_global_clip_scope_bounds_the_combined_l1_norm), full coverage parity with update_gaussian (preserves-weights-at-zero-noise, requires-reference, requires-explicit-scale, noise-scales-with-clipping-norm/noise-multiplier).

Note on #288 (Track A, open)

Both PRs touch cache_model_0/services/client.py and Documentation/technical/services/clients.md's post_training_laplace/post_training_gaussian/"Noise Calibration" prose, in nearby but not identical hunks. I kept this PR fully standalone (no dependency on #288 — verified the full test suite passes against develop with only this PR's changes applied), but a textual doc conflict on merge is likely; whichever lands second will need a small reconciliation pass, not a logic conflict.

Test plan

• pytest tests/test_cache_client_dp.py -v — 39 passed, standalone against develop (no feat(dp): label post-training mechanisms experimental (issue #279 Track A) #288 dependency).
• check_doc_links.py Documentation Developer — 564 links, all resolve.

Partially addresses #279 (Track B — Track C was removed from #279's scope since the clipping-default work is covered by PR #247/#263; see #279's scope clarification)

[Santiagocetran]

Thanks, Abidoye. Reviewed bb48f2e against develop 954fbf8 and #279. The update-level L1 clipping is a useful addition, but I’d like two points addressed before approval.

1. P2: Qualify the sensitivity and calibration claims before marking BL-24 resolved.

The new mechanism documentation calls clipping_norm the correct sensitivity bound, and the BL-24 update presents the calibration issue as resolved.

Global L1 clipping bounds each finite floating-point update’s norm by C before noise is added. That alone does not establish sensitivity C: two points within that bound can be 2C apart. Please define which inputs count as neighbors and explain the resulting sensitivity bound, rather than equating clipping radius with sensitivity.

Please state the protected unit and assumptions about the shared reference model, then explain how laplace_scale maps to the intended guarantee. Also explain the limits of that guarantee where integer buffers pass through unchanged.

Until those assumptions and the calibration have specialist review, please qualify the documentation and backlog status rather than present this as a fully established privacy guarantee. This does not require adding DP-SGD or a privacy accountant in this PR.

Similarly, the roughly 330× figure in the PR description is a worst-case norm-conversion bound for the stated model dimension. Please distinguish it from a measured typical ratio or demonstrated privacy loss.

2. P2: Add an end-to-end regression where update_laplace clipping actually binds.

The new global L1 test exercises clip_state_dict directly. The zero-noise apply test uses clipping_norm 100, so clipping is inactive. The noise-scaling tests also deliberately keep inputs inside the clipping bound.

Please add a test through apply_dp_mechanism with update_laplace, a nonzero reference, multiple floating tensors and a delta exceeding the global L1 limit. Set noise to zero and assert that the reconstructed output minus the reference matches the expected globally L1-clipped delta. Choose values that distinguish L1 from L2 clipping, and retain the integer-buffer preservation assertion.

This would catch a regression that accidentally omits norm_type="l1", and exercise delta computation, binding clipping and reconstruction together. The existing helper and no-op tests do not verify that combined behavior.

Please also reconcile the four overlapping files with #288 so its experimental-mechanism warnings and tests are preserved. The PR description’s remaining Track C reference should reflect Abraham’s scope clarification, rather than reopening the default-clipping work here.

CI is green. The observed Python run passed 545 tests with 133 integration tests deselected; full GI was skipped. My findings rely on source inspection and observed CI. I have not run a local PyTorch or training validation, and the privacy guarantee itself remains unverified.

[robertocarlous]

Reviewed against develop in an isolated worktree (feat/issue-279-update-laplace on top of the upstream develop tip at PR base 954fbf8d, 1 commit bb48f2eb). Note: the branch does not merge cleanly against current upstream develop (f2cff581); see merge-proposal below.

CI on bb48f2eb: CI OK ✅, Python ✅ (545 passed, 133 integration deselected), Solidity ✅, Docs ✅, Integration paths ✅, full GI skipping as usual. Review is based on source inspection and observed CI — no local PyTorch or training run, consistent with Santiagocetran's review.

---

Claimed — update_laplace added as a fourth mechanism. Verified: SUPPORTED_DP_MECHANISMS (line 49), DP_MECHANISM_ALIASES "update-laplace" alias (line 60), and a full branch in apply_dp_mechanism (lines 466–480) all exist and are consistent.

Claimed — norm_type="l1" correctly wired in apply_dp_mechanism. Verified by direct inspection: line 475 passes norm_type="l1" to clip_state_dict in the update_laplace branch. The post_training_gaussian and post_training_laplace paths (lines 436, 444) do not pass norm_type, so they default to "l2" — correct.

Claimed — global L1 norm is exactly additive (no square root). Verified in clip_state_dict lines 181–182: the global-L1 path sums _tensor_norm(value, "l1") directly, without a sum-of-squares or square root. This is mathematically correct — L1 is additive across tensors by the triangle inequality, not sum-of-squares.

Claimed — update_laplace mirrors update_gaussian's structure. Verified: both compute local_delta, call clip_state_dict on it, call add_noise_to_state_dict, and call reconstruct_state_dict_from_delta. The only structural differences are norm_type="l1" for the clip and noise_kind="laplace" for the noise.

Claimed — update_laplace requires reference_state_dict. Verified: lines 467–468 raise ValueError immediately if it is None — same guard as update_gaussian.

Claimed — resolve_dp_config requires laplace_scale for update_laplace. Verified: line 384 condition changed from if dp_mechanism == "post_training_laplace": to if dp_mechanism in ("post_training_laplace", "update_laplace"):.

Claimed — integer buffers pass through unchanged. Verified: clip_state_dict lines 196–202 copy non-floating tensors directly in both per-layer and global paths; apply_dp_mechanism's add_noise_to_state_dict call passes the clipped delta which already has integer buffers preserved, and reconstruct_state_dict_from_delta rebuilds from reference + noisy_delta while keeping integer values from trained_state_dict (confirmed in lines 250–256 of the file). Unverified by any dedicated test path — the zero-noise test (test_update_laplace_preserves_weights_when_noise_is_zero) includes a counter tensor, which is the closest current check.

Claimed — 8 new/updated tests, 34 pass standalone against develop. Verified: test_global_clip_scope_bounds_the_combined_l1_norm, test_update_laplace_preserves_weights_when_noise_is_zero, test_update_laplace_requires_a_reference_state_dict, plus coverage-parity tests for requires-scale, noise-scaling. The L1-composition test correctly places multiple tensors each exceeding clipping_norm and asserts per-layer sums to clipping_norm * n while global sums to clipping_norm. This directly demonstrates the composition gap.

---

Verified — P2 finding No. 1 (Santiagocetran): sensitivity claim is unqualified. The doc (clients.md lines 180–182) states "clipping_norm is the correct sensitivity bound for the Laplace noise added on top of it." This claim requires a neighbor definition. For the Laplace mechanism, (ε, 0)-DP requires laplace_scale ≥ Δf/ε where Δf is the L1 sensitivity — the maximum L1 norm change in the output for two adjacent inputs. If neighbors are datasets differing in one client's contribution (client-level DP), and one neighbor has client i and the other does not, then sensitivity is C (a client with no update contributes a delta of zero, so the distance to a clipped delta of at most C is C). If neighbors differ in one data point within a client's dataset, sensitivity depends on how much that changes the delta — which is not bounded here. The doc presents clipping_norm = Δf without stating which neighbor definition applies, and BL-24's "✅ Resolved" status similarly presents the guarantee as established. Both should be qualified pending specialist review.

Verified — P2 finding No. 2 (Santiagocetran): no end-to-end binding-clipping test. All existing update_laplace tests either call clip_state_dict directly (bypassing apply_dp_mechanism's delta computation and reconstruction) or call apply_dp_mechanism with clipping_norm=100 (zero-noise test) or with small inputs (noise-scaling tests) — none causes the clip in apply_dp_mechanism to actually fire on the full delta. A regression that replaces norm_type="l1" with the default "l2" would not be caught by any current test.

Conflict with upstream/develop. Current upstream develop (f2cff581, after PR No. 263 merged) has a different BL-23 row than the PR's base (954fbf8d). git merge-tree --write-tree against current upstream reports a conflict in Developer/BACK_LOG.md (BL-23/BL-24 rows in the same table region). tests/test_cache_client_dp.py auto-merges. The branch needs a rebase or update-branch before it can merge.

PR description Track C reference. The description says "Partially addresses No. 279 (Track B only — issue stays open for Track C)" but Abraham removed Track C from issue No. 279 (the clipping-default work was already covered by PR No. 247 / PR No. 263). The description's Track C sentence should be updated.

PR No. 288 overlap. PR No. 288 ("feat(dp): label post-training mechanisms experimental, Track A") is still open and touches cache_model_0/services/client.py, tests/test_cache_client_dp.py, Documentation/technical/services/clients.md, and Developer/BACK_LOG.md — all four files changed here. The two PRs are logically independent (Track A vs Track B), but whichever lands second will need a reconciliation pass on the experimental-mechanism warning text and any test additions from the other. Sequencing should be agreed before either merges.

[robertocarlous]

Merge proposal

Head at review: bb48f2ebfe26f5280f1f35bbac53a2e03b3e162d
Merge base (upstream develop at PR creation): 954fbf8d74058f4000f22760550eedd5d8a7f466
Current upstream develop: f2cff581 — branch is behind and conflicting (rebase required before merge)

cache_model_0/services/client.py

Key	Value
Change	+84/-33 lines: _tensor_norm helper (L1/L2); clip_weights/clip_state_dict gain norm_type param; update_laplace mechanism added to SUPPORTED_DP_MECHANISMS, aliases, apply_dp_mechanism; resolve_dp_config requires laplace_scale for update_laplace; minor comment/docstring updates
Pending proposal	None — implementation verified correct
Recommended merge proposal	Merge once tests and docs are fixed; reconcile with PR No. 288's client.py changes when sequencing is agreed
Actual merge proposal	Soon

tests/test_cache_client_dp.py

Key	Value
Change	+149/-1 lines: update_laplace added to DP_MECHANISMS; build_small_state_dict per-element magnitude lowered (L1-safe); L1-composition test; 5 new update_laplace tests (zero-noise, requires-reference, requires-scale, noise-scales-with-clipping-norm, noise-scales-with-multiplier)
Pending proposal	P2-2 Add one end-to-end test through apply_dp_mechanism where the delta exceeds the global L1 limit: multiple floating tensors, nonzero reference, laplace_scale=0, assert reconstruct(reference, clipped_delta) == output with delta clipped to L1 norm = clipping_norm. Choose values where L1 and L2 clipping would give different results, and assert the integer buffer is preserved. Without this, removing norm_type="l1" from line 475 of client.py is undetected.
Recommended merge proposal	Add the binding-clipping regression, then merge
Actual merge proposal	Soon

Documentation/technical/services/clients.md

Key	Value
Change	+60/-10 lines: update_gaussian step 2 qualified as "L2-clip"; new ### update_laplace section; clipping-behavior section updated for L1/L2 distinction; laplace_scale requirement note updated
Pending proposal	P2-1 Qualify the sensitivity and calibration claims. The doc states "clipping_norm is the correct sensitivity bound for the Laplace noise." This is true only under a stated neighbor definition (e.g., client-level DP where one neighbor omits one client's contribution). State which neighbor definition applies, that this gives (ε, 0)-DP with laplace_scale = clipping_norm / ε under that definition, and that formal verification requires specialist review. Also note the integer-buffer caveat (non-floating tensors pass through unchanged, so the clipped output isn't fully privatized — they are presumed non-sensitive).
Recommended merge proposal	Add the neighbor-definition qualifier and specialist-review caveat, then merge
Actual merge proposal	Soon

Developer/BACK_LOG.md

Key	Value
Change	+1/-1 line: BL-24 status from "🆕 New — unaddressed" to "✅ Resolved" with PR description
Pending proposal	P2-1 (same item) BL-24 "✅ Resolved" presents the calibration as established. Change to something like "✅ Resolved (qualified) — update_laplace provides the correctly-calibrated alternative (L1-clip the delta, add Laplace noise); formal DP guarantee requires a stated neighbor definition and specialist review." Also: rebase branch onto current upstream develop to resolve conflict with BL-23 row (changed by PR No. 263 merge).
Recommended merge proposal	Qualify the BL-24 status and rebase, then merge
Actual merge proposal	Soon

[robertocarlous]

P2-1: qualify sensitivity/calibration claims in clients.md and BL-24 (neighbor definition missing — clipping_norm is the sensitivity bound only under a stated neighbor model, e.g. client-level DP; specialist review caveat needed). P2-2: add end-to-end binding-clipping test through apply_dp_mechanism where the delta actually exceeds the global L1 limit (current tests never fire the clip; removing norm_type="l1" from line 475 is undetected). Also: rebase onto current upstream develop to resolve BACK_LOG.md conflict (PR No. 263 merged and modified BL-23, adjacent to BL-24). Reviewed at bb48f2e.

[umeradl]

Reviewed against develop in an isolated worktree. The branch is four commits (299197a … 9743cc9) on merge-base f2cff58; develop is now at f5b2284, which touches none of this PR's files. It merges cleanly: git merge-tree --write-tree exits 0, and GitHub agrees (mergeable: MERGEABLE, mergeStateStatus: BEHIND). CI on 9743cc9: CI OK green. I also ran it on a local trial merge with develop: pytest tests/test_cache_client_dp.py → 39 passed. Beyond the tests, I checked the documented ε recipe numerically and diffed the backlog table row by row.

Claimed: update_laplace L1-clips the per-client delta and adds Laplace noise to it, mirroring update_gaussian.

Verified — holds: apply_dp_mechanism computes the delta, calls clip_state_dict(..., norm_type="l1") and reconstructs from the reference. The global-scope L1 norm is the additive sum over tensors, as it should be. test_global_clip_scope_bounds_the_combined_l1_norm and test_update_laplace_binding_clipping_through_apply_dp_mechanism pass.

Claimed (clients.md L195, BL-24 row): under client-level DP the mechanism is (ε, 0)-DP "at laplace_scale = clipping_norm / ε".

Verified — does not hold. The recipe is off by a factor of clipping_norm. The noise scale the code adds is b = laplace_scale * clipping_norm (client.py:429-430). With L1 sensitivity Δ = clipping_norm, ε = Δ / b = 1 / laplace_scale. So the correct recipe is laplace_scale = 1/ε, independent of clipping_norm. I measured this rather than just deriving it: update_laplace on a zero delta with 200,000 coordinates, clipping_norm = 10 and laplace_scale = 10 (the doc's recipe for ε = 1) gives a mean |noise| of b = 100.13, i.e. an actual ε = 0.100, not 1.0. With clipping_norm = 10 (the manifest default since PR No. 263) that's 10× too much noise. Whenever clipping_norm < 1 the same recipe would add too little noise and overstate the guarantee.

Claimed: sensitivity is clipping_norm under the stated neighbour definition (one client's update vs. a zero delta).

Not settled — question for the DP specialist on issue No. 279: noise here is added locally by each client before upload. Under the replace-one-update neighbour definition (any clipped delta vs. any other), the L1 sensitivity is 2 × clipping_norm, which halves the ε. The PR's add/remove-style definition is stated honestly, but which definition DevNet wants to claim is the specialist's call. That's also why the status shouldn't be "Resolved" yet (next point).

Claimed (BACK_LOG.md): BL-24 → "✅ Resolved (qualified)", plus commit 9743cc9 "sync backlog and manifest from develop".

Verified — does not hold, blocking: 9743cc9 does not sync from develop. It replaces develop's table header and BL-1 … BL-20 (nonce management, signing keystone, … dind healthcheck) with 20 new rows BL-01 … BL-20 ("load_din_info relies on…", "Repo hygiene", …). Those rows don't exist anywhere in the repo's history: git log --all -S'BL-01 | Platform/Docs' finds only this commit. It also deletes BL-28 … BL-35: the releaseGIRegistrationSlots command, DinFeeRouter stuck shares, stalled-GI recovery, S6 wiring, preflight check, deployment drift check, the disableModel() kill-switch gap, and rejectModel() non-refund. The result is 27 rows instead of 35. The commit message also mentions the manifest, but 9743cc9 only touches BACK_LOG.md.

Not independently re-verified: the "real NN tensors tend toward the √d worst case" remark in the issue comment; it isn't asserted in the docs.

---

The mechanism itself looks right and is well tested. Changes requested before merge:

1. Restore Developer/BACK_LOG.md to develop's version and change only the BL-24 status cell. The easiest way is git checkout origin/develop -- Developer/BACK_LOG.md, then re-edit BL-24.
2. Fix the ε recipe in clients.md and the BL-24 row: laplace_scale = 1/ε (noise scale b = clipping_norm/ε). A test that pins the realised noise scale to laplace_scale * clipping_norm would stop it drifting again.
3. BL-24 status: use "🟡 Started, unmerged" (or "Partially addressed") until the DP specialist has reviewed the neighbour definition and sensitivity on issue No. 279. Don't use "Resolved".
4. Coordinate with PR No. 288. It edits the same clients.md sections and the BL-24 row; the two branches conflict in clients.md. Whichever lands second rebases and keeps both changes.

[umeradl]

Files changed (4) — as of 9743cc9 (PR head)

Diffed against merge-base f2cff58 (develop). develop has moved to f5b2284 since then, but none of those commits touch this PR's four files. GitHub agrees: mergeable: MERGEABLE, mergeStateStatus: BEHIND. Confirmed with a local git merge-tree --write-tree dry run: clean against develop, but conflicts with PR No. 288 in clients.md.

cache_model_0/services/client.py

Field	Value
Change	Modified
Lines	+67/-17
Diff (what exactly is in this PR)	Adds the update_laplace mechanism and its update-laplace alias, a _tensor_norm helper, and a norm_type ("l2"/"l1") parameter on clip_weights/clip_state_dict. laplace_scale is now required for update_laplace as well.
Functionality — how & why	How: delta = trained − reference → L1 clip (global scope: additive sum of per-tensor L1 norms; per-layer: each tensor) → Laplace noise of scale laplace_scale * clipping_norm → reconstruct from the reference. L2 stays the default, so the existing mechanisms are unchanged. Why: F4, the Laplace mechanism is calibrated against L1 sensitivity, so the clip has to bound the L1 norm.
Diff vs current develop HEAD	Untouched by develop since merge-base.
Recommended merge proposal	Merge as-is (39 passed on the local trial merge).
Actual merge proposal	Soon
Pending proposal	None for the code. The ε recipe is a docs fix (below).
Local merge conflict	No
GitHub merge conflict	No

tests/test_cache_client_dp.py

Field	Value
Change	Modified
Lines	+198/-4
Diff (what exactly is in this PR)	Seven tests: global L1 bound, zero-noise identity, reference/scale required (direct and via resolve_dp_config), no experimental warning, and an end-to-end binding-clip test.
Functionality — how & why	How: synthetic state dicts through clip_state_dict/apply_dp_mechanism. Why: pins the new mechanism's behaviour.
Diff vs current develop HEAD	Untouched by develop since merge-base.
Recommended merge proposal	Merge as-is. Suggested addition: a test that pins the realised noise scale to laplace_scale * clipping_norm.
Actual merge proposal	Soon
Pending proposal	Optional noise-scale test.
Local merge conflict	No
GitHub merge conflict	No

Documentation/technical/services/clients.md

Field	Value
Change	Modified
Lines	+65/-11
Diff (what exactly is in this PR)	New update_laplace section, the L1/L2 norm-type note, the per-layer clipping_norm * n bound, and the explicit-laplace_scale rule.
Functionality — how & why	How: docs only. Why: documents the new mechanism and its guarantee.
Diff vs current develop HEAD	Untouched by develop. Conflicts with PR No. 288 in the same sections.
Recommended merge proposal	Needs a fix: L195 laplace_scale = clipping_norm / ε → laplace_scale = 1/ε (measured: the doc's recipe gives ε = 0.1 when 1.0 is intended at clipping_norm = 10). Mark the sensitivity statement as pending the specialist's review of the neighbour definition (Δ₁ = 2C under replace-one).
Actual merge proposal	Soon
Pending proposal	ε-recipe fix; neighbour-definition review on issue No. 279; rebase after No. 288 if it lands first.
Local merge conflict	No (against develop)
GitHub merge conflict	No

Developer/BACK_LOG.md

Field	Value
Change	Modified
Lines	+27/-36
Diff (what exactly is in this PR)	Commit 9743cc9 replaces the header and BL-1 … BL-20 with 20 unrelated, previously non-existent rows (BL-01 … BL-20), deletes BL-28 … BL-35, and sets BL-24 to "✅ Resolved (qualified)" with the incorrect ε recipe. 35 rows → 27.
Functionality — how & why	How: a whole-table rewrite labelled "sync … from develop". Why: only the BL-24 status change is intended; the rest looks like an accidental regeneration.
Diff vs current develop HEAD	Untouched by develop since merge-base, so Git won't flag any of this as a conflict. That is exactly why it has to be fixed before merge.
Recommended merge proposal	Do not merge as-is. Restore develop's file and change only BL-24's status: "🟡 Started, unmerged — PR No. 292 (F4, update_laplace), tracked in issue No. 279; pending DP-specialist review", using laplace_scale = 1/ε if the recipe is quoted.
Actual merge proposal	Soon
Pending proposal	Restore the file; one-cell BL-24 edit.
Local merge conflict	No
GitHub merge conflict	No

Verification

pytest tests/test_cache_client_dp.py on a local trial merge with develop f5b2284: 39 passed. Numerical ε check and backlog row diff: see the verification comment above.

Local vs. GitHub agree: clean against develop on both. The clients.md conflict is with PR No. 288, not develop.

[umeradl]

Changes requested at 9743cc9. Details are in the verification comment.

1. Restore Developer/BACK_LOG.md to develop's version (commit 9743cc9 replaces BL-1 … BL-20 with rows that never existed and deletes BL-28 … BL-35). Then change only the BL-24 status cell.
2. Fix the ε recipe in clients.md and BL-24: laplace_scale = 1/ε, not clipping_norm / ε (measured ε = 0.1 when 1.0 is claimed, at clipping_norm = 10).
3. BL-24 status: not "Resolved" until the DP specialist has reviewed the neighbour definition and sensitivity on issue No. 279.
4. Rebase onto develop: PR No. 288 merged in 6e73dca and touches the same clients.md sections and the BL-24 row.

[Abidoyesimze]

Pushed b5992d3 addressing both reviews:

P2-1 (sensitivity/calibration qualification) — clients.md's update_laplace section and Noise Calibration section now state the neighbor definition explicitly: under client-level DP (one neighbor has a client's update, the other a zero contribution), the clipped delta's L1 norm bound (clipping_norm) is the L1 sensitivity, giving (ε, 0)-DP at laplace_scale = clipping_norm / ε under that definition — flagged as not yet DP-specialist-reviewed, and noting integer buffers pass through unprivatized (presumed non-sensitive). Also softened the √d figure in the PR description's framing to a worst-case norm-conversion bound, not a measured/typical ratio. BACK_LOG.md's BL-24 status updated to "✅ Resolved (qualified)" with the same caveats, building on #288/Track A's "partially addressed" note rather than overwriting it.

P2-2 (binding-clipping regression) — added test_update_laplace_binding_clipping_through_apply_dp_mechanism: goes through apply_dp_mechanism with a nonzero reference (so it also exercises the reconstruction step, not just the clip), multiple floating tensors, a delta exceeding the global L1 limit, zero noise, and values chosen so L1 and L2 clipping diverge (L1 norm 40 vs. L2 norm ~10.5 against clipping_norm: 10.0). Confirmed it actually catches the regression — temporarily dropped norm_type="l1" from the update_laplace branch and the test failed as expected, then restored it.

Rebase + #288 reconciliation — rebased onto current develop (past #288's merge). #288 added EXPERIMENTAL_DP_MECHANISMS and a runtime warning recommending update_gaussian as "the mechanism with a defined sensitivity bound" — written before update_laplace existed. Updated that warning (in both client.py and clients.md) to recommend update_gaussian or update_laplace, and cross-referenced update_laplace from the post_training_laplace section as its correctly-calibrated, update-level counterpart.

Also fixed the PR description's stale "Track C" line per Abraham's scope clarification, and updated the test-plan counts (42 tests pass, 571 doc links resolve). mergeable is now clean against develop.