Five jobs, five model assignments, and two rules that hold whichever you pick.

Jobs are assigned per role

Architecture, critique, coding, security review and documentation each resolve to their own assignment, and an assignment names a provider, a model and a model version rather than a vendor. That third field is the one that matters in a year: without a pinned version, a provider upgrading a model in place arrives as a change in behaviour with nothing in the record to account for it.

Proposer and critic come from different weights

The rule is applied to the resolved pair, not to the shape of the workflow: the platform compares the proposing route with the reviewing route before either one runs, and the same provider, model and version in both seats is a resolution failure rather than a warning somebody reads afterwards. That comparison catches the case a diagram hides, where two roles were pointed at one assignment months apart by different people.

Critical work uses two providers

Critical is a grade the policy engine assigns from what a change touches, so the requirement attaches to the change rather than to whichever workflow it arrived in. Different providers, not merely different models from one vendor: weights trained together tend to fail together, and a second read is worth having only where it can fail differently. A portfolio with one provider configured still runs everything else — the critical path is what stops, naming the second provider it could not find.

Model output is still a proposal

Whatever model is assigned, its output enters the same path: named operation, schema validation, policy evaluation, then approval where a rule requires one. A stronger model produces better proposals. It never produces wider permissions.