Reconciling my "hard window" with Min's "soft" ruling — his is right, and why

Date: 2026-10-10 Author: Sol Status: RECONCILIATION — I am correcting my own recommendation Conflicts with: my sol-go-allowance-hard-or-soft.md (now archived — 05-archive/06-implementation-notes/sol-go-allowance-hard-or-soft.md), which recommended hard on the 5-hour windowAgrees with: 03-decisions/go-allowance-and-model-selection.md (Min) and stage-6-cost-and-retention.md §"RULED", which both say SOFT

Young confirmed: "That true Sol, it's a per-model allowance." That confirmation is about the per-model point, which Min and I agree on completely.

What it exposes is that Min and I reached different answers on hard-vs-soft, and his is correct. This file records why mine is withdrawn rather than left standing beside his.

1. What I recommended, and what Min ruled

Min's ruling is in the plan of record and in his decision doc. Mine is the outlier and it should be withdrawn.

2. Why his is right and mine was wrong

My argument was: the 5-hour window is what converts GO spend into ZEN credit spend, so it must be hard or money leaves the plan.

Min's counter, from the vendor's own words, is decisive:

"If you also have credits on your Zen balance, you can enable the Use balance option in the console. When enabled, Go will fall back to your Zen balance after you've reached your usage limits instead of blocking requests."

"Instead of blocking requests" is the answer, and it defeats mine completely. I designed a guard to prevent something that is already the vendor's intended behaviour:

And the deeper error: I treated a designed fallback as a defect to guard against. That is exactly the V2 pattern I keep flagging — building a control against behaviour that is working correctly. A hard 5-hour guard would have produced the opposite of what I intended: the fleet stops, while $40 of paid credit sits unspent.

"Money is unrecoverable, work is not" — my own line — cuts the other way here. The credit is already spent the moment we pay the $40. A hard guard would be protecting money that is already gone, at the cost of work that is not.

3. What survives from my analysis

Three things, and they are the parts that were not in conflict:

1. The per-model point — agreed, and now the more valuable half. Young confirmed it. Min had it independently. It makes 6.5's proof writable: exhaust one model's window, and the ledger must record window_state: blocked for that model while another is still ok — because the allowance is per model, not per workspace.

2. The observability prerequisite — unchanged, and still blocking. The Budgets API needs a service-account key with All permissions; ours are inference-only. A soft guard is still unverifiable without it — you cannot confirm the fallback fired if you cannot read the budget. That item stands.

3. The two-tier paid list — unchanged, but the reason strengthens. Under a soft guard the paid tier is used, not merely available, so retention matters more: Muse Spark 1.2 is the capacity winner and must stay non-default because it trains on request data.

4. What I want recorded about the process

This is the second time this session I have recommended something that a vendor's own documentation had already answered.

• First: I claimed the v0.3 compat adapter was gone in a2a-sdk 1.2.2. It was there — I had looked in the wrong directory.
• Now: I designed a guard against a fallback the vendor documents as intended.

Both times the failure was designing from a principle before checking the substance. "Guard the boundary" is a good principle and it is not a substitute for reading what the boundary actually does.

The rule I am adopting for my own lane:

Before designing a control, check whether the behaviour it guards against is a defect or a design. If it is a design, the control is duplication.

That belongs in live-system-verification, and I am adding it there rather than leaving it in a chat message.

5. Net state

No code, no guard, no probe. One reconciliation, and one lesson recorded where it will load next time.