Proposal: judgment-stage escalation — let [FABLE:PLAN/VERIFY/JUDGE]-tagged spawns go ONE tier above the session model

[Tespera]

This one deliberately goes against a design decision, so I'm opening a discussion instead of a PR. A working implementation (guard changes + tests) lives on my fork's hardening branch if the idea survives scrutiny: https://github.com/Tespera/fable5-mode/tree/hardening

The current stance, and where I think it's inverted

The model ceiling says: never spawn above the session model — fable-mode exists to get Fable-5-grade results without reaching upward. As quota protection, that's sound. But as a quality policy it caps capability in exactly the wrong place.

A round's token budget is spent overwhelmingly on execution — and execution is where the protocol already makes weaker models safe (machine-checkable acceptance, escalation ladder, verification). The stages that decide whether all that execution solves the right problem are tiny: writing the SPEC, reviewing the SPEC, and fresh-eyes verification. Maybe ~5% of tokens. And they are precisely the stages the protocol itself refuses to downgrade ('decomposition, design, debugging and ALL verification stay on the session model — a cheap model here poisons everything downstream'). That reasoning doesn't stop at the session model — it points one tier up:

• A wrong SPEC fails the whole round. Garbage in, discipline out: a weaker model's misreading of the problem gets faithfully executed into a well-documented wrong answer. No downstream gate catches an upstream misunderstanding — every acceptance test was derived from the same misunderstanding.
• The protocol already states 'the verifier must be at least as strong as the implementer.' When the implementer IS the session model, the only way to honor the spirit of that rule (fresh eyes, no shared blind spots) is a tier up — same-tier verification shares the generator's blind spots by construction.
• It's the cost-optimal shape, not a luxury. Strong-plans-cheap-execution beats strong-everything on cost and beats cheap-everything on correctness. The current ceiling forbids the best point on that frontier.

Proposed mechanics (small, auditable, off-switchable)

• A spawn whose payload carries [FABLE:PLAN], [FABLE:VERIFY] or [FABLE:JUDGE] may request one tier above the session model. Two tiers up stays blocked. Untagged spawns: unchanged strict ceiling.
• The tag lands in the payload, hence in the transcript — every escalation is a visible, deliberate, auditable act, consistent with the ROUTING/TIER/PAUSED philosophy of 'never silent'.
• FABLE_JUDGMENT_ESCALATION=off restores the strict ceiling (quota-sensitive users keep today's behavior with one env var).
• [FABLE:VERIFY]/[FABLE:JUDGE] spawns are also exempt from the design gate — the gate exists to stop unplanned implementation fan-out; verification is never that, and final fresh-eyes review legitimately happens when cards are already closed.
• When no stronger tier exists, nothing changes — the tag degrades to a no-op and the existing 'no stronger model available' guidance applies.

The honest counter-arguments

1. 'It's a slippery slope — models will tag everything.' Mitigation: the tag is auditable in the transcript, the design gate still applies to PLAN, and it's one tier, not unlimited. But yes, it relies on the tag being used honestly — like PAUSED reasons already do.
2. 'fable-mode's identity is not-reaching-upward.' Fair. My counter: the identity worth keeping is execution doesn't reach upward. Spending 5% of tokens on judgment so the other 95% solve the right problem is not abandoning frugality — it's what frugality is for.
3. 'FABLE_ESCALATION=on already exists.' It's all-or-nothing: it removes the ceiling for every spawn, including execution. This proposal is the surgical version — escalation only where judgment concentrates.

If the maintainer's stance is a hard no on any upward spawn, a middle ground would be tag-gated design-gate exemption only (no model escalation) — the verifier-when-cards-are-closed problem is real independently of the ceiling question.

Happy to turn the fork branch into a PR (with tests — the fork branch has 6 cases covering tag-one-up allowed, two-up blocked, untagged blocked, env-off strict, design-gate exemption scope) if this direction is acceptable.

🤖 Generated with Claude Code