Local-first Routing و Model Selection

1. مسئله واقعی: Local-first یک preference است، نه shortcut

یک workflow ممکن است هم‌زمان چند مسیر اجرا داشته باشد: مدل روی workstation، endpoint محلی/کلاستر و provider راه‌دور. اگر router فقط «local بودن»، قیمت یا latency را ببیند، می‌تواند مدلی را انتخاب کند که برای task/locale/risk موردنظر qualification ندارد. در این درس Local-first فقط بعد از عبور hard gateها اجازه اثرگذاری دارد.

2. Routing را از Model Qualification جدا نگه دار

AIE-004 پاسخ می‌دهد یک model/runtime/configuration دقیق برای کدام task/locale/risk slice qualified است. AIE-005 آن evidence را مصرف می‌کند و درباره route تصمیم می‌گیرد. Router حق ندارد نبود qualification را با تجربه قبلی، نام مدل، benchmark عمومی یا یک پاسخ موفق جبران کند.

3. Request contract را قبل از candidateها ثابت کن

هر تصمیم با request slice شروع می‌شود: task، locale، risk، capabilityهای الزامی، latency SLO، placement/privacy و وضعیت data egress. اگر این قرارداد مبهم باشد، رتبه‌بندی candidateها فقط ظاهر تصمیم‌گیری دارد و audit نمی‌تواند بگوید چرا یک route مجاز شده است.

4. Qualification binding باید به نسخه دقیق candidate متصل باشد

QUALIFIED بدون model version، runtime/config و slice مربوط کافی نیست. اگر مدل یا runtime تعیین‌کننده تغییر کند و رکورد qualification متناظر وجود نداشته باشد، binding باید STALE یا MISSING شود. Local-first هیچ اجازه‌ای برای reuse ضمنی qualification قدیمی نمی‌دهد.

5. Capability یک hard gate مستقل است

یک candidate ممکن است از نظر کیفیت qualified باشد ولی capability لازم، مثلاً structured output، را نداشته باشد. این candidate INELIGIBLE است؛ router نباید field را حذف کند، prompt را تغییر دهد یا قرارداد application را ضعیف کند تا مسیر local باقی بماند.

6. Placement و egress بعد از qualification همچنان hard gate هستند

Remote candidate ممکن است بهترین quality و latency را داشته باشد، اما وقتی egress_allowed=false است مجاز نیست. برعکس، local بودن به‌خودی‌خود privacy proof نیست؛ فقط نشان می‌دهد مسیر اجرای محلی است و باید با policy و environment evidence همان deployment ارزیابی شود.

7. Availability و latency evidence را از folklore جدا کن

Qualified بودن به معنی available بودن نیست. Candidate محلی که unavailable است یا latency evidence آن SLO را رد می‌کند، برای همان request eligible نیست. Router باید وضعیت را با evidence ثبت کند، نه اینکه چون route محلی «معمولاً سریع» است آن را انتخاب کند.

8. Cost signal را مصرف کن ولی مالک budget enforcement نشو

AIE-005 می‌تواند cost signal نسخه‌دار را در record نگه دارد و برای preference/ordering استفاده کند، اما quota، retry amplification و circuit state مالک AIE-008 هستند. Router نباید یک budget failure را به تخمین شخصی تبدیل کند یا enforcement آن درس را دور بزند.

9. ترتیب تصمیم: hard gates → eligible set → local preference

الگوی قابل ممیزی این است: qualification binding → capability → placement/egress → availability/latency → eligible candidate set. فقط بعد از این مراحل، local-first preference و route priority اجرا می‌شوند. یک score خوب حق ندارد candidate مردود در hard gate را دوباره وارد رقابت کند.

10. Worked example: چرا remote-alpha انتخاب می‌شود

در fixture پایه، local-ollama-q4 برای فارسی qualification ندارد؛ local-vllm-fp16 برای فارسی qualified است ولی unavailable است؛ remote-alpha برای فارسی/ریسک موردنظر qualified و با egress مجاز available است. نتیجه درست ROUTE به remote است، نه شکستن qualification برای حفظ local-first.

11. Negative case: structured output محلی غایب است

اگر local-vllm-fp16 available و qualified باشد اما requirement اجباری structured output را نداشته باشد، مسیر local مردود می‌شود. اگر remote واجد همه gateهاست، remote انتخاب می‌شود؛ اگر egress نیز بسته باشد، نتیجه باید REJECT باشد، نه silent degradation.

12. Stale binding: نسخه جدید مدل به qualification جدید نیاز دارد

فرض کن model version محلی عوض شده ولی qualification record هنوز به نسخه قبلی bind است. حتی اگر endpoint سالم باشد، latency خوب باشد و مدل همان نام را داشته باشد، candidate فعلی qualified محسوب نمی‌شود. اگر route جایگزین مجاز نداریم، تصمیم DEFER تا requalification قابل دفاع‌تر است.

13. Route provenance بخشی از خروجی است

خروجی فقط selected_route نیست. record باید policy version، request slice، candidate versionها، gate resultها، rejection reasonها و دلیل انتخاب نهایی را نگه دارد. بدون provenance، downstream فقط یک نام route می‌بیند و نمی‌تواند بفهمد چه evidenceای آن را مجاز کرده است.

14. Lab: هشت fixture deterministic

در Lab هشت حالت را اجرا می‌کنی: baseline remote fallback، local qualified/available، capability missing، egress blocked، stale qualification، latency breach، remote unavailable و transfer با local جدید ولی capability ناقص. evaluator باید hard gateها را قبل از preference اعمال کند و 8 state خروجی برای هر case بسازد.

15. Exit checklist و transfer

قبل از خروج بررسی کن: request contract نسخه‌دار است؛ qualification دقیق slice و version را پوشش می‌دهد؛ capability و egress hard gate هستند؛ unavailable/slow route eligible نمی‌شود؛ local preference فقط روی eligible set اجرا می‌شود؛ rejection reason و policy version ثبت می‌شوند. در transfer، egress_allowed=false و local جدید بدون structured output را از صفر دوباره ارزیابی کن؛ تصمیم قبلی را کپی نکن.