منبع حقیقت، محتوا، انتشار و رسانه · فصل ۴ — Media Library، Factory، FFmpeg، Workbench و QA · 168

Creative Workbench و Variant Graph

محتوا یا media تولید می‌کند اما provenance، rights، version، approval و release boundary را یک سیستم واحد نمی‌بیند. موضوع جاری: «Creative Workbench و Variant Graph». می‌تواند «Creative Workbench و Variant Graph» را در یک pipeline محدود با provenance، rights/version و publication gate تعریف کند.

Creative Workbench and Variant Graph — en-US

خلاصهٔ درس

محتوا یا media تولید می‌کند اما provenance، rights، version، approval و release boundary را یک سیستم واحد نمی‌بیند. موضوع جاری: «Creative Workbench و Variant Graph».

می‌تواند «Creative Workbench و Variant Graph» را در یک pipeline محدود با provenance، rights/version و publication gate تعریف کند.

خروجی این درس

می‌تواند «Creative Workbench و Variant Graph» را در یک pipeline محدود با provenance، rights/version و publication gate تعریف کند.

پیش‌نیازها

1. مسئله: «final-v3» lineage نیست

در یک workbench خلاقه، خیلی سریع چند crop، دو headline، یک color grade و چند composite ساخته می‌شود. اگر رابطه‌ی میان این خروجی‌ها فقط در filename، ترتیب پوشه یا history نرم‌افزار بماند، بعد از rename، compact شدن history یا export دوباره نمی‌توان با اطمینان گفت هر candidate از چه bytes و چه transformی آمده است. CON-017 این آشفتگی را به یک Variant Graph قابل ممیزی تبدیل می‌کند.

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

خروجی این درس Creative Variant Graph & Workbench Decision Ledger v1 است. این درس media-library authority را تعریف نمی‌کند، transform recipe reproducibility را مالک نیست، اجرای FFmpeg را آموزش نمی‌دهد و اجازه انتشار هم صادر نمی‌کند. CON-017 فقط lineage و انتخاب editorial را برای variantهای دقیق ثبت می‌کند؛ rights و publication gate در درس‌های مجاور بسته می‌شوند.

3. هر variant مادی یک node تغییرناپذیر

هر variant که واقعاً وارد جریان تصمیم می‌شود باید node جدا داشته باشد؛ حداقل با variant_node_id، asset_ref و asset_digest. اگر bytes تغییر کنند، node تازه ساخته می‌شود. «همان فایل قبلی با یک اصلاح کوچک» از نظر lineage کافی نیست؛ تغییر bytes یعنی identity جدید و provenance جدید.

4. PROV: entity و derivation را از هم تفکیک کن

W3C PROV برای توصیف provenance از Entity، Activity و Agent استفاده می‌کند و derivation/revision را می‌توان میان entityهای متمایز ثبت کرد. این نکته به ما اجازه می‌دهد source و variant را به‌عنوان entityهای جدا نگه داریم و transform را به activity وصل کنیم. اما PROV خودش policy مربوط به review، rights یا publication را برای MAKNOW تعیین نمی‌کند.

5. edge باید type داشته باشد

رابطه‌ی دو node فقط «مرتبط است» نیست. برای یک crop یا grade معمولاً lineage از نوع derivation است؛ برای composite باید ingredientهای تشکیل‌دهنده معلوم باشند؛ و برای ورودی یک فرایند محاسباتی باید نقش input مشخص بماند. edge بدون type یا بدون reference دقیق، lineage را مبهم می‌کند و باید UNKNOWN/LINEAGE_GAP بماند.

6. C2PA ingredient relationship چه کمکی می‌کند

C2PA 2.4 سه relationship مهم برای ingredient دارد: parentOf برای assetی که current asset از آن مشتق شده، componentOf برای assetی که یکی از اجزای ترکیب است، و inputTo برای ورودی یک فرایند محاسباتی. این semantics برای provenance مفیدند؛ اما به‌تنهایی branch policy، editorial selection یا اجازه انتشار نیستند.

7. branch یعنی lineage متفاوت، نه folder متفاوت

branch_id باید دلیل انشعاب را روشن کند: مثلاً locale/fa، locale/en یا headline/B. ساختن دو پوشه با نام‌های مختلف branch authoritative نمی‌سازد. branch زمانی معنی‌دار است که nodeهای دقیق، parentها و edgeهای آن در graph ثبت شوند و هر branch بتواند ingredientهای خودش را مستقل حمل کند.

8. merge را به‌صورت inheritance ضمنی ثبت نکن

اگر یک product cutout اصلاح‌شده فقط وارد branch فارسی شده، branch انگلیسی نباید خودکار همان ingredient را «ارث» ببرد. merge باید record جدا با node/ingredient دقیق داشته باشد. sibling branch فقط زمانی ingredient جدید را می‌گیرد که edge/merge ثبت‌شده برای همان branch وجود داشته باشد.

