Contract Suite Concepts: MSA/SOW/SLA/Scope

هدف این درس نوشتن قرارداد نیست؛ هدف ساختن یک مدل تصمیم قابل ممیزی است که بتواند بگوید یک درخواست یا تعهد دقیقاً به کدام سند و کدام نسخه متصل است. خروجی اصلی، Contract Suite Scope, Performance & Change-Control Matrix v1 است.

سناریو: یک سرویس agent-managed دارای توافق چارچوب، یک SOW پیاده‌سازی و یک SLA عملکردی است. مشتری یک integration جدید می‌خواهد و استدلال می‌کند چون SLA از «پشتیبانی سرویس» حرف می‌زند، integration هم در scope است. پاسخ درست نباید از یک جمله‌ی آشنا یا نام سند نتیجه بگیرد؛ باید authority محدوده، acceptance، performance و change-control را جدا کند.

خط قرمز: mention در MSA یا SLA به‌تنهایی scope proof نیست؛ performance commitment هم scope expansion نیست.

مسیر یادگیری و مرز مسئولیت

این درس مالک AGN-008 است: تفکیک framework terms، scoped work، acceptance، SLA performance و change control. درس AGN-007 درباره cost metering و AGN-009 درباره privacy/DPA را جذب نمی‌کند.

مسیر پایه با field map و یک سناریوی کامل شروع می‌شود. مسیر experienced تعریف‌ها را کوتاه می‌کند اما باید تعارض سندی، change state و recomputation را با همان evidence bar ثابت کند. هر دو مسیر به یک artifact واحد ختم می‌شوند.

مدل ذهنی: «Suite» یک سند واحد نیست

چهار لایه را از هم جدا نگه دارید:

1. Framework layer: توافق‌های عمومی و قواعد مشترک.
2. Scope/delivery layer: SOW یا change مصوب؛ چه چیزی، توسط چه کسی، در چه بازه‌ای و با چه deliverable/acceptance.
3. Performance layer: SLA؛ معیار، target، measurement window/source و remedy reference.
4. Change/conflict layer: درخواست تغییر، approval، priority rule، conflict و escalation.

این جداسازی یک قاعده حقوقی جهانی نیست؛ یک طراحی governance برای جلوگیری از قاطی‌شدن authorityهاست.

پایه‌ها: FACT در برابر DESIGN

NIST، SLA را commitment میان provider و customer می‌داند که می‌تواند مسئولیت‌ها، نوع سرویس، سطح عملکرد، reporting، resolution و termination را پوشش دهد. این مرجع برای فهم ماهیت performance evidence مفید است، نه برای تعیین enforceability یک قرارداد خاص.

FAR 8.405-2 در بافت مشخص خرید فدرال آمریکا، برای SOW عناصر کار، محل، period of performance، deliverable schedule، performance standards و special requirements را ذکر می‌کند. ما از این فهرست به‌عنوان نمونه ساختار evidence استفاده می‌کنیم، نه قانون عمومی قرارداد خصوصی.

هر چیزی فراتر از این—اولویت اسناد، approval state، remedy، legal review—باید از authority محلی یا بررسی حقوقی واقعی بیاید.

توضیح عمیق Contract

Artifact این درس ۱۹ dimension بحرانی دارد: contract_suite_id, سه reference اصلی MSA/SOW/SLA، scope_version, scope_item_id, deliverable_id, acceptance_criteria_ref, acceptance_state, service_metric_id, service_target, measurement_source, change_request_id, change_approval_state, document_priority_rule_ref, conflict_state, legal_review_required, evidence_ref, audit_ref.

چند gate کلیدی:

• اگر درخواست out-of-scope است، change-control لازم است؛ agent حق ندارد آن را صرفاً به دلیل wording یک SLA in-scope اعلام کند.
• اگر deliverable به change request تأییدنشده منتقل شده، acceptance_state=APPROVED تناقض است.
• تغییر measurement window، result قبلی را stale می‌کند و metric باید دوباره محاسبه شود.
• تعارض واقعی اسناد نمی‌تواند زیر conflict_state=CLEAR پنهان شود.
• priority rule یا remedy بدون reference معتبر، authority ساختگی است.
• در transfer، تصمیم baseline oracle نیست؛ schedule و customer dependency جدید باید از نو بررسی شوند.

مثال‌های کارشده

۱) درخواست integration جدید

SOW فعلی integration را ندارد، اما SLA درباره availability سرویس صحبت می‌کند. Matrix باید OUT_OF_SCOPE را ثبت کند، change request بسازد و SLA را فقط برای performance evidence نگه دارد. خروجی bounded: SCOPE_CHANGE_REVIEW_READY.

