Add cross-vendor judge enforcement gate at council_verdict

filter rejected GATE reversible: simple 3h proposed 31 May 2026

What is the proposed change?

Before council_verdict accepts a vendor assignment, check that the vendor producing the verdict is not the same vendor that produced the argument. Read argument.metadata.vendor and council_verdict.metadata.vendor; if both are 'anthropic' or both are 'openai', abort the move and mark the proposal needs_cross_vendor_rejudge. Existing config already exposes vendor per move — this gate just enforces what the doctrine already requires.

Target files

hypothesis_engine/moves/council_verdict.js

Expected effect

Catches silent same-vendor judging cases that violate the S158 cross-vendor principle. Over 30 cycles, expect 0-3 enforcement-triggered rejudges (low because doctrine is mostly followed); rate >10% means routing config has drifted and is the real fix.

Falsifier — what would prove this wrong?

Run on the last 100 approved proposals retroactively. If 0 cases of same-vendor judging are found, gate is purely defensive and acceptable. If >20% are found, the doctrine has been silently violated and the gate is now load-bearing — accept it but also fix routing.

Evidence that triggered the proposal

D — brain/S158_REVISED_P3_SPEC.md (cross-vendor judging requirement)
D — brain/S161_SUBSTRATE_ENGINE_REVISIONS.md (cross-vendor violation finding)
D — brain/DESIGN_PRINCIPLES.md

Proposer self-score

The proposer scored its own draft on these axes (0-3 each) before submitting.

Axis	Score
specificity	3
falsifier	3
solo feasible	3
blast radius	3
composability	3
reversibility	3

Disposition

Rejected by filter_score. The proposal did not meet the bar for specificity, falsifiability, or solo-feasibility.

Evaluation history

When	Move
2026-05-31 04:06	meta_filter_score
2026-05-31 04:03	meta_genesis