داشبورد تیم سبز است: پوشش تست ۸۵٪، همهٔ User Storyها دارای Acceptance Criteria، خودکارسازی رگرسیون ۷۰٪ و پیچیدگی کد زیر ۱۰ است. دو انتشار بعد هم نقصهای بحرانی پروداکشن از ۱۰ به ۴ رسیدهاند. آیا این اعداد ثابت میکنند چهار معیار اول «شاخص پیشرو» بودهاند و باعث کاهش نقص شدهاند؟ نه. فعلاً فقط چند مشاهده، یک ترتیب زمانی و یک همزمانی داریم؛ نه تعریف پایدار، نه آزمون قدرت پیشبینی و نه شاهد علّی.
شاخص پیشرو و پسرو در QA برچسب ذاتی یک متریک نیست. یک معیار فقط نسبت به پیامد مشخص، جمعیت، افق زمانی و تصمیم مشخص پیشرو یا پسرو میشود. حتی یک معیار DORA میتواند نسبت به شیوههای توسعه «پسرو» و نسبت به عملکرد سازمانی «پیشرو» باشد. بنابراین پرسش حرفهای این نیست که «لیست Leading Indicatorهای تست چیست؟»؛ پرسش این است: «کدام فرضیهٔ Indicator برای این تصمیم، در این دامنه و تا این تاریخ اعتبار کافی دارد؟»
پاسخ کوتاه: Leading بودن یک ادعای قابلآزمون است، نه نامی که روی Coverage، Automation یا Code Review میگذاریم. تقدم زمانی لازم است؛ اما تا وقتی تعریف، سازوکار، Baseline، دادهٔ اعتبارسنجی، خطاهای هشدار، Lead time قابلاقدام و سیاست تصمیم ثبت نشدهاند، آن معیار فقط Candidate Indicator است.
این راهنما دقیقاً چه مسئلهای را حل میکند؟
این راهنما برای QA Lead، Test Manager، مهندس کیفیت، Product Manager و تحلیلگری است که میخواهد از معیارها برای دیدن ریسک آینده استفاده کند، بدون آنکه از همبستگی، داستان علّی بسازد. خروجی کار یک نمودار زیبا نیست؛ یک Indicator Hypothesis نسخهدار و قابلابطال است که معلوم میکند چه چیزی را، برای کدام تصمیم، با چه خطایی و تا چه زمانی میتوان استفاده کرد.
اگر به فهرست و تعریف متریکها نیاز دارید، راهنمای متریکهای تست نرمافزار مالک آن موضوع است. اگر سؤال شما تشخیص Noise از Signal در سری زمانی است، به تحلیل روند معیارهای تست بروید. این صفحه فقط رابطهٔ فرضی «Indicator زودتر ← Outcome دیرتر» و اعتبار تصمیمی آن را مالک میشود.
تعریف عملی شاخص پیشرو و پسرو
| نوع | تعریف محدود | آنچه ثابت نمیکند |
|---|---|---|
| Leading Indicator | اندازهای که پیش از Outcome مرجع مشاهده میشود و برای پیشبینی یا اقدام زودهنگام، در دامنه و افق تعریفشده اعتبارسنجی شده است | علت Outcome، تضمین پیشگیری یا اعتبار دائمی |
| Lagging Indicator | اندازهای که Outcome یا پیامد تحققیافته را در Cutoff تعریفشده ثبت یا تأیید میکند | بیفایده، ذاتاً دیرهنگام یا صرفاً واکنشی بودن |
| Candidate Indicator | معیاری با سازوکار محتمل و تقدم زمانی که هنوز قدرت پیشبینی آن تأیید نشده است | اجازهٔ تصمیم خودکار یا ادعای «پیشبینیکننده» |
عبارت «پیش از Outcome» نسبی است. زمان شکست یک تست، نسبت به Commit قبلی یک Outcome پسرو است؛ همان شکست نسبت به تصمیم انتشار فردا میتواند یک ورودی زودهنگام باشد. جایگاه زمانی بهتنهایی آن را پیشبینیکننده نمیکند؛ باید معلوم شود این ورودی با چه دقتی و چند ساعت یا چند روز زودتر به تصمیم کمک میکند.
چرا برچسب Leading یا Lagging ذاتی نیست؟
راهنمای رسمی DORA Metrics نمونهٔ روشنی ارائه میکند: معیارهای تحویل نرمافزار میتوانند برای عملکرد سازمان و بهزیستی کارکنان نقش Leading داشته باشند، اما نسبت به شیوههای توسعه و تحویل، Lagging باشند. این مثال یک نکتهٔ بنیادی را روشن میکند: Indicator یک رابطه است، نه ویژگی دائمی ستون دیتابیس.
| معیار مشاهدهشده | Outcome مرجع | نقش احتمالی | وضعیت درست پیش از اعتبارسنجی |
|---|---|---|---|
| Test failure در Build B42 | تغییر کد همان Build | پسرو؛ پیامد تغییر و اجرای تست | Observed Outcome |
| Test failure در Build B42 | Rollback پس از انتشار B42 | نامزد پیشرو | Candidate، نه Prediction |
| نقص پروداکشن نسخهٔ ۷ | کیفیت نسخهٔ ۷ | پسرو | Outcome Measure |
| نقص پروداکشن نسخهٔ ۷ | ریسک تکرار در نسخهٔ ۸ | نامزد پیشرو | نیازمند تعریف Cohort و Horizon |
| زمان Code Review | تاخیر همان Pull Request | پسرو | Process Outcome |
| زمان Code Review | نقص Escape شدهٔ انتشار بعد | نامزد پیشرو با رابطهٔ احتمالاً غیرخطی | Hypothesis |
پنج جزء اجباری هر برچسب Indicator
- Outcome: دقیقاً کدام پیامد دیرتر قرار است پیشبینی یا تأیید شود؟
- Population: رابطه برای کدام سرویس، Journey، Build، تیم، نوع تغییر یا Cohort ادعا میشود؟
- Horizon: چند ساعت، روز، Sprint یا Release جلوتر؟
- Decision: مشاهدهٔ Indicator قرار است چه تصمیمی را تغییر دهد؟
- Validity window: اعتبار از چه نسخه و تاریخی شروع میشود و چه زمانی باید بازبینی شود؟
جملهٔ «Coverage یک Leading Indicator کیفیت است» هر پنج جزء را حذف میکند. صورت قابلآزمونتر چنین است: «برای تغییرات جدید سرویس تسویه در Buildهای واجدشرایط، نسبت پوشش Branch مسیرهای پرریسک در هفت روز پیش از Cutoff، نامزد پیشبینی وجود حداقل یک Reconciliation mismatch تأییدشده تا ۱۴ روز پس از انتشار است؛ نتیجه فقط برای تصمیم ورود به Shadow Pilot استفاده میشود.» این جمله هنوز حقیقت نیست، اما دستکم قابلردشدن است.
Metric، Measure، Indicator، Target و Signal یکی نیستند
| واژه | کارکرد | مثال محدود |
|---|---|---|
| Measure | مشاهده یا مقدار خام با واحد | ۲۴ Failure در Run R42 |
| Metric | قاعدهٔ محاسبه روی جمعیت و Window تعریفشده | Failure rate بر Attemptهای واجدشرایط |
| Indicator | Metric تفسیرشده نسبت به Outcome و Decision | نامزد هشدار ریسک Rollback طی ۷ روز |
| Target | سطح مطلوب یا تعهد مدیریتی | کمتر از ۲٪؛ نه Control Limit و نه Forecast |
| Threshold | مرز ورود به Action policy | دو Observation متوالی بالاتر از مقدار ثبتشده |
| Signal | الگوی غیرعادی طبق Rule ازپیشتعریفشده | Trigger برای Investigation؛ نه اثبات Cause |
| Outcome | پیامد مرجع با Cutoff و قرارداد خودش | Rollback تأییدشده تا هفت روز پس از Release |
ممکن است Metric از Target عبور کند ولی Signal آماری نباشد؛ یا Signal رخ دهد اما هنوز Outcome آینده را خوب پیشبینی نکند. همچنین Threshold عملیاتی لزوماً بهترین مرز آماری نیست؛ انتخاب آن باید هزینهٔ False alert و False miss را منعکس کند.
Activity، Output، Intermediate Outcome و Outcome نهایی
بسیاری از «Leading Indicator»های رایج فقط Activity هستند: تعداد جلسه، ساعت تست، تعداد Test Case یا درصد خودکارسازی. Activity میتواند ورودی یک Theory of Change باشد، اما رابطهٔ آن با Outcome باید توضیح داده و آزموده شود. زنجیرهٔ ساده چنین است:
| لایه | نمونهٔ Checkout ساختگی | خطر تفسیر |
|---|---|---|
| Input | زمان و محیط تست Stub | منبع بیشتر مساوی کیفیت بیشتر نیست |
| Activity | اجرای سناریوی Callback تکراری | اجرا، Evidence پذیرفتهشده نیست |
| Output | Evidence معتبر برای سه Retry pattern | Coverage محدود، نبود نقص را ثابت نمیکند |
| Intermediate outcome | کشف mismatch پیش از انتشار | کشف بیشتر میتواند نتیجهٔ مشاهدهپذیری بهتر باشد |
| Final outcome | کاهش mismatch تأییدشده پس از انتشار | عوامل همزمان و تغییر جمعیت باید کنترل شوند |
Magenta Book دولت بریتانیا در بحث Theory of Change بر زنجیرهٔ علّی مورد انتظار، فرضها، شواهد پشتیبان، Context و پیامدهای میانی تأکید میکند. این منبع قالب QA ارائه نمیدهد؛ ما فقط اصل «سازوکار را آشکار و قابلآزمون کن» را برای طراحی فرضیهٔ Indicator اقتباس میکنیم.
تقدم زمانی لازم است، اما کافی نیست
اگر X پس از Y ثبت شود، X نمیتواند Y را پیشبینی کند؛ پس Temporal precedence یک Entry criterion است. اما X قبل از Y نیز ممکن است کاملاً بیربط باشد، با یک عامل سوم حرکت کند یا فقط از تغییر تعریف داده خبر دهد. مثال: افزایش Automation rate پیش از کاهش نقص ممکن است همزمان با کوچکشدن Scope، تعویض تیم، بهترشدن Observability یا تغییر روش شمارش Defect رخ داده باشد.
- Before: فقط ترتیب زمانی را نشان میدهد.
- Associated: حرکت آماری مشترک را در دادهٔ تعریفشده نشان میدهد.
- Predictive: روی دادهٔ ندیدهشده و Horizon مشخص، برای تصمیم ارزش دارد.
- Causal: تغییر X در شرایط تعریفشده واقعاً Y را تغییر میدهد؛ ادعایی قویتر و نیازمند طراحی مناسب.
Early Metric با Leading Indicator چه تفاوتی دارد؟
Early Metric زود در چرخه قابلمشاهده است؛ Leading Indicator علاوه بر زودبودن باید برای Outcome مرجع قدرت پیشبینی قابلاستفاده داشته باشد. «درصد Storyهای دارای Acceptance Criteria در Refinement» یک Early Process Metric است. تا وقتی نشان ندادهایم تغییر این درصد، با تعریف ثابت، پیش از Rework یا Defect بعدی ظاهر میشود و برای انتخاب اقدام مفید است، نام درست آن Candidate Indicator است.
سه نقش متفاوت: Driver، Confirmation و Guardrail
یک Portfolio متعادل همهچیز را Leading/Lagging نمینامد. Driver متریکی است که تیم انتظار دارد با Intervention تغییر کند؛ Confirmation Outcome تحققیافته را میسنجد؛ Guardrail آسیب جانبی یا بازیدادن سیستم را آشکار میکند. ممکن است یک Driver هنوز Indicator معتبر نباشد و فقط برای یادگیری در Pilot رصد شود.
| نقش | پرسش | نمونه |
|---|---|---|
| Driver candidate | چه چیزی را زودتر میتوان تغییر داد؟ | Coverage مسیرهای Risk-tagged، نه کل کد |
| Outcome confirmation | پیامد موردنظر واقعاً چه شد؟ | Mismatch تأییدشده بر جمعیت ثابت |
| Guardrail | برای بهترشدن عدد چه آسیبی ممکن است پنهان شود؟ | Flaky rate، زمان بازخورد، Escaped risk |
| Data-health | آیا خود اندازهگیری سالم است؟ | Missing، Duplicate، Late، Join failure |
| Context | چه تغییر بیرونی بر رابطه اثر گذاشت؟ | Runner version، Scope، Traffic mix |
چرخهٔ Indicator Hypothesis
چرخهٔ پیشنهادی این مقاله چنین است: Decision و Outcome → Theory/Mechanism → Candidate → Temporal contract → Metric/Data contract → Baseline → Validation → Action policy → Shadow use → Revalidation → Retire یا Correct. این چرخه تلفیق تحلیلی همین راهنماست و قالب رسمی DORA، GOV.UK یا NIST محسوب نمیشود.
Indicator lifecycle states
DRAFT → CANDIDATE → DATA_READY → VALIDATION_READY → SHADOW_VALIDATED
→ DECISION_APPROVED → ACTIVE → UNDER_REVIEW → RETIRED
↘ CORRECTED / REJECTED
Forbidden shortcuts:
CANDIDATE ≠ PREDICTIVE
ASSOCIATED ≠ CAUSAL
ACTIVE ≠ PERMANENT
RETIRED ≠ DELETE_HISTORY
گام اول: تصمیم را پیش از متریک بنویسید
«بهبود کیفیت» تصمیم نیست. تصمیم باید گزینه، Authority، Deadline و Evidence need داشته باشد: آیا Checkout جدید وارد Shadow traffic شود؟ آیا Verification اضافی برای تغییرات High-risk لازم است؟ آیا فرضیه برای یک Cycle دیگر تمدید شود؟ اگر با تغییر Indicator هیچ Action متفاوتی رخ نمیدهد، ساخت آن احتمالاً هزینهٔ گزارشدهی بدون ارزش تصمیمی است.
decision_id: DEC-SYN-042 question: "آیا فرضیه برای یک Shadow Pilot سیروزه پذیرفته شود؟" options: [REJECT, SHADOW_PILOT, REDESIGN] authority_role: ROLE-QUALITY-DECISION decision_due: 2026-09-01T09:00:00Z required_evidence: [indicator-contract, validation-report, error-costs] not_deciding: [release, risk-acceptance, production-change]
گام دوم: Outcome را مثل یک متریک مستقل قرارداد کنید
Outcome مبهم، Leading Indicator کاذب تولید میکند. «باگ پروداکشن» باید نوع Defect، منبع تأیید، Severity vocabulary، واحد جمعیت، Attribution window، Duplicate policy، Reopen و Cutoff داشته باشد. اگر Outcome از Release به Release تغییر تعریف دهد، رابطهٔ تاریخی قابلمقایسه نیست.
outcome_ref: OUT-SYN-RECON-v3 subject: "reconciliation mismatch confirmed by synthetic oracle" population: eligible fake PaymentAttempt per release cohort unit: confirmed mismatch / 1,000 eligible attempts window: release_at → release_at + 14d cutoff_rule: event_time <= cutoff; late events provisional exclusions: corrupted fixture, unknown build, duplicate event not_claimed: real payments, customer harm, financial impact
گام سوم: Theory و Mechanism را قابلردشدن کنید
Mechanism توضیح میدهد چرا انتظار داریم Indicator قبل از Outcome حرکت کند. برای مثال: «نقض قرارداد Callback در تست Stub، اگر همان State transition و Idempotency rule محصول را پوشش دهد، ممکن است الگوهای مستعد mismatch را پیش از انتشار آشکار کند.» سپس باید شرایط شکست Theory را نوشت: Stub با Production contract فاصله دارد؛ تستها فقط Happy path را میبینند؛ Outcome از خطای عملیاتی میآید؛ یا تغییر Observability فقط کشف را بیشتر کرده است.
نوشتن Negative Theory از خوشبینی جلوگیری میکند: چه شرایطی باعث میشود Indicator بهتر شود ولی Outcome بدتر بماند؟ چه عاملی هر دو را همزمان تغییر میدهد؟ کدام مشاهده سازوکار را رد خواهد کرد؟ اگر پاسخ «هیچچیز» باشد، فرضیه علمی و مدیریتی نیست؛ روایت غیرقابلابطال است.
گام چهارم: Candidate Indicator را انتخاب کنید
Candidate را به دلیل دسترسبودن داده انتخاب نکنید. از Outcome به عقب برگردید: چه تغییر قابلمشاهدهای در زنجیرهٔ سازوکار، پیش از پیامد رخ میدهد؟ آیا تیم فرصت و Authority اقدام دارد؟ آیا اندازهگیری قابلاعتماد است؟ آیا Indicator با یک Countermetric همراه میشود؟
- به Outcome نزدیک باشد، اما آنقدر دیر نباشد که زمان اقدام از دست برود.
- برای Population مشخص قابلمحاسبه و قابلتکرار باشد.
- با تغییر رفتار نمایشی یا Gaming بهسادگی سبز نشود.
- به تصمیمی متصل باشد که تیم واقعاً مجاز به اجرای آن است.
- هزینهٔ جمعآوری، بررسی و خطا با ارزش تصمیم متناسب باشد.
گام پنجم: Lead horizon و Actionable lead time
Lead horizon میگوید Outcome چند وقت بعد ارزیابی میشود؛ Actionable lead time فاصلهٔ واقعی میان آمادهشدن Indicator و آخرین زمان مفید برای اقدام است. اگر داده سه روز دیر Ingest شود و تصمیم چهار ساعت بعد لازم باشد، Indicator از نظر تقویمی زودتر است اما از نظر عملیاتی پیشرو نیست.
| زمان | معنا | خطای رایج |
|---|---|---|
| event_time | رخداد واقعاً چه زمانی اتفاق افتاد؟ | جایگزینی با زمان ورود به داشبورد |
| observed_at | سیستم اندازهگیری چه زمانی دید؟ | نادیدهگرفتن Out-of-order |
| ingested_at | چه زمانی وارد Pipeline شد؟ | پنهانکردن تأخیر جمعآوری |
| computed_at | Indicator چه زمانی محاسبه شد؟ | محاسبهٔ جدید روی Snapshot قدیمی |
| decision_due | آخرین زمان تصمیم چه بود؟ | نامیدن گزارش دیررس بهعنوان Leading |
| outcome_cutoff | Outcome تا چه زمانی بالغ میشود؟ | برچسب صفر به Caseهای هنوز باز |
قرارداد کامل Indicator Hypothesis
indicator_review_id: IND-042-v1 decision_ref: DEC-SYN-042 outcome_ref: OUT-SYN-RECON-v3 candidate_metric_ref: M-CALLBACK-CONTRACT-v2 population_ref: POP-SYN-CHECKOUT-v4 mechanism: "contract violation may precede reconciliation mismatch" expected_direction: positive expected_shape: not assumed; compare preregistered bins lead_horizon: 14d minimum_actionable_lead: 48h confounders: [fixture-version, scope-mix, runner-version, oracle-change] countermetrics: [join-failure-rate, flaky-rate, feedback-latency] validation_plan_ref: VAL-042-v1 action_policy_ref: ACT-042-v1 not_claimed: [causality, release-readiness, product-quality, real-user-risk] owner_role: ROLE-METRIC-STEWARD review_due: 2026-10-01T09:00:00Z correction_policy: supersede; never silent-edit
Metric Contract را از Indicator Contract جدا کنید
Metric Contract فقط محاسبه را پایدار میکند: واحد تحلیل، Eligibility، Numerator، Denominator، Window، Join، Dedup، Missing و Version. Indicator Contract تفسیر آن Metric نسبت به Outcome و Decision را نگه میدارد. یک Metric پایدار میتواند در چند فرضیه استفاده شود؛ تغییر تفسیر نباید بیصدا فرمول را عوض کند.
| Metric Contract | Indicator Contract |
|---|---|
| چه چیزی و چگونه محاسبه میشود؟ | نسبت به کدام Outcome چه ادعایی داریم؟ |
| Population، unit، numerator، denominator | Decision، horizon، mechanism، expected relation |
| Missing، duplicate، late، join | Validation، error costs، threshold، action |
| Version و Source lineage | Validity window، revalidation، retirement |
جهت رابطه و شکل رابطه را حدس نزنید
«بیشتر بهتر است» اغلب نادرست است. Review time بسیار کم میتواند نشانهٔ مرور سطحی باشد و بسیار زیاد میتواند از Scope بزرگ یا Bottleneck خبر دهد. Coverage ممکن است پس از حدی بازده نزولی داشته باشد. Automation rate میتواند بالا برود چون Caseهای سخت حذف شدهاند. جهت، شکل خطی/آستانهای/U شکل و Lag باید پیش از دیدن نتیجه ثبت یا دستکم صریحاً Exploratory اعلام شود.
Population و هویتها را ثابت نگه دارید
اگر Indicator روی Test Case محاسبه شود و Outcome روی Release، Join rule باید مشخص کند کدام Case به کدام تغییر و Release تعلق دارد. مقایسهٔ یک ماه از Attemptهای ریز با ماه بعد از Suiteهای درشت، Simpson’s paradox و تغییر ترکیب جمعیت میسازد. حداقل هویتهای Subject، Change، Build، Run، Environment، Data snapshot و Outcome cohort را نگه دارید.
Data Snapshot پیش از مدل و نمودار
هر Validation باید به Snapshot تغییرناپذیر متصل شود: Extract time، Event cutoff، Query digest، Source version، تعداد Eligible، Missing، Duplicate، Late، Quarantined و Join failure. Missing هرگز خودکار صفر نیست. اگر Outcome هنوز بالغ نشده، رکورد Censored یا Provisional است؛ نباید آن را «بدون نقص» شمرد.
snapshot_id: SNAP-SYN-042 event_cutoff: 2026-08-01T00:00:00Z extract_at: 2026-08-03T09:00:00Z query_digest: sha256:fictional-demo-only source_versions: [runner-v5, oracle-v3, registry-v4] eligible: 240 missing: 3 duplicates_quarantined: 4 late_provisional: 6 join_failures: 2 fitness: HOLD_IF join_failure_rate > 0.02 limitations: synthetic, offline, non-representative
Baseline برای رابطه است، نه فقط مقدار
Baseline Indicator باید دورهای را پوشش دهد که تعریف Candidate و Outcome پایدار بودهاند. فقط میانگین Coverage گذشته کافی نیست؛ توزیع مشترک Indicator، Outcome، Lag و Context لازم است. تغییر Runner، Oracle، Scope یا Defect taxonomy در میانهٔ Baseline باید Annotate، Segment یا Exclude شود و تصمیم آن ثبت بماند.
Retrospective validation و Prospective validation
| طراحی | کاربرد | محدودیت |
|---|---|---|
| Retrospective | غربال Candidateها با دادهٔ تاریخی | تعریفهای ناپایدار، Leakage و انتخاب پس از دیدن نتیجه |
| Prospective shadow | ثبت Prediction پیش از Outcome بدون تغییر تصمیم واقعی | زمانبر؛ هنوز اثر Intervention را ثابت نمیکند |
| Controlled experiment | سنجش اثر تغییر Process بر Outcome | نیازمند طرح، توان، اخلاق و کنترل مناسب |
| Natural/quasi-experiment | وقتی Randomization ممکن نیست | فرضهای قوی و Confounding باقی میماند |
دادهٔ تاریخی برای ساخت فرضیه مفید است، اما انتخاب Candidate و Threshold روی همان داده و سپس گزارش عملکرد روی همان نمونه، خوشبینی ایجاد میکند. بهترین شروع عملی معمولاً یک دورهٔ Shadow است: Prediction و Action پیشنهادی پیش از Cutoff ثبت میشوند، اما Authority واقعی هنوز به آن Indicator واگذار نمیشود.
زمان را در Train، Validation و Holdout حفظ کنید
برای Indicator زمانی، Split تصادفی ممکن است اطلاعات آینده را به گذشته نشت دهد. Windowهای قدیمیتر برای کشف و تنظیم، Window بعدی برای Validation و تازهترین Window دستنخورده برای Holdout مناسبترند. اگر یک Release در چند ردیف تکرار شده، همهٔ ردیفهای آن باید در یک Split بمانند.
- Threshold را پس از دیدن Holdout تغییر ندهید و همان عملکرد را مستقل ننامید.
- Outcomeهای هنوز بالغنشده را از Negative واقعی جدا کنید.
- Featureهایی که فقط پس از Outcome در دسترساند حذف کنید.
- نسخهٔ Query، کد و Seed ساختگی را ثبت کنید.
- چند Candidate آزمودهشده و Selection process را پنهان نکنید.
R² بالا یا همبستگی زیبا کافی نیست
راهنمای NIST دربارهٔ اعتبارسنجی مدل صریحاً هشدار میدهد که R² بالا تضمین نمیکند مدل بهخوبی با داده سازگار است و Residual analysis را ابزار اصلی بررسی برازش معرفی میکند. این صفحه دربارهٔ مدلسازی فرایند است، نه نسخهٔ آماده برای QA؛ کاربرد محدود ما این است که هیچ Summary statistic واحدی را «اعتبار Indicator» ننامیم.
رابطه باید در دادهٔ ندیدهشده، Segmentهای معنادار و Window زمانی آینده بررسی شود. Residual، Drift، Missingness، Seasonality و Base rate را ببینید. نتیجهٔ «از ۱۰ به ۴» با دو نقطه نه Trend معتبر است، نه Calibration، نه دلیل استراتژی درست.
اعتبار پیشبینی را با یک سبد آزمون بسنجید
| آزمون | پرسش | مرز تفسیر |
|---|---|---|
| Temporal precedence | Indicator پیش از Decision و Outcome آماده بود؟ | فقط شرط زمانی |
| Association | رابطهٔ مشاهدهشده با روش و عدمقطعیت چیست؟ | علت نیست |
| Discrimination | Caseهای Outcome و non-Outcome را چقدر جدا میکند؟ | احتمالها را کالیبره نمیکند |
| Calibration | ریسک پیشبینیشده با فراوانی مشاهدهشده سازگار است؟ | در یک Segment ممکن است خوب و در دیگری بد باشد |
| Lead-time distribution | چقدر زودتر و با چه پراکندگی هشدار میدهد؟ | میانگین، Tail را پنهان میکند |
| Stability | در Window/Version/Segment بعدی میماند؟ | اعتبار دائمی نیست |
| Decision utility | پس از هزینهٔ خطا، Action بهتری میسازد؟ | دقت آماری مساوی ارزش عملیاتی نیست |
Sensitivity، Specificity و Precision به زبان تصمیم
وقتی Indicator هشدار دودویی میدهد، جدول چهارخانه بسازید. Sensitivity/Recall میپرسد چه سهمی از Outcomeهای واقعی زودتر هشدار داشتهاند. Specificity میپرسد چه سهمی از non-Outcomeها بیهشدار ماندهاند. Precision میپرسد از هشدارهای صادرشده، چند مورد واقعاً به Outcome منتهی شدهاند.
| Outcome رخ داد | Outcome رخ نداد | |
|---|---|---|
| Alert صادر شد | True positive | False alert |
| Alert صادر نشد | False miss | True negative |
Base rate اهمیت دارد. اگر Outcome بسیار نادر باشد، حتی Indicator با Sensitivity و Specificity ظاهراً مناسب میتواند Precision پایین و هشدارهای بیثمر فراوان داشته باشد. به همین دلیل «۹۰٪ Accuracy» بدون Confusion matrix، جمعیت و هزینهٔ خطا برای تصمیم کافی نیست.
Lead-time distribution را به یک میانگین تقلیل ندهید
میانهٔ Lead time شاید ۷۲ ساعت باشد، اما ۲۵٪ هشدارها پس از Deadline تصمیم برسند. P10/P50/P90، نسبت هشدارهای actionable و تأخیر Data pipeline را گزارش کنید. یک Indicator با Precision کمی پایینتر ولی ۴۸ ساعت فرصت پایدار، ممکن است از Indicator دقیقتری که پنج دقیقه پیش از Outcome هشدار میدهد ارزشمندتر باشد.
Calibration و Discrimination دو سؤال جدا هستند
Discrimination رتبهبندی ریسک را میسنجد: آیا موارد پرریسک بالاتر از کمریسک قرار میگیرند؟ Calibration دربارهٔ مقدار احتمال است: وقتی مدل ۳۰٪ میگوید، آیا تقریباً ۳۰٪ آن گروه Outcome دارند؟ اگر خروجی فقط رنگ قرمز/سبز است، ادعای Calibration probability نکنید. اگر نمونه کوچک است، بازهٔ عدمقطعیت و گروهبندی ازپیشتعریفشده لازم است.
هزینهٔ False alert و False miss متقارن نیست
False alert ممکن است Review اضافی، تأخیر یا Alert fatigue ایجاد کند؛ False miss ممکن است فرصت بررسی یک ریسک مهم را از بین ببرد. هزینه را با عدد ساختگی دقیق جلوه ندهید. میتوانید رتبه، بازه یا سناریوی شفاف ثبت کنید و Authority کسبوکار/فنی را در تعیین Trade-off دخیل سازید.
action_policy: ACT-042-v1 IF alert=true AND data_fitness=PASS AND actionable_lead>=48h THEN request focused evidence review ELSE keep UNKNOWN/HOLD; do not infer safety false_alert_response: review threshold and burden; preserve history false_miss_response: incident review independent of indicator status automatic_release_block: false automatic_people_score: false authority_role: ROLE-QUALITY-DECISION
Threshold باید به Action policy متصل باشد
Threshold بدون Action فقط رنگ است. برای هر سطح بنویسید چه کسی چه اقدامی را تا چه زمانی انجام میدهد، چه Evidence تازهای لازم است، چه چیزی خودکار نیست و چه شرایطی Alert را منقضی میکند. «قرمز = انتشار ممنوع» نباید از دل داشبورد و بدون Authority، Scope و Risk decision بیرون بیاید. تصمیم انتشار همچنان باید در چارچوب مستقلی مانند تصمیم کیفیت بهاندازهٔ کافی خوب انجام شود.
Association را Cause اعلام نکنید
اگر Coverage بالا رفت و Defect کم شد، حداقل توضیحهای جایگزین را ثبت کنید: Scope سادهتر، کاهش Traffic، تغییر Severity، بهبود Review، حذف Code قدیمی، Detection lag یا تغییر Defect intake. Association میتواند برای Prediction مفید باشد حتی اگر Cause شناخته نشده باشد؛ اما Action روی یک Proxy غیرعلّی ممکن است Outcome را تغییر ندهد.
برای ادعای اثر، Experiment یا Contribution Evaluation لازم است
پرسش «آیا Indicator پیشبینی میکند؟» با «آیا Intervention ما Outcome را بهتر کرد؟» متفاوت است. دومی به طراحی آزمایش و بهبود مستمر مبتنی بر Experiment یا، در سیستم چندعاملی، به Contribution Evaluation در QA نیاز دارد. پایینآمدن Lagging metric بهتنهایی اثر برنامهٔ QA را ثابت نمیکند.
Confounder، Mediator و Countermetric را جدا کنید
| نوع متغیر | نقش | نمونهٔ ساختگی |
|---|---|---|
| Confounder | هم Candidate و هم Outcome را تغییر میدهد | کوچکشدن Scope تغییرات |
| Mediator | بخشی از مسیر سازوکار است | کشف زودتر mismatch پس از اجرای سناریوی جدید |
| Moderator | قدرت رابطه را در Segmentها تغییر میدهد | تغییرات High-risk در برابر Low-risk |
| Countermetric | آسیب یا Gaming را آشکار میکند | Flaky rate همراه Automation rate |
| Data-health metric | سلامت مشاهده را میسنجد | Join failure و Late-event rate |
کنترل مکانیکی همهٔ متغیرها درست نیست؛ اگر Mediator را بهعنوان Confounder حذف کنید، بخشی از مسیر واقعی را میبندید. Diagram سادهٔ فرضی، زمانبندی و نظر Domain expert کمک میکند نقشها پیش از تحلیل روشن شوند.
Coverage یک Candidate است، نه تضمین کاهش باگ
Code coverage فقط نشان میدهد کدام ساختار در یک اجرای مشخص لمس شده است؛ کیفیت Assertion، Oracle، Data، Interaction و Risk coverage را تضمین نمیکند. تعریف دقیق Branch/Condition/Path، Scope کد، Generated code، Build و Test suite لازم است. Candidate قویتر ممکن است «پوشش مسیرهای Risk-tagged با Oracle معتبر» باشد، همراه Mutation score یا Defect escape بهعنوان Countermetric؛ باز هم نیازمند اعتبارسنجی است.
Cyclomatic Complexity یک آلارم زمینهای است
پیچیدگی بالاتر میتواند Testing و Review را دشوار کند، اما Threshold جهانی «کمتر از ۱۰» حقیقت عمومی نیست. زبان، ابزار، ساختار، Generated code، اندازهٔ تابع و Domain روی تفسیر اثر دارند. آن را ابتدا برای Sampling یا Review عمیقتر بهکار ببرید و رابطهٔ محلی با Outcome تعریفشده را بررسی کنید؛ امتیاز فردی توسعهدهنده نسازید.
Acceptance Criteria completeness با کیفیت نیازمندی برابر نیست
وجود یک فیلد غیرخالی، وضوح، صحت یا Testability را تضمین نمیکند. Indicator نامزد میتواند درصد Storyهای واجد معیارهای نسخهدار، قابلآزمون و Reviewشده باشد؛ اما باید Sampling semantic و پیامد بعدی مثل Rework یا Ambiguity defect تعریف شود. تیم نباید با متنهای قالبی و بیمعنا به ۱۰۰٪ برسد.
Code Review time رابطهای غیرخطی دارد
زمان کمتر ممکن است Flow بهتر یا Review سطحی باشد؛ زمان بیشتر ممکن است دقت بیشتر، PR بزرگتر یا Queue باشد. Cycle time را به Waiting و Active review تفکیک کنید، اندازه و ریسک Change را نگه دارید و Outcome مناسب انتخاب کنید. هدفگذاری خام زمان میتواند Reviewer را به کلیک سریع وادار کند.
Automation percentage بهتنهایی Driver خوبی نیست
Numerator و Denominator خودکارسازی معمولاً ناپایدارند: Case، Scenario، Risk یا Execution؟ Caseهای آسان میتوانند عدد را بالا ببرند و Maintenance cost، Flakiness و Feedback latency را بدتر کنند. اگر Candidate میسازید، Population را بر Risk/Flow تعریف و Countermetricهای Flaky rate، Time-to-signal، Maintenance burden و Escaped risk را اضافه کنید.
Production defects همیشه فقط Lagging نیست
نقص نسخهٔ جاری نسبت به همان نسخه Outcome پسرو است؛ اما نسبت به تصمیم Patch، Prioritization یا ریسک نسخهٔ بعد میتواند Candidate پیشرو باشد. Severity، Discovery channel، Duplicate، Exposure و Attribution window را ثابت کنید. «تعداد بالا = ضعف QA» ادعایی غیرمنصفانه و علّی است؛ تغییر Product، Operations، Requirement و Observability نیز اثر دارند.
Test Failure Rate و MTTR را نسبی بخوانید
Failure rate نسبت به تغییر قبلی Outcome است و نسبت به Release بعدی ممکن است Candidate باشد. MTTR نسبت به Incident بستهشده Lagging است، اما توزیع MTTRهای اخیر شاید برای Capacity planning آینده اطلاعاتی بدهد. هیچکدام بدون Build، Attempt، Retry، Quarantine، Severity، Open/censored work و Window قابلمقایسه نیستند.
Portfolio متعادل شاخصها چگونه ساخته میشود؟
| جایگاه | حداقل یک مورد | سؤال کنترلی |
|---|---|---|
| Outcome | پیامد کاربر/سیستم با Contract | آیا بالغ و قابلنسبتدادن به Cohort است؟ |
| Leading candidate | Metric زودهنگام با Mechanism | آیا Lead time قابلاقدام دارد؟ |
| Confirmation | Lagging Outcome measure | آیا نتیجهٔ واقعی را تأیید میکند؟ |
| Guardrail | هزینه یا آسیب جانبی | آیا بهبود Proxy چیزی را خراب کرده؟ |
| Data health | Missing/Late/Join/Version | آیا سبزی نمودار از خرابی داده میآید؟ |
| Context | Scope/Build/Traffic/Tool change | آیا رابطه هنوز قابلمقایسه است؟ |
داشبورد باید Hypothesis Registry را نمایش دهد
داشبورد Indicator نباید فقط مقدار و رنگ نشان دهد. شناسهٔ فرضیه، Outcome، Population، Horizon، Validity state، Data cutoff، Lead-time، Threshold version، False alerts/misses، Owner، Next review و Not claimed را قابلمشاهده کند. اصول Semantic layer و نمایش تصمیممحور را در راهنمای طراحی داشبورد گزارش تست دنبال کنید.
| وضعیت | معنای مجاز | نمایش ممنوع |
|---|---|---|
| CANDIDATE | Mechanism و طرح آزمون ثبت شده | Predictive/Validated |
| SHADOW_VALIDATED | معیارهای ازپیشتعریفشده در Shadow پاس شدهاند | Causal/Release-ready |
| ACTIVE | Authority استفادهٔ محدود را تأیید کرده | تضمین Outcome |
| UNDER_REVIEW | Drift یا تغییر Contract در حال بررسی است | سبز/قرمز قطعی |
| RETIRED | برای تصمیم جدید استفاده نمیشود | حذف تاریخچه |
| UNKNOWN | داده یا بلوغ Outcome کافی نیست | صفر یا Pass |
حلقهٔ بازخورد را بدون Closed-loop theater ببندید
Alert باید به Investigation، Decision، Action، Observation بعدی و Correction متصل شود. صرف ارسال پیام یا ساخت Ticket حلقه را نمیبندد. الگوی جامع Signal تا اقدام و یادگیری در Quality Feedback Loop در SDLC توضیح داده شده است. اینجا فقط باید مشخص کنیم Indicator چه Trigger محدودی ایجاد کرده و نتیجهٔ Action چگونه به Registry برمیگردد.
نقشها و اختیارها را از هم جدا کنید
| قابلیت | مسئولیت | اختیار ندارد مگر صریحاً واگذار شود |
|---|---|---|
| Metric steward | Contract، lineage، quality و version | Risk acceptance |
| Indicator analyst | Validation، error analysis، limitation | تغییر Outcome برای بهترشدن نتیجه |
| Domain owner | Mechanism و Context | تأیید مستقل تحلیل خودش |
| Decision authority | Threshold trade-off و Action approval | بازنویسی Evidence |
| Independent reviewer | Leakage، assumptions و reproducibility | مالکیت نتیجهٔ کسبوکار |
| Data/security owner | Access، minimization، retention | استفادهٔ ثانویهٔ نامحدود |
از Indicator برای امتیازدهی افراد استفاده نکنید
Coverage، Defect count، Review time، Automation rate و Escaped defects زمینهٔ تیمی و سیستمی دارند. اتصال مستقیم آنها به رتبهبندی، پاداش یا تنبیه فردی باعث Gaming، پنهانکردن Defect، شکستن Caseها یا حذف کار سخت میشود. واحد تحلیل و کاربرد مجاز را در Contract محدود کنید و People scoring را صریحاً false قرار دهید.
Automation و AI چه کاری میتوانند انجام دهند؟
- Schema، identity، time ordering، version و Missing را بهصورت قطعی کنترل کنند.
- Split زمانی، محاسبهٔ Confusion matrix و Reproducible report را اجرا کنند.
- Drift و Expiry را Alert کنند، بدون اعلام خودکار Cause.
- AI میتواند Candidate mechanism یا توضیح ساده پیشنهاد کند، اما منبع و عدمقطعیت باید حفظ شود.
- AI نباید دادهٔ واقعی محرمانه را بدون مجوز ببیند، Threshold را پنهانی تنظیم کند یا Release/Risk decision صادر کند.
خروجی مدل زبانی Evidence نیست. اگر AI خلاصهٔ Validation مینویسد، اعداد باید از Artifact قطعی و نسخهدار وارد شوند؛ هر Claim به جدول/کد منبع پیوند داشته باشد و بازبین انسانی حق Challenge و Correction داشته باشد.
امنیت، حریم خصوصی و Data minimization
برای ساخت Indicator معمولاً نیازی به نام فرد، ایمیل، IP، متن کامل Ticket، Screenshot یا Payload واقعی نیست. شناسههای Pseudonymous، Aggregate حداقلی و Retention محدود را ترجیح دهید. Purpose، lawful/organizational basis، Access، Export، Redaction، deletion و incident response باید با سیاست سازمان و مشاوران مسئول بررسی شود؛ این مقاله مشاورهٔ حقوقی یا امنیتی نیست.
Drift چگونه اعتبار Indicator را منقضی میکند؟
رابطه ممکن است با تغییر معماری، Runner، تیم، Scope mix، Test strategy، Feature flag، Traffic یا Outcome taxonomy جابهجا شود. سه نوع را جدا کنید: Data drift در توزیع ورودی، Concept drift در رابطهٔ Indicator–Outcome و Measurement drift در تعریف/ابزار. هرکدام Trigger و پاسخ متفاوت دارد.
- Measurement drift: استفاده را HOLD، lineage را تعمیر و تاریخچه را Correct کنید.
- Data drift: Segment و Population fitness را بازبینی کنید؛ فوراً Threshold تازه نسازید.
- Concept drift: Shadow revalidation و احتمال Retirement.
- Operational drift: اگر Lead time دیگر قابلاقدام نیست، Indicator حتی با دقت مشابه بیفایده شده است.
Revalidation و Expiry از ابتدا تعیین شوند
Active شدن پایان کار نیست. بازبینی دورهای و Event-driven لازم است: تغییر Contract، افت Precision، افزایش False miss، تغییر Base rate، عبور Data-health از حد، تغییر تصمیم یا پایان Horizon. تا وقتی Revalidation تمام نشده، وضعیت UNDER_REVIEW یا UNKNOWN را نمایش دهید؛ از مقدار قدیمی بهعنوان حقیقت زنده استفاده نکنید.
چه زمانی Indicator را Retire کنیم؟
- دیگر تصمیمی را تغییر نمیدهد یا Action قابلاجرا ندارد.
- Lead time از Deadline تصمیم کوتاهتر شده است.
- هزینهٔ False alert/miss از ارزش عملیاتی عبور کرده است.
- تعریف Outcome یا Population بنیادی عوض شده و Bridge معتبر نداریم.
- Gaming یا آسیب جانبی با Guardrail قابلکنترل نیست.
- Candidate در Holdout یا Shadow criteria شکست خورده است.
Retirement به معنای پاککردن نیست. آخرین نسخه، علت، تاریخ، تصمیمهای متاثر، جایگزین و Correctionهای لازم را نگه دارید. Dashboard تاریخی باید نشان دهد آن Indicator در آن زمان چه Status و Validity داشته است.
Correction باید قابلردیابی باشد
correction_id: COR-IND-042-02 corrects: IND-042-v1 / validation-report-v1 reason: outcome cutoff excluded six late events incorrectly affected_windows: [2026-W28, 2026-W29] old_claim: SHADOW_VALIDATED new_claim: UNDER_REVIEW affected_decisions: [DEC-SYN-042] owner: ROLE-METRIC-STEWARD issued_at: 2026-08-05T11:00:00Z superseding_artifacts: [IND-042-v2, validation-report-v2] silent_edit: false
آزمایش اجرایی: داشبورد سبز در برابر قرارداد Indicator
آزمایش زیر کاملاً ساختگی، آفلاین و بدون وابستگی است. Checker سطحی فقط پنج عدد محبوب را میبیند و نتیجه را معتبر اعلام میکند. ممیزی قراردادی ۴۴ جزء لازم را میسنجد. عدد ۴۴ Benchmark صنعت، Score بلوغ یا توصیهٔ عمومی نیست؛ فقط تعداد Ruleهای همین Fixture نسخهدار است.
const draft = {
dashboard: {
coverage: 85,
acceptance_criteria: 100,
automation: 70,
complexity: 9,
critical_defects: [10, 4]
},
declared_status: "LEADING_INDICATORS_VALIDATED",
people_scoring: false
};
const present = (v) =>
v !== undefined && v !== null &&
!(typeof v === "string" && v.trim() === "") &&
!(Array.isArray(v) && v.length === 0);
const rules = [
["IR-01 review_id", x => present(x.review_id)],
["IR-02 revision", x => present(x.revision)],
["IR-03 supersedes", x => present(x.supersedes)],
["IR-04 decision", x => present(x.decision)],
["IR-05 authority", x => present(x.authority)],
["IR-06 decision_due", x => present(x.decision_due)],
["IR-07 outcome_ref", x => present(x.outcome_ref)],
["IR-08 outcome_metric_contract", x => present(x.outcome_metric_contract)],
["IR-09 outcome_horizon", x => present(x.outcome_horizon)],
["IR-10 outcome_population", x => present(x.outcome_population)],
["IR-11 indicator_metric_contract", x => present(x.indicator_metric_contract)],
["IR-12 mechanism", x => present(x.mechanism)],
["IR-13 temporal_precedence", x => present(x.temporal_precedence)],
["IR-14 expected_direction", x => present(x.expected_direction)],
["IR-15 expected_shape", x => present(x.expected_shape)],
["IR-16 lead_horizon", x => present(x.lead_horizon)],
["IR-17 minimum_actionable_lead", x => present(x.minimum_actionable_lead)],
["IR-18 confounders", x => present(x.confounders)],
["IR-19 countermetric", x => present(x.countermetric)],
["IR-20 not_claimed", x => present(x.not_claimed)],
["IR-21 snapshot_id", x => present(x.snapshot_id)],
["IR-22 source_versions", x => present(x.source_versions)],
["IR-23 baseline_window", x => present(x.baseline_window)],
["IR-24 validation_window", x => present(x.validation_window)],
["IR-25 holdout_window", x => present(x.holdout_window)],
["IR-26 freshness_sla", x => present(x.freshness_sla)],
["IR-27 missing_policy", x => present(x.missing_policy)],
["IR-28 dedup_policy", x => present(x.dedup_policy)],
["IR-29 leakage_check", x => present(x.leakage_check)],
["IR-30 association_method", x => present(x.association_method)],
["IR-31 discrimination_method", x => present(x.discrimination_method)],
["IR-32 calibration_method", x => present(x.calibration_method)],
["IR-33 sensitivity", x => present(x.sensitivity)],
["IR-34 specificity", x => present(x.specificity)],
["IR-35 precision", x => present(x.precision)],
["IR-36 false_alert_count", x => present(x.false_alert_count)],
["IR-37 false_miss_count", x => present(x.false_miss_count)],
["IR-38 lead_time_distribution", x => present(x.lead_time_distribution)],
["IR-39 threshold", x => present(x.threshold)],
["IR-40 action_policy", x => present(x.action_policy)],
["IR-41 action_authority", x => present(x.action_authority)],
["IR-42 revalidation_trigger", x => present(x.revalidation_trigger)],
["IR-43 expiry", x => present(x.expiry)],
["IR-44 correction_policy", x => present(x.correction_policy)],
["IR-45 people_scoring_prohibited", x => x.people_scoring !== true]
];
const audit = (x) => rules.filter(([, ok]) => !ok(x)).map(([id]) => id);
const superficial = Object.values(draft.dashboard).every(present);
console.log("SUPERFICIAL", superficial ? "PASS" : "HOLD", draft.declared_status);
console.log("CONTRACT", audit(draft).length ? "HOLD" : "READY", audit(draft).length);
const corrected = {
review_id: "SYN-IND-042", revision: "v1", supersedes: "none:first-revision",
decision: "whether to start a 30-day shadow pilot",
authority: "ROLE-QUALITY-DECISION", decision_due: "2026-09-01T09:00:00Z",
outcome_ref: "OUT-SYN-RECON-v3", outcome_metric_contract: "M-OUT-v3",
outcome_horizon: "14d", outcome_population: "POP-SYN-v4",
indicator_metric_contract: "M-CALLBACK-v2",
mechanism: "contract violation may precede synthetic mismatch",
temporal_precedence: "computed >=48h before decision and before outcome cutoff",
expected_direction: "positive", expected_shape: "preregistered bins; no linear claim",
lead_horizon: "14d", minimum_actionable_lead: "48h",
confounders: ["scope_mix", "runner_version", "oracle_version"],
countermetric: ["flaky_rate", "join_failure_rate"],
not_claimed: ["causality", "release-readiness", "real-user-risk"],
snapshot_id: "SNAP-SYN-042", source_versions: ["runner-v5", "oracle-v3"],
baseline_window: "2026-W01..W12", validation_window: "2026-W13..W18",
holdout_window: "2026-W19..W24", freshness_sla: "24h",
missing_policy: "UNKNOWN; never zero", dedup_policy: "event_id first-write quarantine",
leakage_check: "time split; release groups kept intact; outcome fields excluded",
association_method: "preregistered synthetic contingency analysis",
discrimination_method: "holdout confusion matrix",
calibration_method: "descriptive preregistered risk bins with uncertainty",
sensitivity: 0.71, specificity: 0.82, precision: 0.44,
false_alert_count: 14, false_miss_count: 4,
lead_time_distribution: {p10: "49h", p50: "76h", p90: "121h"},
threshold: "TH-SYN-v1", action_policy: "focused evidence review only",
action_authority: "ROLE-QUALITY-DECISION",
revalidation_trigger: ["contract_change", "precision_below_0.35", "concept_drift"],
expiry: "2026-10-01T09:00:00Z", correction_policy: "supersede; no silent edit",
people_scoring: false
};
const findings = audit(corrected);
console.log("CORRECTED", findings.length ? "HOLD" : "READY_FOR_INDICATOR_REVIEW", findings.length);خروجی مستقل Fixture و تفسیر درست آن
SUPERFICIAL PASS LEADING_INDICATORS_VALIDATED CONTRACT HOLD 44 CORRECTED READY_FOR_INDICATOR_REVIEW 0
نسخهٔ اول هر پنج عدد را دارد، اما Review identity، Decision، Outcome، Mechanism، Horizon، Contract، Snapshot، Windowهای مستقل، معیارهای خطا، Action، Revalidation و Correction ندارد؛ بنابراین دقیقاً ۴۴ Finding ساختاری میگیرد. Rule چهلوپنجم People scoring را منع میکند و چون مقدار false است Finding نمیسازد. نسخهٔ اصلاحشده از نظر Schema صفر Finding دارد، اما این نتیجه صحت داده، کفایت نمونه، اعتبار روش آماری، قدرت پیشبینی واقعی، رابطهٔ علّی، کیفیت محصول، آمادگی انتشار یا درستی تصمیم را ثابت نمیکند. نام خروجی عمداً READY_FOR_INDICATOR_REVIEW است، نه VALIDATED.
آزمایشگاه آفلاین فارسی برای Checkout ساختگی
برای تمرین، یک Lab کاملاً جدا از Production بسازید: Order، PaymentAttempt، PSP Stub جعلی، Callback، Ledger، Reconciliation و اعلان ساختگی. سناریوها شامل Timeout پیش و پس از Fake commit، Retry، Callback تکراری/دیررس/جابهجا، قطع Collector، Outcome نارس و تغییر نسخهٔ Oracle باشند. هیچ اتصال شبکه، کاربر، سفارش، پول یا PSP واقعی وارد Lab نشود.
lab_id: SYN-IR-CHECKOUT-INDICATOR-01
network: disabled
production_data: forbidden
identities: [Tenant, Order, Attempt, Event, Build, Run, Snapshot, Cohort]
canonical_currency: fictional IRR only
toman_view: presentation-only and explicitly labelled
digits: [Persian, Arabic, Latin]
unicode_pairs: [ی/ي, ک/ك]
event_time: ISO-8601 UTC
display_timezone: Asia/Tehran
jalali_date: presentation-only
forbidden: [real PSP, bank, PAN, CVV2, OTP, account, mobile, email,
IP, cookie, token, credential, production log, screenshot]
claims: synthetic, non-representative, no legal/financial/security conclusion
برای ریال/تومان یک ستون Canonical با IRR ساختگی نگه دارید و View تومان را فقط نمایشی و برچسبدار بسازید؛ Conversion را در منطق Indicator پنهان نکنید. ارقام فارسی/عربی/لاتین و تفاوت ی/ی و ک/ک را در Normalize آزمایش کنید. زمان Canonical را UTC نگه دارید، Asia/Tehran را View و تاریخ جلالی را Presentation بدانید. هیچ ادعای بانکی، حقوقی، مالی، امنیتی یا نمایندگی بازار ایران از این Lab مجاز نیست.
Pilot سیروزه برای اعتبارسنجی بدون قفلکردن تصمیم
- روز ۱ تا ۵: Decision، Outcome، Contract، Theory، Candidate و Not claimed را Review کنید.
- روز ۶ تا ۱۰: Snapshot/Data-quality gate، Baseline و Split زمانی را Freeze کنید.
- روز ۱۱ تا ۲۰: Predictionها را پیش از Outcome بهصورت Shadow ثبت کنید؛ هیچ Release Gate خودکار نسازید.
- روز ۲۱ تا ۲۶: Outcomeهای بالغ، False alert/miss، Lead-time و Segmentها را بررسی کنید.
- روز ۲۷ تا ۳۰: مستقل Review کنید و یکی از REJECT، REDESIGN، EXTEND_SHADOW یا LIMITED_ACTIVE را با Authority ثبت کنید.
اگر Outcome در سی روز بالغ نمیشود، Pilot را بهزور «موفق» اعلام نکنید؛ مدت مشاهده را بر Horizon واقعی تنظیم کنید. خروجی ممکن است UNKNOWN یا EXTEND_SHADOW باشد. یادگیری معتبر از تصمیم سریع ارزشمندتر است.
ضدالگوهای رایج در شاخصهای پیشرو و پسرو
- ساخت لیست ثابت Leading metrics برای همهٔ تیمها و محصولات
- برچسب Predictive فقط چون Metric زودتر ثبت میشود
- تبدیل همبستگی دو Release به اثبات استراتژی
- استفاده از Coverage، Automation یا AC=۱۰۰% بهعنوان تضمین کیفیت
- اعلام «کمتر از ۱۰» برای Complexity بدون Context
- تنظیم Threshold پس از دیدن Holdout و گزارش همان عملکرد بهعنوان مستقل
- شمردن Outcome نارس یا Missing بهعنوان صفر
- نادیدهگرفتن Base rate، False miss و Alert fatigue
- یکیگرفتن Target، Control limit، Threshold و Forecast
- استفادهٔ مستقیم از Indicator برای رتبهبندی افراد
- تغییر Denominator برای سبزکردن Dashboard
- Re-baseline پس از هر Signal بدون حفظ تاریخچه
- اعلام Cause از روی Trend یا Storytelling
- واگذاری Risk acceptance یا Release به Rule خودکار
- Silent edit گزارش پس از کشف خطای داده
- حفظ Indicator بدون Expiry چون «همیشه استفاده شده»
چکلیست Owner پیش از فعالکردن Indicator
- Decision، options، Authority و Deadline ثبت شدهاند.
- Outcome Contract، Population، Window و Cutoff نسخه دارند.
- Candidate metric Contract مستقل و Reproducible دارد.
- Mechanism، Negative theory و Alternative explanations نوشته شدهاند.
- تقدم زمانی و Minimum actionable lead آزمونپذیرند.
- Expected direction/shape پیشثبت یا Exploratory برچسب خورده است.
- هویت Subject/Change/Build/Run/Cohort پایدار است.
- Snapshot شامل Missing/Duplicate/Late/Join و Source version است.
- Baseline از Intervention و تغییر تعریف آلوده نشده است.
- Train/Validation/Holdout یا Shadow plan زمان را حفظ میکند.
- Leakage و Outcome maturity بررسی شدهاند.
- Association، discrimination، calibration متناسب و عدمقطعیت روشناند.
- Sensitivity، specificity، precision و Base rate گزارش شدهاند.
- False alert/miss و هزینههای تصمیمی مرور شدهاند.
- Lead-time distribution و Data latency ثبت شدهاند.
- Threshold به Action، Authority، Due و Expiry وصل است.
- Guardrail، Countermetric و Data-health کنار Candidate هستند.
- People scoring، Causal claim و Release auto-decision ممنوع شدهاند.
- Drift، Revalidation، Retirement و Correction policy وجود دارد.
- Independent review، Security، access و Retention کاملاند.
پرسشهای متداول درباره Leading و Lagging Indicator در QA
آیا Test Coverage همیشه شاخص پیشرو است؟
خیر. Coverage یک Metric است. فقط وقتی نسبت به Outcome، Population، Horizon و Decision مشخص، با تعریف پایدار و دادهٔ ندیدهشده قدرت پیشبینی و Lead time قابلاقدام نشان دهد، میتوان آن را در همان دامنه Leading Indicator نامید. حتی آن زمان نیز علت یا تضمین کیفیت نیست.
آیا شاخص پسرو بیفایده و صرفاً واکنشی است؟
خیر. Lagging Indicator پیامد واقعی را تأیید میکند، Candidateهای پیشرو را کالیبره و خطاهای آنها را آشکار میسازد. همان Outcome تحققیافته ممکن است برای تصمیم دیگری در آینده Candidate پیشرو شود. ارزش آن به Decision و Contract بستگی دارد، نه برچسب زمانی.
چند Release برای اعتبارسنجی Indicator کافی است؟
عدد جهانی وجود ندارد. Base rate، واحد تحلیل، استقلال مشاهدات، اندازهٔ اثر، عدمقطعیت قابلقبول، تعداد Segmentها، طول Horizon و هزینهٔ خطا تعیینکنندهاند. دو Release و کاهش ۱۰ به ۴، بهتنهایی Validation نیست. طرح و کفایت نمونه را با فرد دارای صلاحیت آماری/دامنهای بررسی کنید.
اگر Leading Indicator بهتر شد ولی Outcome بدتر ماند چه کنیم؟
فوراً تیم را مقصر یا Threshold را جابهجا نکنید. سلامت داده، تغییر Contract/Population، Lag، Outcome maturity، Confounder، Gaming و شکستن Mechanism را بررسی کنید. وضعیت را UNDER_REVIEW بگذارید و بر اساس Evidence، Hypothesis را Redesign، Retire یا Correct کنید.
آیا میتوان Indicator را مستقیماً Release Gate کرد؟
بهطور پیشفرض نه. ابتدا Shadow validation، خطاها، Lead time، Guardrail، Authority و Action policy را تثبیت کنید. حتی Active Indicator یک ورودی محدود به Evidence review است؛ Risk acceptance و Release decision باید با Scope، Unknownها، گزینهها و اختیار روشن ثبت شوند.
جمعبندی: Indicator را فرضیه نگه دارید، نه حقیقت سازمانی
تفاوت شاخص پیشرو و پسرو با دو ستون «آینده/گذشته» تمام نمیشود. هر دو نسبت به Outcome و Decision معنا میگیرند. Leading بودن نیازمند تقدم زمانی، Mechanism، Metric/Data contract، Validation مستقل، خطاهای قابلقبول، Lead time قابلاقدام و تاریخ انقضاست. Lagging metric نیز برای دیدن Outcome واقعی و تصحیح فرضیه ضروری است.
از Candidate شروع کنید، نه از ادعای Prediction. تعریفها را Freeze، Prediction را در Shadow ثبت، False alert/miss را آشکار، تصمیم را از داشبورد جدا و Drift/Correction را حفظ کنید. تیم بالغ کیفیت آینده را «پیشگویی» نمیکند؛ فرضیهای محدود میسازد، آن را منصفانه میآزماید و وقتی داده مخالفت کرد، بدون پاککردن تاریخچه کنار میگذارد.
