معماری چندکسب‌وکاری، تجاری و تجارت الکترونیک · فصل ۵ — Editorial Cell، SEO، QA، Approval و Onboarding · 249
Claim/Source Registry برای محتوای تجاری
workflow تجاری را به UI یا integration منفرد تقلیل می‌دهد و state، rights، approval و measurement را یکپارچه نمی‌کند. موضوع جاری: «Claim/Source Registry برای محتوای تجاری». می‌تواند «Claim/Source Registry برای محتوای تجاری» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
خلاصهٔ درس
workflow تجاری را به UI یا integration منفرد تقلیل می‌دهد و state، rights، approval و measurement را یکپارچه نمی‌کند. موضوع جاری: «Claim/Source Registry برای محتوای تجاری».
می‌تواند «Claim/Source Registry برای محتوای تجاری» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
خروجی این درس
می‌تواند «Claim/Source Registry برای محتوای تجاری» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
1) مسئله: داشتن لینک، Claim را VERIFIED نمی‌کند
یک صفحهٔ تجاری می‌گوید «۴۰٪ سریع‌تر»، یک testimonial کوتاه‌شده دارد و یک محدودیت محصول را از مستندات vendor نقل می‌کند. هر سه ردیف در spreadsheet لینک دارند، اما benchmark معلوم نیست برای کدام جمعیت بوده، متن اصلی testimonial نگه‌داری نشده و صفحهٔ vendor بعداً تغییر کرده است. مشکل کمبود URL نیست؛ مشکل این است که هویت Claim، نسخهٔ Source، مسیر Derivation، Scope، Reviewer و Freshness به هم متصل نیستند.
2) مرز COM-008: Claim/Source Registry، نه SEO Schema و نه Provider Routing
مالک این درس Commercial Claim-Source Registry v1 است. COM-007 مالک Provider Routing و COM-009 مالک SEO Page Schema است. این درس صحت حقوقی یا علمی هر ادعا را خودکار تضمین نمی‌کند، publication authority ایجاد نمی‌کند و هیچ لینک خارجی را به‌تنهایی مجوز انتشار نمی‌داند.
3) مدل ذهنی: Source Entity → Extraction Activity → Claim Derivation → Review → Typed State → Publication Gate
به‌جای ستون سادهٔ «منبع»، هر Claim را به یک source_entity نسخه‌دار متصل کنید. سپس مشخص کنید چه generation_activity یا extractionای انجام شده، چه relationای Claim را از Source مشتق می‌کند، چه کسی review کرده و نتیجهٔ قابل‌ممیزی چه stateی دارد. اگر یکی از این حلقه‌ها شکسته باشد، state مثبت نباید حدس زده شود.
4) FACT: PROV بین Entity، Activity و Agent فرق می‌گذارد
W3C PROV provenance را با Entity، Activity و Agent مدل می‌کند و روابطی برای generation، usage و derivation دارد. این تفکیک به ما اجازه می‌دهد «سند منبع»، «عمل استخراج/بازنویسی» و «عامل مسئول» را یک چیز فرض نکنیم. اما PROV دربارهٔ قانونی‌بودن یا truth threshold یک Claim تجاری تصمیم نمی‌گیرد.
5) FACT: Provenance فقط یک URL نیست
خانوادهٔ PROV برای derivation، collection و پیوند provenance descriptions سازوکار دارد. بنابراین یک registry قابل‌ممیزی باید بتواند نسخهٔ source، entity قبلی، derivation و supersession را نگه دارد؛ صرفاً جایگزین‌کردن URL جدید روی یک ردیف قدیمی history را نابود می‌کند.
6) قرارداد ۲۱ فیلدی Registry
هر Claim material یک claim_id پایدار، نوع و متن Claim، Scope، Source ID/Locator/Version، زمان retrieval، Entity/Activity/Agent، relation مشتق‌شدن، boundary کاربرد، freshness، review due، reviewer، verification result، dispute، supersession، publication state و evidence reference دارد.
| claim_id | claim_type | claim_text | claim_scope | source_id | source_locator | source_version | retrieved_at | source_entity | generation_activity | responsible_agent | derivation_relation | applicability_boundary | freshness_class | review_due | reviewer | verification_result | dispute_reason | supersedes_claim | publication_state | evidence_ref |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CLM-PERF-01 | performance | 40% faster in benchmark X | benchmark-X / workload-A | SRC-BENCH-01 | https://example.invalid/bench | v3 | 2026-09-15 | ENT-BENCH-v3 | ACT-EXTRACT-21 | reviewer-A | wasDerivedFrom | workload-A only | PRACTICE_EVOLVING | 2026-12-31 | reviewer-A | VERIFIED | VERIFIED | EVID-001 | ||
| CLM-QUOTE-02 | testimonial | Shortened customer quote | case-study-2026 | SRC-CASE-09 | https://example.invalid/case | v2 | 2026-09-15 | ENT-CASE-v2 | ACT-EDIT-22 | reviewer-B | wasDerivedFrom | approved excerpt only | PRACTICE_EVOLVING | 2026-12-31 | reviewer-B | HOLD | original source entity not preserved | HOLD | EVID-002 | |
| CLM-LIMIT-03 | product_limit | Feature unavailable in mode Z | product-doc mode-Z | SRC-DOC-17 | https://example.invalid/docs | v7 | 2026-09-15 | ENT-DOC-v7 | ACT-EXTRACT-23 | reviewer-A | wasDerivedFrom | mode-Z | PRACTICE_EVOLVING | 2026-10-15 | reviewer-A | STALE | source revised after review | CLM-LIMIT-01 | STALE | EVID-003 |
7) Claim ID باید از wording جدا باشد
متن Claim ممکن است برای کوتاه‌سازی، localization یا channel adaptation تغییر کند. اگر هر rewrite یک Claim بی‌هویت جدید بسازد، lineage از بین می‌رود. claim_id برای هویت تصمیم است؛ claim_text نسخهٔ بیان فعلی را ثبت می‌کند و supersedes_claim رابطهٔ جایگزینی را روشن نگه می‌دارد.
8) Source Locator با Source Version یکی نیست
یک URL ثابت می‌تواند امروز محتوایی متفاوت از ماه قبل نشان دهد. source_locator محل دسترسی است؛ source_version یا snapshot/retrieval state می‌گوید دقیقاً چه evidenceای در زمان review دیده شده است. اگر locator عوض شود یا source content materially تغییر کند، VERIFIED قبلی به‌طور خودکار carry forward نمی‌شود.
9) Applicability Boundary بخشی از خود Claim است
عبارت «۴۰٪ سریع‌تر» بدون baseline، workload، population، region یا test condition قابل‌انتقال به همهٔ contextها نیست. applicability_boundary تعیین می‌کند evidence تا کجا اجازهٔ تعمیم دارد. حذف boundary از یک performance claim حداقل آن را از VERIFIED خارج می‌کند و ممکن است فقط PARTIAL یا HOLD باقی بماند.
10) Reviewer و Verification Result باید مستقل ثبت شوند
وجود source نشان می‌دهد «چیزی برای بررسی وجود دارد»، نه اینکه support کافی است. Reviewer باید بتواند VERIFIED، PARTIAL، DISPUTED، STALE، REJECTED یا HOLD را ثبت کند و دلیل را در evidence/dispute نگه دارد. هیچ Model confidence یا citation count جای review boundary را نمی‌گیرد.
11) Freshness و Review Due، زمان را وارد Evidence می‌کنند
برخی منابع بنیادی تقریباً پایدارند؛ برخی docs محصول یا policyها سریع تغییر می‌کنند. freshness_class و review_due مشخص می‌کنند چه زمانی recheck لازم است. اگر source بعد از review materially تغییر کند یا review_due بگذرد، state امن STALE است تا دوباره qualification انجام شود.
12) Dispute و Supersession را overwrite نکنید
اگر reviewer با support یک Claim اختلاف دارد، history را با «آخرین نظر» پاک نکنید. dispute_reason نگه می‌دارد چه چیزی محل اختلاف است. اگر Claim جدیدی جای قبلی را می‌گیرد، supersedes_claim lineage را حفظ می‌کند؛ Claim قدیمی می‌تواند historical بماند بدون اینکه همچنان publishable باشد.
13) Publication State آخرین Gate است، نه Synonymِ Verification
verification_result=VERIFIED شرط مهمی است، اما کافی نیست. Publication State باید همچنین freshness، scope، dispute و approval محلی را در نظر بگیرد. در این درس، evidence ناقص یا provenance شکسته هیچ‌وقت با یک URL یا AI guess به state موفق تبدیل نمی‌شود.
14) Failure Modeها و state درست
- evidence کامل، provenance کامل، source fresh، support روشن و dispute حل‌شده →
VERIFIED - scope/boundary ناقص ولی بخشی از support معتبر است →
PARTIAL - support فعلی با evidence تاریخی یا review تعارض مادی دارد →
DISPUTED - source/version یا review زمان‌گذشته است و re-review نشده →
STALE - source عملاً Claim را پشتیبانی نمی‌کند →
REJECTED - provenance یا evidence لازم برای تصمیم وجود ندارد →
HOLD
15) Lab و Transfer: Source جدید را روی State قدیمی overwrite نکنید
Lab هشت fixture آفلاین و ۴۸ assertion deterministic دارد. در Transfer، vendor document جدید دیگر یک limitation قدیمی را نشان نمی‌دهد. کار درست حذف evidence تاریخی نیست: نسخهٔ قبلی را نگه دارید، current source را ثبت کنید، affected claims را دوباره review کنید و برای هرکدام state واقعی مثل STALE، DISPUTED، HOLD یا VERIFIED را از evidence جدید محاسبه کنید.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
COM-008-S1 retrieval
What does COM-008 own, and what remains outside its boundary?
COM-008-S2 application
Build Commercial Claim-Source Registry v1 for the baseline synthetic fixture.
COM-008-S3 diagnosis
A source URL changes but the old VERIFIED state is retained. Which evidence/state must change?
COM-008-S4 transfer
A vendor revision removes a previously verified limitation. Preserve provenance and recompute claim state.
ملاک‌های ارزیابی (rubric)
A passing artifact must keep claim identity, source version, derivation, applicability, freshness, reviewer and publication state visible. A citation alone is insufficient. Any decisive missing evidence, stale source or material dispute must remain a typed non-success state. Transfer must preserve history and recompute from changed evidence.
منابع و تازگی
مطالعهٔ موارد (case studies)
تصاویر درس
فایل‌های آزمایشگاه
فایل run_checks.py را اجرا کنید. داده‌ها کاملاً مصنوعی و آفلاین‌اند. برای هر case، هویت Claim، نسخهٔ Source، provenance، applicability، freshness، support و dispute را بررسی کنید و state را از evidence بسازید؛ مقدار قدیمی verification_result را کپی نکنید. هیچ API key، شبکه یا دادهٔ production لازم نیست.