9. editor state فقط reference کمکی است

workbench_session_id و editor_state_ref برای audit مفیدند، اما authority lineage نیستند. ممکن است history compact شود، cache پاک شود یا پروژه editor جابه‌جا شود. اگر graph مستقل و digest-bound باشد، lineage بعد از حذف history هم قابل بازسازی می‌ماند؛ اگر نباشد، history خوب هم provenance durable نمی‌سازد.

10. filename و thumbnail هویت نیستند

rename نباید graph را تغییر دهد. اگر lexical order دو فایل برعکس شود ولی node IDs، digests و edges ثابت بمانند، lineage همان است. هر روشی که latest/final را از filename حدس بزند، در برابر final2, final_final و rename شکست می‌خورد.

11. selection را از provenance جدا نگه دار

Graph توضیح می‌دهد یک candidate چگونه ساخته شده؛ Decision Ledger توضیح می‌دهد کدام candidate برای review انتخاب یا رد شده است. selected_candidate، rejected_candidate، review_note و rejected_reason باید durable ثبت شوند. highlight آبی در UI یا tab فعال editor، انتخاب editorial قابل ممیزی نیست.

12. LINEAGE_GAP و ORPHAN را حدس نزن

اگر candidate digest دارد اما parent/ingredient binding لازم پیدا نمی‌شود، آن را به نزدیک‌ترین فایل نسبت نده. state باید LINEAGE_GAP یا ORPHAN_VARIANT بماند و recheck trigger دقیق تعریف شود. این discipline جلوی ساختن provenance خیالی از folder proximity یا similarity ظاهری را می‌گیرد.

13. Evidence Matrix را چگونه بخوانیم

جدول CON-017-T1 برای هر node/edge این فیلدها را کنار هم می‌گذارد: variant node، digest، branch، parent، edge type، ingredient، recipe reference، workbench session، review note، candidate state، selected/rejected reason و lineage completeness. جدول و نمودار یک معنی مشترک دارند و هیچ تصمیمی فقط با رنگ منتقل نمی‌شود.

14. Lab: هشت fixture و 64 assertion

در lab://CON-017/CON017-LAB1 هشت fixture دارید: baseline کامل، حذف editor history با graph سالم، rename فایل‌ها، node بدون digest، orphan candidate، composite با ingredient ناقص، selection فقط در UI و transfer دو locale branch. هدف این است که graph را از convenience state جدا کنید و هر missing binding را typed نگه دارید.

15. Transfer: دو locale branch، یک cutout اصلاح‌شده

در transfer، square variant به branch فارسی و انگلیسی fork می‌شود. cutout اصلاح‌شده فقط با componentOf به branch فارسی merge می‌شود و headline قدیمی رد می‌شود. nodeهای قبلی rewrite نمی‌شوند؛ branch انگلیسی ingredient قدیمی خود را حفظ می‌کند تا زمانی که merge جداگانه‌ای ثبت شود. نتیجه مطلوب این درس LINEAGE_READY است، نه «قابل انتشار»: publication authority هنوز متعلق به CON-018/CON-022 است.

ارزیابی

پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.

Q1 application

A square crop is exported and renamed. Which fields keep its lineage authoritative after rename?

lesson ✗AI ✗notes ✗

Q2 diagnosis

A composite references a cutout by filename but has no bound ingredient record. What state should the graph preserve?

lesson ✗AI ✗notes ✗

Q3 decision

The editor highlights variant B but no decision-ledger record exists. Can the selection be treated as durable?

lesson ✗AI ✗notes ✗

Q4 transfer

Fork FA/EN variants and merge a corrected cutout into FA only. Which branch inherits the corrected ingredient and why?

lesson ✗AI ✗notes ✗

Q5 reflection

State one claim proven by a complete variant graph and one publication claim it does not prove.

lesson ✗AI ✗notes ✗
ملاک‌های ارزیابی (rubric)

Critical dimensions: exact node identity, typed edge binding, negative/unknown-state preservation, bounded lineage decision, and changed-context transfer.

A sufficient submission never infers parentage from filename/editor state, never silently propagates a merge to sibling branches, and never turns LINEAGE_READY into publication approval.

منابع و تازگی

·
·

مطالعهٔ موارد (case studies)

فایل‌های آزمایشگاه

Use the supplied synthetic fixtures to evaluate durable variant identity, typed edge binding, lineage completeness, orphan state, and editorial selection recording.

The editor history and filename are convenience evidence only. Do not infer missing parent/ingredient bindings from visual similarity or folder order. Run python run_checks.py to verify fixture shape before implementing starter.py.