Asset Provenance

1) چرا فایل‌نام و پوشه، منشأ یک asset را ثابت نمی‌کنند؟

فرض کنید یک تصویر محصول با نام final-v7.png از آژانس می‌رسد. در DAM یک فایل تقریباً مشابه وجود دارد، نسخه‌ای دیگر با AI پس‌زمینه‌اش تغییر کرده و مجوز منبع فقط داخل یک ایمیل مانده است. اگر صرفاً «جدیدترین فایل» را انتخاب کنیم، هنوز نمی‌دانیم این asset دقیقاً از کجا آمده، چه تغییری کرده، چه کسی یا چه ابزاری روی آن عمل کرده، hash یا credential متعلق به کدام نسخه است و آیا rights و approval همین نسخه معتبرند.

در این درس Digital Asset Provenance Ledger v1 را می‌سازیم: ledgerای که هویت پایدار asset را به source/ingredient، activity، agent، hash/credential، rights/consent، approval و downstream use متصل می‌کند.

قانون مرکزی: provenance «شواهد درباره‌ی تاریخچه و اتصال asset» است؛ وجود provenance یا credential به‌تنهایی حقیقت معنایی محتوا، مجوز حقوقی یا approval انتشار را ثابت نمی‌کند.

2) مرز درس و چیزی که مالک آن نیستیم

COM-016 مالک Asset Provenance است. COM-015 درباره‌ی Single-source Content Model است و COM-017 درباره‌ی Content Workflow States. بنابراین این درس content model یا workflow انتشار را دوباره طراحی نمی‌کند.

همچنین هیچ استفاده‌ی زنده، legal clearance، billing change یا production mutation انجام نمی‌شود. داده‌ها synthetic و تصمیم‌ها bounded هستند.

3) مدل ذهنی: Asset → Source/Ingredients → Activity/Agent → Binding/Credential → Rights/Approval → Downstream

هر نسخه‌ی asset باید بتواند به این پرسش‌ها پاسخ دهد: کدام asset و کدام version؟ از چه source یا ingredientهایی ساخته شد؟ چه activity رخ داد؟ actor انسانی یا نرم‌افزاری چه بود؟ آیا bytes فعلی با content hash یا binding ثبت‌شده می‌خوانند؟ credential چه وضعیتی دارد؟ rights و consent مستقل چه می‌گویند؟ approval متعلق به همین version است؟ و کجا downstream استفاده شده؟

اگر یکی از شواهد حیاتی نامعلوم، disputed یا stale است، state موفق مجاز نیست.

4) W3C PROV چه چیزی می‌دهد و چه چیزی نمی‌دهد؟

PROV-O منشأ را با سه مفهوم اصلی Entity، Activity و Agent مدل می‌کند و روابطی مثل generation، usage، derivation و attribution را برای بازسازی تاریخچه ارائه می‌دهد. برای ledger ما این الگو کمک می‌کند source asset، عملیات تبدیل و actor از هم جدا باشند.

اما PROV-O امضای cryptographic فایل نیست. اینکه یک relation را ثبت کرده‌ایم، به‌خودی‌خود ثابت نمی‌کند bytes دست‌نخورده‌اند یا claim حقوقی معتبر است.

5) C2PA Content Credentials چه چیز اضافه می‌کند؟

C2PA 2.4 یک C2PA Manifest را به‌صورت مجموعه‌ای از assertions، claim، signature و content binding تعریف می‌کند. برای derived و composed asset نیز ingredientها بخشی از provenance هستند. بنابراین می‌توان origin/change history را با شواهد tamper-evident و bindingهای محتوایی قوی‌تر کرد.

اما خود C2PA صریحاً provenance را trust signal می‌داند، نه داوری خودکار درباره‌ی «خوب/بد» یا درست‌بودن همه‌ی ادعاهای داخل محتوا. پس credential_validation_state=VALID نباید خودکار rights_state=APPROVED یا approval_state=APPROVED تولید کند.

6) Stable identity: asset_id و asset_version را از filename جدا کن

asset_id باید هویت منطقی asset باشد و asset_version تغییر مشخص آن را نشان دهد. final-v7.png یک label انسانی است، نه contract هویت. اگر bytes عوض شوند ولی version و hash قدیمی حفظ شوند، ledger باید mismatch را ببیند.

برای derived asset، source_asset_ref لازم است؛ برای composed asset، ingredient_refs باید همه‌ی اجزای مؤثر را پوشش دهد. حذف عمدی یا تصادفی یک ingredient یعنی lineage ناقص است.