۲) deliverable موجود و acceptance کامل

اگر deliverable در scope فعلی است، criteria معلوم است و evidence پذیرش موجود است، APPROVED می‌تواند قابل دفاع باشد. این approval نباید به درخواست‌های جدید سرایت کند.

۳) transfer

در suite دوم همان metric SLA باقی مانده اما delivery schedule و customer dependency تغییر کرده است. نتیجه باید با شواهد جدید بازسازی شود؛ reuse تصمیم قبلی ممنوع است.

failure modeهای مهم

• SLA-as-scope: performance clause را scope authority فرض کردن.
• Mention-as-commitment: صرف وجود واژه در MSA را deliverable تلقی کردن.
• Approved-after-unapproved-change: change هنوز pending است ولی acceptance نهایی اعلام می‌شود.
• Stale metric: measurement window عوض شده ولی result قبلی نگه داشته می‌شود.
• Hidden conflict: دو سند متناقض‌اند ولی conflict=CLEAR است.
• Invented priority/remedy: agent بدون rule/ref معتبر اولویت یا remedy می‌سازد.
• Baseline oracle: transfer از تصمیم قبلی به‌جای evidence جدید استفاده می‌کند.

گزینه‌ها و trade-offها

یک suite می‌تواند اسناد کمتر یا بیشتری داشته باشد؛ این درس تعداد سند «صحیح» را تجویز نمی‌کند. trade-off واقعی بین سادگی، traceability، change-control overhead و clarity است.

در سیستم کوچک ممکن است یک سند چند نقش داشته باشد، اما evidence roleها هنوز باید قابل تفکیک باشند: کدام بخش scope را ثابت می‌کند؟ کدام performance target را؟ کدام change approval را؟ اگر پاسخ روشن نیست، state باید HOLD/REVIEW بماند.

پل برای فرد باتجربه

اگر قبلاً MSA/SOW/SLA را می‌شناسید، تعریف‌ها را رد کنید و مستقیم این سه سؤال را جواب دهید:

1. آیا هر obligation یک governing source و version دارد؟
2. آیا acceptance و SLA result با state و evidence جاری هم‌خوان‌اند؟
3. اگر سندها یا context تغییر کنند، کدام stateها باید recompute شوند؟

تجربه باعث waiver شدن evidence bar نمی‌شود.

تمرین هدایت‌شده و مستقل

ابتدا derived_text/tables/AGN-008-T1.csv را باز کنید و سه سناریو را مقایسه کنید. سپس Lab را اجرا کنید:

python -B lab/AGN-008-LAB1/learner/run_checks.py

در مرحله مستقل، تصمیم label را نادیده بگیرید و فقط از fieldها state را بازسازی کنید. یک سناریوی جدید بسازید که SLA metric همان باشد اما SOW schedule یا customer dependency عوض شود.

شواهد قابل بررسی

قبولی با یک جواب متنی نیست. باید Matrix کامل، provenance sourceها، negative case و transfer recomputation وجود داشته باشد. Lab باید نشان دهد shortcutهایی مثل SLA_ONLY => IN_SCOPE، pending change + approved acceptance و changed window + old result fail می‌شوند.

همه تصمیم‌ها باید از fieldهای قابل مشاهده بازتولید شوند؛ hidden reasoning یا «به نظر agent» evidence نیست.

ارزیابی و انتقال

ارزیابی چهار بخش دارد: retrieval مرز درس، application روی baseline، diagnosis روی mutation، و transfer. در transfer، suite دوم همان SLA metric را دارد اما schedule جدید و customer dependency صریح دارد. لازم است scope، acceptance، change-control و performance state از شواهد جدید recompute شوند.

اگر baseline decision کپی شود—even اگر تصادفاً نتیجه مشابه باشد—transfer مردود است.

منابع، تازگی و محدودیت حقوقی

• NIST CSRC Glossary — Service Level Agreement: مرجع terminology/performance expectations.
• Acquisition.gov FAR 8.405-2: نمونه رسمیِ عناصر SOW در بافت فدرال آمریکا.
• Frozen Lesson Bible lesson://AGN-008: authority محلی MAKNOW برای state vocabulary و governance.

این درس مشاوره حقوقی نیست. اولویت اسناد، remedies، enforceability و متن قرارداد واقعی باید توسط authority سازمانی/حقوقی تعیین شود. منابع بیرونی تا 2026-11-14 یا زودتر در صورت تغییر معنادار دوباره بررسی می‌شوند.