Claim/Evidence Governance و Confidence

1. مسئله واقعی: citation زیاد، confidence معتبر نیست

یک pipeline می‌تواند ده‌ها citation، provenance و حتی signature داشته باشد اما هنوز نداند هر claim دقیقاً چه می‌گوید و کدام evidence همان claim محدود را پشتیبانی یا نقض می‌کند. اگر confidence فقط از «تعداد منبع» یا «ظاهر معتبر منبع» بیاید، یک جملهٔ مطمئن ممکن است پس از stale شدن evidence یا تغییر نسخه زنده بماند. هدف این درس ساختن Claim–Evidence Ledger & Confidence Decision Record v1 است؛ جایی که هر claim هویت، scope، evidence، freshness، contradiction و recheck trigger دارد.

2. Claim را واحد مستقل و قابل اشاره کن

هر claim باید claim_id پایدار، متن bounded و claim_scope روشن داشته باشد. claim broad مثل «این قابلیت offline کار می‌کند» معمولاً خطرناک است؛ شاید evidence فقط نسخهٔ v3.2 و فقط یک workflow خاص را ثابت کند. اگر scope evidence کوچک‌تر از scope claim است، claim را محدود کن؛ evidence را مجبور نکن claim بزرگ‌تر را حمل کند.

3. Source authority با claim support یکی نیست

CON-001 مشخص می‌کند source canonical کدام است و exact version چگونه bind می‌شود. CON-002 آن binding را مصرف می‌کند اما سؤال دیگری می‌پرسد: آیا این evidence دقیقاً این claim را پشتیبانی می‌کند؟ یک source رسمی می‌تواند درباره موضوع مرتبط معتبر باشد ولی claim فعلی را اثبات نکند. authority، relevance و sufficiency را یک field نکن.

4. PROV-O برای lineage است، نه حقیقت

PROV-O با Entity، Activity و Agent و رابطه‌هایی مثل wasDerivedFrom provenance و derivation را مدل می‌کند. این برای پاسخ به «این evidence از کجا آمده و چگونه تولید شده؟» عالی است. اما provenance صحیح به‌تنهایی نمی‌گوید claim انسانی درست، کامل یا قابل اتکاست. در ledger، provenance یک dimension لازم است، نه confidence shortcut.

5. C2PA سیگنال provenance می‌دهد، نه verdict حقیقت

C2PA assertions، claim، signature و content binding را در manifest کنار هم قرار می‌دهد و validation می‌تواند tamper-evidence و trust signal بدهد. خود specification تأکید می‌کند که این سازوکار value judgment درباره خوب/بد یا حقیقت assertionها نمی‌دهد. پس c2pa_valid=true هرگز معادل claim_supported=true نیست.

6. Evidence را typed و جهت‌دار ثبت کن

برای هر evidence حداقل evidence_id، evidence_type، source_binding_ref، retrieved_at، review_due، provenance و جهت اثر را ثبت کن. جهت اثر باید صریح باشد: supports, contradicts, neutral/context. یک evidence می‌تواند فقط بخشی از claim را support کند. «منبع مرتبط» را با «support» یکی نکن.

7. Support و contradiction هم‌زمان ممکن‌اند

Claim governance باید اجازه دهد evidenceهای مخالف کنار evidenceهای موافق باقی بمانند. اگر تست deterministic یک claim را support می‌کند ولی release note جدید wording broad را نقض می‌کند، تاریخچه هیچ‌کدام را پاک نکن. claim را split یا restrict کن و contradiction را به current decision وارد کن.

8. Freshness یک clock واقعی است

retrieved_at فقط زمان دریافت است؛ برای reliance به review_due یا trigger معتبر نیاز داری. وقتی decisive evidence stale می‌شود، confidence قبلی نباید خودکار ادامه پیدا کند. current status می‌تواند RESTRICTED_STALE یا REQUALIFY شود، در حالی‌که رکورد تاریخی evidence و تصمیم قبلی دست‌نخورده می‌ماند.

9. Confidence label بدون rule ممنوع است

اگر از LOW/MEDIUM/HIGH استفاده می‌کنی، باید semantics آن را از قبل تعریف کنی: چه evidenceهایی لازم‌اند، contradiction چه اثری دارد، freshness چگونه وارد تصمیم می‌شود و چه scopeی پوشش داده می‌شود. HIGH=0.93 ننویس مگر واقعاً calibration method و دادهٔ calibration داری. label ordinal را probability جا نزن.

10. Confidence basis باید inspectable باشد

کنار confidence_label یک confidence_basis بنویس که به evidence IDها و ruleهای صریح اشاره کند. مثال: «HIGH فقط برای claim scope=v3.2/offline-cache؛ E1 official version-bound + E2 deterministic test fresh؛ no active contradiction». این متن باید بتواند بدون reasoning پنهان مدل audit شود.

11. Stateهای current claim را typed کن

حداقل بین SUPPORTED_BOUNDED، RESTRICTED_SCOPE، RESTRICTED_STALE، RESTRICTED_CONFIDENCE، RESTRICTED_OR_UNSUPPORTED و UNSUPPORTED تفاوت بگذار. UNKNOWN را به false یا true تبدیل نکن. اگر decisive binding گم شده یا evidence کافی نیست، downstream باید بداند دقیقاً چه چیزی قابل اتکا نیست.

12. تاریخچه را پاک نکن؛ current status را عوض کن

وقتی evidence جدید claim قبلی را نقض می‌کند، claim/evidence eventهای تاریخی را حذف یا overwrite نکن. current record را با دلیل جدید، timestamp و recheck trigger به‌روزرسانی کن. audit trail باید نشان دهد چرا در زمان T1 reliance مجاز بوده و چرا در T2 محدود شده است.

13. Decision record باید non-claim داشته باشد

یک تصمیم خوب فقط نمی‌گوید «چه چیزی پشتیبانی می‌شود»؛ می‌گوید چه چیزی اثبات نشده است. برای نمونه: «این ledger درباره rights، approval validity یا release manifest حکم نمی‌دهد.» non-claimها مانع می‌شوند confidence این درس به لایه‌های CON-003 تا CON-005 نشت کند.

14. Transfer: نسخه عوض شده، evidence قبلی کافی نیست

تمرین انتقال Bible را اجرا کن: همان family از claim را نگه دار، اما E2 پس از version change منقضی شود و یک تست تازه contradiction ایجاد کند. تصمیم قبلی را copy نکن. support، contradiction، freshness و binding را از نو محاسبه کن. تا وقتی evidence جدید bounded gap را نبندد، state باید RESTRICTED_OR_UNSUPPORTED بماند.

15. خروجی نهایی و مرز اتکا

Claim–Evidence Ledger & Confidence Decision Record v1 باید Claim ID/Text/Scope، Source Binding، Evidence IDs/Types، Support/Contradiction Links، Retrieved/Review Due، Freshness State، Confidence Label/Basis، Current Claim Status، Residual Uncertainty، Recheck Trigger و Provenance را نگه دارد. این درس source authority را انتخاب نمی‌کند، rights را تعیین نمی‌کند، approval را صادر نمی‌کند و release را نمی‌سازد؛ فقط مشخص می‌کند برای این claim bounded، با این evidence فعلی، چه مقدار reliance قابل دفاع است.