7) Activity و Agent: «چه اتفاقی افتاد؟ توسط چه کسی یا چه چیزی؟»

activity_id عملیات را مشخص می‌کند: crop، color correction، generative fill، recomposition یا export. agent_id مسئول/عامل را ثبت می‌کند و tool_or_model ابزار را توضیح می‌دهد. این تفکیک مهم است: ابزار، agent و approval authority یک چیز نیستند.

اگر یک AI tool background را تغییر دهد، آن تغییر باید در activity ثبت شود؛ اما ابزار به‌خودی‌خود rights یا editorial approval صادر نمی‌کند.

8) Hash و credential را برای نسخه‌ی درست bind کن

content_hash باید به bytes همین asset_version مربوط باشد. اگر فایل جایگزین شده اما hash و credential state قدیمی مانده‌اند، BLOCKED_HASH_MISMATCH یک state سالم‌تر از success است.

credential_ref و credential_validation_state نیز باید به همان asset/version متصل باشند. invalid، inaccessible یا stale credential باید به‌صورت صریح دیده شود؛ حذف این uncertainty فقط audit را ضعیف می‌کند.

9) Rights، consent و approval سه محور جدا هستند

ممکن است credential معتبر باشد اما license برای campaign جدید اجازه ندهد. ممکن است rights روشن باشد ولی consent موردنیاز وجود نداشته باشد. ممکن است هر دو درست باشند اما editorial approval بعد از یک transformation مادی stale شده باشد.

پس MAKNOW این stateها را جدا نگه می‌دارد: rights_state، consent_ref و approval_state. یک مسیر downstream فقط وقتی مجاز است که policy همان use case را با evidence کافی پوشش دهد.

10) مثال پایه و ضد‌مثال

در baseline، asset نسخه‌ی مشخص دارد، source و ingredientها کامل‌اند، activity و agent معلوم‌اند، hash match است، credential VALID است، rights برای همان use APPROVED است و approval همین version معتبر است. نتیجه می‌تواند DOWNSTREAM_USE_ALLOWED باشد.

ضد‌مثال اول: composed asset دو ingredient دارد اما ledger فقط یکی را ثبت کرده است. credential خود composed file حتی اگر VALID باشد، ingredient gap را پاک نمی‌کند؛ نتیجه BLOCKED_INGREDIENT_GAP است.

ضد‌مثال دوم: credential معتبر است اما rights_state=UNKNOWN. سیستم حق ندارد از «credential valid» به «rights approved» بپرد؛ نتیجه BLOCKED_CREDENTIAL_OVERCLAIM است.

11) Failure modeهای مهم

• Old hash after replacement: bytes عوض شده‌اند اما hash قبلی نگه داشته شده → BLOCKED_HASH_MISMATCH.
• Derivative without source: asset مشتق شده ولی source link ندارد → BLOCKED_SOURCE_LINK.
• Invalid credential: credential validation fail شده → BLOCKED_CREDENTIAL_INVALID.
• Stale approval: transformation مادی انجام شده ولی approval هنوز متعلق به version قبلی است → BLOCKED_APPROVAL.
• Missing decisive evidence: evidence حیاتی واقعاً وجود ندارد → HOLD_MISSING_EVIDENCE.

12) Lab و انتقال به context جدید

در COM-016-LAB1 هشت fixture آفلاین را اجرا می‌کنید. هدف پیدا کردن state درست از evidence آشکار است، نه تقلید baseline.

Transfer: یک asset تأییدشده crop و color-correct می‌شود و سپس با یک ingredient جدیدِ licensed ترکیب می‌شود. باید version جدید بسازید، source و ingredientها را حفظ کنید، activity/agent را ثبت کنید، hash/credential را برای خروجی جدید بررسی کنید و مشخص کنید approval قبلی هنوز معتبر است یا fresh approval لازم است.

13) تصمیم bounded و Freshness

خروجی این درس یک «حکم حقیقت» نیست؛ یک تصمیم محدود درباره‌ی قابلیت استفاده‌ی downstream بر اساس evidence فعلی است. اگر origin، ingredient، hash، credential، rights یا approval تغییر کند، تصمیم باید دوباره محاسبه شود.

مرجع foundational: W3C PROV-O. مرجع evolving: C2PA Content Credentials 2.4. وضعیت نسخه و validation/ingredient semantics تا 2026-12-31 یا زودتر در صورت تغییر مادی دوباره بررسی می‌شود. قواعد BLOCK/HOLD، rights classes و approval transitionها طراحی MAKNOW هستند، نه الزام W3C یا C2PA.