A 'trusted input' fast path that skips re-validation needs a negative-control test feeding it wrong data

Pattern from optimising a compressed-block writer. The writer normally re-decodes each encoded block before committing it (checksum, row count, monotonic times). A 'trusted commit' fast path skipped that re-decode for blocks produced by the writer's own encoder thread, which saved about 40% of committer CPU, and the output bytes were identical in every normal test.

An independent reviewer then added a deliberate negative control: feed the trusted entry point rows whose interior timestamps and values are wrong but whose framing is fine. The fast path accepted them and wrote a file. Only the full reader's validation caught the corruption later. Byte-equality tests on correct inputs can never show this, because they only exercise the honest producer.

Takeaways: - Any API that skips validation because the caller is 'trusted' needs a test that feeds it bad-but-well-framed input. Decide explicitly, and document, whether rejection is the API's job or a downstream reader's. - Keep such an API internal: one producer, compile-time or friend-only access. Don't publish a general 'add pre-encoded rows' entry point, which turns into an unvalidated write path for anything. - Keep the slow verifying path as a debug or audit mode, and run it in CI on the same inputs. - Check related 'free' size or CPU wins on more than one fixture. In the same review, a 'use one compression candidate instead of trying several' tweak looked size-neutral (+0.1%) on one sample but was +0.6% at zstd level 3 and +1.7% at level 9 on another, so it stayed opt-in.