The UDAAP Lens on Silent Clamping

Deception analysis asks whether a practice is likely to mislead a reasonable consumer about something material. An input silently snapped into range, feeding a decision the consumer thinks is about their own numbers, is worth examining under exactly that lens.

The Dodd-Frank Act's Section 1031 gives federal consumer-protection law its modern working vocabulary: unfair, deceptive, or abusive acts or practices, with deception turning on whether a representation or omission is likely to mislead a reasonable consumer and is material to their decision. This piece applies that lens to one specific, widespread calculator behavior — silent input adjustment — and to the design pattern that eliminates it. One boundary first: this is a risk analysis from the engineering side, meant to give product and compliance teams a shared frame. Whether any practice violates any law in any context is a determination for regulators, courts, and the firm's counsel — never for a vendor's essay.

The behavior in question

Silent clamping is the default behavior of most calculator code, usually without anyone deciding it. A user enters a savings rate of 90 percent; the tool's slider maxes at 80 and computes with 80. A retirement age below the current age gets bumped to current-age-plus-one. A loan term outside the supported range snaps to the boundary. In every case the tool then displays a confident answer — with no indication that the question was changed before it was answered. The user reads the output as a statement about their inputs. It is not. The gap between what the consumer believes the number represents and what it actually represents is precisely the raw material of a deception analysis: an omission (the adjustment was not disclosed) about something material (the number informs a financial decision).

Why intent does not rescue it

No engineer clamps inputs to mislead anyone; clamping is what happens when a team wants to avoid error states. That is exactly why the pattern deserves a compliance-grade name. Deception analysis in consumer protection is generally about the practice's likely effect on the consumer, not the firm's intent — a well-meaning silent substitution and a cynical one read the same from the consumer's side of the screen. The scale multiplies the concern: a clamping calculator does not mislead one consumer once; it applies the same undisclosed substitution to every out-of-range user it ever serves, which is the pattern-and-practice shape that can turn a UX shortcut into an examination topic.

The last row is the design answer

The platform's contract makes the fourth row the only possible behavior: out-of-domain inputs are rejected with the field and the valid range named; missing inputs are individually named, never defaulted — the API has no optional inputs; and cross-field violations return the rule as the error message. Where a model carries a convention worth knowing — a percent-points input, a scope boundary — the constraint note travels in the envelope's assumptions array, disclosed rather than implied. The consumer-facing consequence is structural: there is no code path on which a Worthune model answers a different question than the one asked. A product built on it can still reintroduce the risk one layer up — a UI that clamps before calling the API has rebuilt the problem — which is why the error-handling guide (/writing/out-of-range-errors) treats client-side clamping as the design temptation to resist, and why the refusal-design piece (/writing/refusing-beats-guessing) gives rejection its UX vocabulary.

What a product team should take from this

• ✓Audit for adjustment: any place your stack modifies a user value before computing is a finding.
• ✓Kill client-side clamps — constrain the control, or relay the rejection, but never adjust silently.
• ✓Surface the assumptions array where the number renders — disclosure that exists but is hidden is barely disclosure.
• ✓Phrase sentinels as the honest extremes they are, not as errors to soften.
• ✓Put this pattern in front of your compliance function with this frame — it is their lens, applied to your code.

The convergence worth noticing

The consumer-protection lens and the engineering lens land on the same requirement from opposite directions. Auditability demands that stored inputs be the computed inputs — the envelope's echo and hash depend on it. Consumer protection demands that the consumer's understanding match the computation — no silent substitutions. One mechanism delivers both: reject what you cannot compute within the studied range, disclose what you assumed, annotate the extremes. That a trust-engineering decision and a consumer-protection instinct converge on the same architecture is the strongest signal in this pillar that the architecture is right.