That’s a really good point, and I think you’re right.

My N² argument only applies to the “all pairs, arbitrary version jump in one step” case, which is not how pairwise patch systems are usually deployed in practice. Adjacent diffs, power-of-two/sparse ladders, and base-version strategies are much more realistic baselines.

I’m going to update the wording and benchmarks to reflect that. Instead of framing pairwise diffs as “bad because N²”, I’ll compare CAVS against several practical patch policies:

• adjacent-only diffs;
• power-of-two ladder diffs;
• base-version diffs;
• all-pairs as the theoretical one-step baseline;
• CAVS content-addressed / hybrid reconstruction.

I still think CAVS has an interesting tradeoff because it can reuse cache, previous installed artifacts, and content-addressed chunks without requiring a separate patch graph for every route. But you’re right that the comparison should be against realistic patch policies, not just the worst-case all-pairs model.

Thanks for pointing this out. This is exactly the kind of feedback I was hoping to get.

You were right — my previous wording was too focused on the all-pairs N² case, which is not the way pairwise patch systems are usually deployed.

I updated the benchmark to compare CAVS against more practical patch policies, including adjacent-only updates, skip-heavy scenarios, warm-cache cases, and replayable patch graphs. The new results are now documented in docs/results/v1.1.0/patch-policy/ and summarized in BENCHMARKS.md.

The goal is no longer to frame pairwise diffs as “bad because N²”, but to compare CAVS against realistic policies and show the tradeoffs in storage, update size, skipped-version behavior, apply path length, and cache reuse.

Thanks again for pointing this out — it made the benchmark much better.