معماری چندکسب‌وکاری، تجاری و تجارت الکترونیک · فصل ۲ — ICP، Serviceability، Pilot، Workload و Admission · 231
Pilot Design و Stop/Pivot Criteria
معماری یا تصمیم تجاری را با preference و الگوهای آماده می‌گیرد و constraint/cost/serviceability را مدل نمی‌کند. موضوع جاری: «Pilot Design و Stop/Pivot Criteria». می‌تواند برای «Pilot Design و Stop/Pivot Criteria» یک تصمیم bounded با constraints، cost/risk و stop/pivot condition طراحی کند.
خلاصهٔ درس
معماری یا تصمیم تجاری را با preference و الگوهای آماده می‌گیرد و constraint/cost/serviceability را مدل نمی‌کند. موضوع جاری: «Pilot Design و Stop/Pivot Criteria».
می‌تواند برای «Pilot Design و Stop/Pivot Criteria» یک تصمیم bounded با constraints، cost/risk و stop/pivot condition طراحی کند.
خروجی این درس
می‌تواند برای «Pilot Design و Stop/Pivot Criteria» یک تصمیم bounded با constraints، cost/risk و stop/pivot condition طراحی کند.
1) Pilot ابزار تصمیم است، نه نسخهٔ کوچک Production
Pilot برای کم‌کردن عدم‌قطعیت دربارهٔ یک فرض پرریسک است؛ نه برای نمایش حجم کار، نه برای ساختن Backlog کوچک Production و نه برای توجیه ادامه فقط چون هزینه شده است. در این درس Pilot Hypothesis & Stop-Pivot Contract v1 ساخته می‌شود تا تصمیم نهایی به شواهد محدود بماند.
2) از پرریسک‌ترین فرض شروع کن
راهنمای Alpha در GOV.UK بر تست‌کردن پرریسک‌ترین فرض‌ها و ساختن فقط همان مقدار Prototype که برای تست ایده لازم است تأکید دارد. این را به یک گزارهٔ ابطال‌پذیر تبدیل کن: اگر اپراتورها از Workflow کمکی استفاده کنند، زمان Verification به زیر هدف می‌رسد بدون اینکه Guardrail بازبینی انسانی نقض شود.
3) Scope را تا حداقلِ قابل‌تست کوچک کن
فقط اجزایی را وارد Pilot کن که برای آشکارکردن همان فرض لازم‌اند. ظاهر کامل Authentication، Integrationهای گسترده، Billing، Migration و Production Hardening وارد Pilot نمی‌شوند مگر اینکه خودشان فرض پرریسک باشند. Scope بیشتر می‌تواند Sunk Cost را زیاد کند بدون اینکه Learning بیشتری بسازد.
4) Baseline را قبل از دیدن نتیجه Freeze کن
هر نتیجه به نقطهٔ مقایسه نیاز دارد. زمان فعلی Review، نرخ خطا/فرار فعلی و روش اندازه‌گیری باید پیش از شروع ثبت شوند. Baselineای که بعد از دیدن خروجی بازنویسی شود، مبنای تصمیم قابل‌دفاع نیست.
5) Primary Measure را از Guardrail جدا کن
Primary Measure می‌گوید منفعت مورد انتظار ایجاد شده یا نه. Guardrail می‌گوید این منفعت با مرز ایمنی قابل‌قبول به‌دست آمده یا نه. Verification سریع‌تر وقتی Safety/Error Boundary شکست خورده باشد موفقیت نیست؛ Guardrail حق وتو دارد.
6) Sample، Timebox و Decision Date را مرزبندی کن
دقیق بنویس چه کسانی/چه مواردی داخل Sample هستند، چه چیزهایی خارج‌اند، Pilot چقدر طول می‌کشد و چه روزی تصمیم گرفته می‌شود. Private Beta در GOV.UK از مشارکت محدود برای یادگیری و بهبود پیش از بازشدن گسترده‌تر استفاده می‌کند؛ MAKNOW این اصلِ bounded learning را می‌گیرد، نه عدد Sample یا Threshold آن را.
7) STOP، PIVOT و CONTINUE را از قبل Commit کن
Thresholdها قبل از دیدن داده نوشته می‌شوند. CONTINUE یعنی Hypothesis و Guardrail هر دو در مرز اعلام‌شده پاس شده‌اند. STOP یعنی Guardrail/ایمنی یا شرط غیرقابل‌بازیابی شکست خورده است. PIVOT یعنی مکانیزم فعلی رد شده اما یک تغییر مشخص و قابل‌تست ارزش آزمایش دارد. HOLD یعنی هنوز Evidence کافی نداریم.
8) تصمیم را از Sunk Cost محافظت کن
پولی که قبلاً خرج شده Evidence ادامهٔ Pilot نیست. Contract باید در Decision Date بدون دانستن میزان تلاش تیم قابل‌خواندن باشد. اگر Criterion فقط به‌خاطر ناامیدکننده‌بودن نتیجه تغییر می‌کند، از ابتدا Precommitment واقعی نبوده است.
9) Production Claim را جدا نگه دار
Pilot می‌تواند Learning موفقی تولید کند اما هنوز برای Production نامناسب باشد. Security، Reliability، Capacity، Compliance، Operations، Cost و Release Ownership ممکن است اثبات نشده باشند. CONTINUE در این درس یعنی ادامهٔ مسیر bounded learning؛ نه «انتشار در Production».
10) Baselineِ Pilot Hypothesis & Stop-Pivot Contract
| Pilot | Assumption | Hypothesis | Minimum Scope | Baseline | Primary Measure | Guardrail | Sample Boundary | Timebox | Decision Date | Stop | Pivot | Continue | Production Claim | Evidence |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| PILOT-AI-VERIFY-01 | operators can verify AI-assisted outputs within target time without safety degradation | median verification <=60s AND unsafe escape <=2% | one workflow; trained operators; synthetic/non-sensitive cases | median verification 90s; unsafe escape 1.5% | median verification seconds <=60 | unsafe escape rate <=2% | 120 cases; 6 trained operators; one workflow | 4 weeks | 2026-10-15 | guardrail >2% or severe safety event | primary >60s with guardrail <=2% and a defined integration/process change is testable | primary <=60s AND guardrail <=2% with complete evidence | forbidden; separate production-readiness gate required | SYN-PILOT-BASELINE |
سؤال Baseline فقط یکی است: آیا اپراتور می‌تواند Output کمکی را حداکثر در 60 ثانیه Verify کند و نرخ Unsafe Escape حداکثر 2٪ بماند؟ Pilot چهار هفته است، Sample Boundary مشخص است و Decision Date قبل از اجرا قفل می‌شود.
11) میان‌بُر غلط: Primary بهتر شده ولی Guardrail شکست خورده
فرض کن Median Verification Time از 90 ثانیه به 48 ثانیه رسیده اما Unsafe Escape به 5٪ افزایش یافته است. Primary Metric بهتر شده، ولی Guardrail شکست خورده است. تصمیم bounded برابر STOP است، نه ساختن یک Average Score دلخواه برای اعلام موفقیت.
12) تغییر Scope و Threshold قرارداد اصلی را بی‌اعتبار می‌کند
اگر تیم بعد از Kickoff Scope را بزرگ کند اما Hypothesis را دوباره Bind نکند، Evidence به PARTIAL می‌رود. اگر بعد از دیدن نتیجه Success Threshold را عوض کند، وضعیت DISPUTED می‌شود. Pilot با Rules متحرک قابل Audit نیست.
13) Lab: هشت Fixture و 64 Assertion
Lab کاملاً Offline است و Baseline Continue، Guardrail Stop، Pivot قابل‌بازیابی، Scope Mutation، Missing Evidence، Post-hoc Threshold، Stale Evidence و Transfer پس از Integration را می‌سنجد. برای هر Fixture هشت خروجی قابل‌سنجش چک می‌شود و هیچ API Key یا Tenant زنده لازم نیست.
14) Transfer: Integration بعد از Guardrail Breach زمان Review را کم می‌کند
تصمیم را از Evidence جدید دوباره بساز. اگر Integration زمان Verification را به 44 ثانیه و نرخ Safety را به 1.5٪ برساند و Sample/Threshold همان مرز اعلام‌شده باقی بماند، نتیجهٔ bounded می‌تواند دوباره CONTINUE شود. شکست قبلی پاک نمی‌شود؛ تصمیم جدید Evidence جدید دارد.
15) چک‌لیست تحویل
یک Risky Assumption صریح است؛ Minimum Scope محدود است؛ Baseline و Measurement Method قبل از نتیجه Freeze شده‌اند؛ Primary و Guardrail جدا هستند؛ Sample/Timebox/Decision Date مشخص‌اند؛ STOP/PIVOT/CONTINUE از قبل تعریف شده‌اند؛ Evidence ناقص، stale، disputed یا تغییرکرده پنهان نمی‌شود؛ Transfer از نو محاسبه می‌شود؛ و هیچ نتیجهٔ Pilot به‌عنوان Production Readiness معرفی نمی‌شود.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
ARC-012-Q1 retrieval
Explain the owned boundary of Pilot Hypothesis & Stop-Pivot Contract v1 and name one adjacent non-goal.
ARC-012-Q2 application
Build the contract for the baseline four-week operator-verification pilot.
ARC-012-Q3 diagnosis
The primary metric improves while the safety guardrail fails. State the bounded decision and the evidence that controls it.
ARC-012-Q4 transfer
A new integration reduces review time after an earlier guardrail breach. Recompute STOP/PIVOT/CONTINUE/HOLD from the new evidence without making a production claim.
ملاک‌های ارزیابی (rubric)
- Boundary: ARC-012 owns the pilot hypothesis and stop/pivot contract; ARC-013 workload cataloging remains out of scope.
- Precommitment: baseline, primary, guardrail, sample/timebox and decision criteria are recorded before interpreting results.
- Negative evidence: a guardrail breach, missing evidence, stale evidence, scope mutation or post-hoc threshold change remains visible.
- Bounded decision: STOP/PIVOT/CONTINUE/HOLD is no stronger than the evidence and never implies production readiness.
- Transfer: the changed integration case is recomputed from new evidence rather than copied from the baseline.
منابع و تازگی
مطالعهٔ موارد (case studies)
تصاویر درس
فایل‌های آزمایشگاه
به‌صورت Offline دستور python run_checks.py را اجرا کنید. هشت Fixture مصنوعی را بررسی کنید و توضیح دهید چرا با شکست Guardrail، تغییر Scope، Evidence ناقص/stale یا تغییر Threshold پس از دیدن نتیجه، State عوض می‌شود. CONTINUE را Production Readiness تلقی نکنید.