Content Version Model و Derivatives

1. «همان محتوا» با «همان نسخه» فرق دارد

یک content_id پایدار می‌تواند چند نسخه immutable داشته باشد. وقتی master از CV-17 به CV-18 می‌رود، CV-17 حذف یا بازنویسی نمی‌شود؛ فقط نسخه جدید ساخته می‌شود. این تفکیک پایه‌ی auditability است.

2. مرز مالکیت CON-012

این درس version و derivative lineage را می‌بندد. CON-011 localization semantics، CON-013 calendar/campaign readiness و C04 transform execution/QC را مالک‌اند. اینجا فقط می‌پرسیم «کدام نسخه دقیق، با کدام parent و transform، این derivative را ساخته است؟»

3. سه شناسه را قاطی نکن

content_id هویت پایدار موضوع است؛ content_version_id snapshot immutable آن محتواست؛ derivative_id یک خروجی مستقل با digest و lineage خودش است. latest فقط pointer کمکی است و authority تاریخی نیست.

4. PROV برای derivation vocabulary است

PROV-O اجازه می‌دهد Entity، Activity و Agent و رابطه wasDerivedFrom را مدل کنیم. در MAKNOW از آن برای traceability استفاده می‌کنیم، نه برای اثبات rights یا approval.

5. Derived asset با Rendition یکی نیست

در C2PA، derived asset نتیجه تغییر editorial است؛ asset rendition تبدیل non-editorial مثل re-encode یا resize است. بنابراین تغییر bitrate و تغییر معنا یک class واحد نیستند.

6. Composed asset چند ingredient دارد

اگر social image از master + لوگو + تصویر محصول ساخته شود، lineage فقط یک parent ندارد. ingredientهای decisive باید صریح ثبت شوند؛ حذف یک ingredient edge یعنی INCOMPLETE_LINEAGE.

7. Parent باید نسخه دقیق باشد

نوشتن «از master ساخته شد» کافی نیست. باید CV-17 یا digest دقیق ثبت شود. وقتی CV-18 می‌آید، derivative قدیمی نباید تاریخچه‌اش را عوض کند و ناگهان child نسخه جدید شود.

8. Transformation evidence را جدا ثبت کن

عمل transform، recipe/ref و در صورت نیاز transformation digest باید کنار lineage باشند. این evidence توضیح می‌دهد خروجی چگونه ساخته شده، اما به‌تنهایی rights یا approval را نمی‌بندد.

9. Digest هویت بایتی derivative را می‌بندد

هر derivative digest خودش را دارد. دو فایل با filename یکسان می‌توانند bytes متفاوت داشته باشند و دو filename متفاوت می‌توانند bytes یکسان داشته باشند. تصمیم را روی digest و version binding بنا کن.

10. تغییر upstream تاریخ را بازنویسی نمی‌کند

وقتی parent از CV-17 به CV-18 می‌رود، childهای CV-17 همچنان child همان نسخه‌اند. سیاست می‌تواند آن‌ها را STALE یا REQUALIFY کند؛ نباید edge قدیمی را به CV-18 repoint کند.

11. Staleness وابسته به نوع derivative است

تغییر editorial در parent معمولاً derivativeهای معنایی را نیازمند requalification می‌کند. اما یک rendition جدید با bitrate متفاوت می‌تواند همان editorial source version را حفظ کند و فقط node/digest جدید بسازد.

12. Rights و Approval از provenance مستقل‌اند

C2PA binding معتبر یا PROV chain کامل، approval revoked را دوباره معتبر نمی‌کند. rights_check و approval_binding باید dimensionهای جدا در graph باشند.

13. Negative case: provenance سبز، approval قرمز

اگر C2PA/lineage درست باشد ولی approval parent version لغو شود، خروجی CURRENT_FOR_LINEAGE نیست به معنای publication-ready. تصمیم باید REQUALIFY یا BLOCK شود و علت دقیق ثبت گردد.

14. Transfer: سه mutation هم‌زمان

به social asset ingredient دوم اضافه کن، video را فقط با resolution جدید rendition کن، و approval یکی از parent versionها را revoke کن. nodeهای قدیمی immutable می‌مانند؛ edgeها و state جدید از evidence تازه ساخته می‌شوند.

15. خروجی قابل ممیزی

برای هر row حداقل Content ID، Version ID، Parent(s)، Derivative ID/Type، Ingredients، Transform، Digestها، Rights، Approval، Stale state، Decision و Reason را ثبت کن. قوی‌ترین claim این است که lineage همین fixture reconstructable است؛ نه اینکه truth/rights/publication globally تضمین شده‌اند.