We measure skill durability across substrates — not model rankings.

Driftproof now runs the same suites on more than one provider's models. This page states the neutrality policy that governs a cross-provider report, and the one limitation that matters most, plainly.

What a cross-provider report is — and is not

A Driftproof report asks one question: does a skill still help, and by how much, on the substrate underneath it? When that substrate is two different model families — say a Claude flagship and a GPT flagship — the report shows the skill's with-vs-without lift on each, side by side. The interesting signal is whether a skill's benefit is durable across substrates or whether it depends on the model it was written against.

This is not a model leaderboard. Driftproof does not rank GPT against Claude, and a report's baseline scores are not a "which model is smarter" table. Comparing raw baseline numbers across providers would conflate model capability, judge affinity, and prompt-format differences into one meaningless figure. The unit of evidence is the skill's delta on a fixed judge, not a model's absolute score.

Same suites, same judge, same n — no authoring favoritism

Same suites. Every provider is run on the identical eval suites at the identical pinned rubrics (Report #001 v1.2 rubrics). No provider gets a suite tuned to its strengths.
Same judge. One fixed, cheap judge (claude-haiku-4-5) grades every generation from every provider. The judge is held constant so the target model is the only thing that varies. Only a model with judge_eligible: true in the registry may judge — and no OpenAI model is judge-eligible, by policy.
Same n. Identical sample count per case (n = 5) and the identical band + effect-floor verdict rule across providers. See the methodology.
No favoritism in authoring. Rubrics grade against a skill's own documented claims (the grounding policy), not against any provider's house style.

The judge-affinity limitation (stated plainly)

The fixed judge is a Claude-family model, and it grades generations from every provider. An LLM judge can be marginally kinder to prose that resembles its own family's — so a Claude-family judge grading a Claude generation may score it slightly higher than an equally-good GPT generation. We do not pretend this is zero.

The mitigation is structural: the headline metric is the with/without-skill delta, not the absolute score. Any constant style preference the judge holds toward a provider is present in both the with-skill and the baseline run for that provider, so it largely cancels in the difference. A report leads with each skill's delta on each substrate precisely because the delta is the judge-affinity-robust quantity; absolute cross-provider scores are reported as context, never as a ranking. The judge policy covers style affinity, the grading ceiling on hard suites, quantization, and fail-closed parsing in full.

Surfaces are disclosed per receipt

The same model can be reached over different surfaces: a metered API or a subscription CLI. Driftproof's provider layer is two-axis — provider (anthropic / openai) × surface (api / cli) — and every receipt records the exact provider and surface it ran on.

The API surface is preferred for published runs (temperature is settable, token usage is reported, and it is reproducible for a third party who has a key).

A CLI / subscription surface is disclosed whenever it is used — Report #001 ran on claude-cli and said so, and that precedent holds. On the openai-cli (Codex) surface the receipt additionally carries a surface_overhead_note stating the fixed harness preamble the surface prepends.

A drift comparison between receipts on different surfaces is flagged, because sampling control differs between them.

Matched surfaces in a cross-provider report

Report #002 goes further than disclosure: both substrate columns run on the vendor's own first-party subscription CLI — Claude via claude -p (surface claude-cli), GPT via codex exec (surface openai-cli). The type of surface (a first-party vendor CLI on a subscription) is therefore held constant across substrates, not merely recorded — so a difference between the columns is not an api-vs-cli artifact.

Per-surface harness overhead is disclosed, because it differs. The openai-cli (Codex) surface prepends a fixed ~12,000–15,000-token base-instruction preamble to every call (recorded in each receipt's surface_overhead_note); the claude-cli (claude -p) surface carries a smaller first-party harness/system context. Neither preamble is authored or controlled by Driftproof, both are first-party to the vendor, and each is noted so a reader knows the per-call input-token counts are dominated by a vendor-side constant, not by the skill.

Absolute cross-substrate scores are not a ranking. Because the two substrates sit behind different first-party harnesses (with different overhead and different sampling control), comparing one column's raw number to the other's would conflate model, harness, and judge affinity. The headline metric is the within-substrate with/without-skill delta — computed against the same baseline on the same surface — which cancels the vendor-side constant and isolates the skill's contribution. Read the delta down each column; do not read across the columns as a scoreboard.

Hold the suites, the judge, and the sample count constant; vary only the target model; run both substrates on their matched first-party vendor CLI and disclose each surface's overhead; and lead with the within-substrate delta because it cancels judge affinity and the vendor-side harness constant. That is the whole neutrality policy.