PATTERN Cited by 1 source

Model as interchangeable component

Intent

Design AI pipelines so that the underlying model can be swapped, rotated, or cross-tested without affecting the orchestration logic — treating models as commodity compute rather than system-defining components.

Mechanism

1. Design the harness to be model-agnostic from day one — no model-specific prompt engineering that breaks on swap.
2. Use different models for different stages (e.g., one for discovery, a different one for validation) so findings are cross-checked by distinct logical weights.
3. Absorb provider-side volatility (temperature changes, caching policy shifts, inference-effort adjustments) at the orchestration layer.
4. When pointed at the same target, different models turn up different shares of bugs — model diversity increases coverage.

Rationale

"Relying on a single model inherently limits defensive coverage, as the same system will tend to look at code paths through the exact same lens." (Source: sources/2026-06-18-cloudflare-build-your-own-vulnerability-harness)

Seen in

• systems/cloudflare-vulnerability-discovery-harness + systems/cloudflare-vulnerability-validation-system — VDH and VVS explicitly use different models; the post names this as an "obvious security benefit"

Related

• concepts/model-agnostic-orchestration — the concept form
• patterns/adversarial-cross-model-validation — the specific cross-check application