What not to compress

Stated outright, not buried: source code, configuration files, diffs, and legal or contract text are a poor use case for the ladder.

Why

These texts are constraint-dense with near-zero redundancy. Every clause carries weight; dropping "filler" drops constraints. Compression here fails silently: the output stays fluent, and a superficial check looks fine, while qualifiers, cross-references, or deeming clauses are gone.

This is a measured result on our calibration corpus, not an assumption:

• Legal excerpts (open-source license texts and statute sections) at targets 0.5 through 0.7: judged material loss on nearly every unit, with flagged semantic differences concentrated at targets at or below 0.6. The losses sit in legal qualifiers, deeming clauses, and cross-references - exactly the surfaces where damage is expensive.
• Code and config share the profile: the deterministic rung's AST pruning is the only safe squeeze we ship for fenced code, and it strips structure, not logic.

What to do instead

• For code and config: rely on deterministic mode's structural stripping only, and audit the receipt's integrity fields per call.
• For legal text: do not squeeze it with this service at launch. The receipt will honestly disclose material loss if you try - the fidelity fields exist precisely so you can catch this yourself.
• The receipt is the referee: whatever the guidance says, the per-call fields (headline.ratio, quality.fidelity_score, quality.min_window_posterior) tell you what actually happened to your bytes.